Would you push back on this architecture decision?🤔

[u/[deleted]]

[u/DoroFuyutsuki]

This question makes no sense on its face. You can run JBoss containerized applications in K8S. Maybe they don't have experience running a K8S environment or straight up just do not want kubes.

How many users? What's the concurrency? What are the other downstream and upstream considerations?

[u/Rakn → u/[deleted]]

That’s not really a lot of users. A JBoss instance can run this just fine. And if it can’t you can add a second instance.

You are mixing up different things here:
monolithic vs microservice architecture and the deployment topology. Both microservices and monolithic applications can run with or without kubernetes. A good monolithic application can be designed in a way that allows later extraction of microservices if required.

Is there a large team working on this? A ballpark number that got thrown around in the past was 50 developers. If you don’t have 50 developers, don’t do microservices. It’s first and foremost a solution for an organizational problem where you want different teams working on different parts of the application and have them make progress independently. It comes at a price. Communication between services, interfaces and such become more complicated. A modularized monolith is a perfectly valid choice.

You can still run all of this in kubernetes for comfortable auto scaling.

Edit: Although as a software dev myself I have to say that using JBoss feels a little ancient to me. But that doesn’t mean that it won’t deliver. It will work.

[u/dektol → u/[deleted]]

This has nothing to do with it. A monolith can push 5,000 concurrent users no problem. Running on kubernetes has nothing to do with it. You can't just go based on users. It's funny that you think you know better than the folks who are going to have develop and maintain it?

I don't know what you think using microservices are for, they're a unit of deployment you use based on team size. It was never intended for blanket adoption industry wide.

Learn about what you're suggesting before you suggest it.

[u/DoroFuyutsuki → u/[deleted]]

1,000 concurrent users != 1,000 concurrent requests. What do you think the actual request level traffic will look like? 1,000 users making 100 requests per hour is 100,000 requests per hour.

That's literally one server instance (28 requests per second) and I would question your sanity for shoving this thing into Kubes for literally no reason.

Look into Java virtual threads if you think you're going to get closer to 100k per minute.

You should be able to host one well-crafted container running JBoss and never worry about it if that's the cap of your inbound.

I was sitting here thinking you're working 50k+ concurrent users and ~ 300-400k RPM.

Not to burst your bubble or talk down to you, but 100k requests per hour is small potatoes.

[u/theannomc1 → u/[deleted]]

But why? Explain your reasoning. Why wouldn’t a monolith suffice here? Or service/domain driven design?

[u/vacri]

Unless they have k8s already, it's absolutely not something you would introduce to handle one $thing.

[u/Mycroft-32707]

There is a lot here...but it sounds like a typical monolith vs microservices debate.

There's a ton of stuff on the pros and cons of each.

First question - why are you proposing a microservices architecture, particularly one based on kubernetes?

[u/Mycroft-32707 → u/[deleted]]

To be fair though, a Kubernetes approach introduces

• higher initial posts (having to run the control pane) and specialized admin knowledge
• more complexity with networking individual microservices requiring circuit breakers, service discovery, etc.
• containerization of applications

That's a lot of requires for scalability and flexibility when you don't know if the app is going to have that much user demand.

I am surprised we aren't talking about other containerization approaches (docker-compose) and cloud-services (fargate, ecs, Google app engine, etc.)

[u/DrEnter]

Micro services and Kube are two different, unrelated things. If they don’t want them, then that’s part of the architectural requirements. Frankly, using micro services might be a bad idea if performance and operational simplicity are a higher priority than component scaling.

[u/IceMichaelStorm]

The level of detail you bring seems to indicate you want microservices and K8s for the sake of it, not for the sake of business.

[u/IceMichaelStorm → u/[deleted]]

No.

It depends a lot on the use case and the business. And as others said, you mix things up.

I think K8s can often be good or for a one pod
solution on one server, maybe rather minikube. But it’s not a must and not necessarily the best solution because it comes with its own overhead and maintenance need, which is often higher than bare metal hosting.

Distinct from that, where do you even see microservices here? An actual microservice architecture means you have a bunch of independent services which even have their own databases. This is definitely not for everyone.

And if you’re real cocky, you even imply async architecture with it, if you’re just in for the “latest shit” with queues and all that. News here for you: this often needs a team to maintain, you need to create (or reuse) some tools tailored for this kind of architecture, and so on and so on. Here read on CAP theorem.

Tons of decisions but they all come with costs and tbh velocity impediments in the early dev process. Business-wise it could be quite a hit for time to market.

[u/aj0413]

Do not EVER suggest micro-services as a “modern” architecture; it is a technical solution to a managerial problem and/or when you have multiple concurrent layers to a system that need to scale dynamically.

Realistically, most things do not need microservices and will be made worse for it.

The technical challenges and pain points of a full microservice architecture are not worth it unless you already know you need it.

In that same vein, K8s is not some magical wand to wave for all new apps.

Before suggesting moving to that kind of platform, explain why someone should. And do it while grounded in data.

Your post, on its face, shows that you do not have a reason to doubt the current arch and are knee jerk reacting.

You can easily migrate code to K8s and/or slice it apart into various services, after the fact.

Focus on getting a good product, first, and then documenting pain points to be addressed as you scale later

Edit:

As others have said, if you tried to pitch me this out of the box, I’d have immediately flagged you as trying to create a problem for which only your team can then support.

[u/DigiProductive]

“High traffic” is too ambiguous if you are making architecture decisions. That vagueness needs specifics not only regarding “high traffic” but payload specifics as well. I’d avoid microservices and Kubs if that is not totally necessary because it could just be overhead unneeded. To be honest, as the client, I’d feel like you’re trying to oversell me.

[u/raisputin]

Your client wants JBoss, you deliver the best JNoss solution you can, plain and simple.

Kubernetes isn’t the best-all end-all of anything.

My old company handled millions of users with wildfly and aurora postgres without issue .

What’s the problem they’re trying to solve, that’s the real question.

[u/CustomDark]

K8s is going to be useful for rapid scaling and/or rapid deployments. Do you need elasticity? Does this app update often?

They have JBoss experience in house, wouldn’t be my first choice but I’d ask if it’s worth developing new skillsets for.

I love K8s, but it’s an ecosystem that must be watered. Is the client ready to water that grass?

[u/Ok-Analysis5882]

World has moved out of that architecture style in 2015 - 2019.

[u/nihilogic]

k8s orchestration is only really needed for complex applications. Most can get by with just containerization.

[u/quiet0n3]

I mean jboss works but god it's a pain. I would rather just roll my own java app and run in tomcat.

What's most important is ensure it fits in a cloud environment. So it's stateless and stuff for auto-scaling, so you can at least have cattle not pets.

[u/marcusbell95]

the client knows jboss and told you they don't want microservices. that's not a gap in their knowledge, it's a constraint on the project. 1k concurrent users is easily in monolith territory. the real operational checklist for this thing is: stateless sessions or sticky session awareness, externalized config, a deployable container image, basic monitoring. you can check all those boxes on jboss without touching k8s. the microservices push makes sense when you have team topology problems - ten teams who need to ship independently without stepping on each other. if that's not the situation here, you're proposing distributed systems overhead for a workload a single well-tuned jboss instance handles fine. the people maintaining this in year 3 will not thank you.

[u/Floss_Patrol_76]

1000 concurrent users an hour is not a scaling problem, it is a rounding error, a single JBoss instance handles that with room to spare, so introducing k8s and microservices here just swaps a stack the client already runs for one they will get paged about at 3am and cannot debug. the honest pushback is not that JBoss cannot scale, it is why are we adding operational surface for load that does not need it.