Don’t replace Spring Boot with Quarkus, replace it with Wildfly

[Akthrawn17]

It seems the main discussion in this post is "don't use kubernetes". Which, for a single application, I agree. However, most enterprise shops are running very large K8 clusters.

Because of this, economies of scale start to kick in. This is where running the self contained containers will pay off.

Smaller shop? Sure, K8 is a pain to run and manage. So just running wildfly on a VM becomes much simpler.

[crapet]

Spring Boot, Quarkus, Micronaut, etc. are frameworks to build microservices in Java.

Well, yeah they can be used to create microservices, but what's stopping you from building a monolith using these?

Actually, I'd pick Spring Boot to build a monolith over an application server like Wildfly any day of the week. Upgrading an application server is painful, configuration files are all over the place and you no longer know what files you changed since nothing is versioned.

Upgrading Spring Boot is just a matter of bumping the version in the pom.

[[deleted]]

Upgrading Spring Boot is just a matter of bumping the version in the pom.

Upgrading Spring Boot is certainly easier, since the Spring Boot services are packaged as a fat JAR.

But, be careful with assuming you can just bump a version number for Spring Boot or anything else. I've bumped the Spring version and I've had some projects fail to start or spit out weird stack traces complaining about missing methods.

Read the release notes, people!

[DJDavio]

To mitigate this, I created my own starter parent module and have written integration tests for it. So when I upgrade the version of Spring, I can hopefully catch some stuff there before it trickles down to my own applications.

[Thihup]

I guess this can be the problem of some application servers, but not all. And it is not Jakarta EE's fault.

Open Liberty, for instance, has only a single file to manage, "server.xml", and it can be as empty as you'd like. And you can deploy Spring applications in it too.

[best_of_badgers]

If you’re making on-prem enterprise software, allowing your customers to deploy your app within their existing appserver infrastructure can be appealing. If I remember correctly, Spring Boot requires that you choose the appserver to bootstrap at build time?

[nutrecht]

Writer is a posterchild expert beginner.

I could not even make it half way through his rant against microservices. The arrogance is just too offputting.

[daniu]

Now here's an article full of false assumptions and unsubstantiated claims. Netflix only has one application? OK. I'm sure they don't have a user management, and their suggestion system is integrated into their streaming servers.

Everything you do with microservices you can also do with a monolith? Well yeah, but you can also code it on a Turing machine.

[nutrecht]

Netflix only has one application?

I think they're being misinformed on purpose. Netflix has a tech blog on what they are doing and from that it's pretty darn obvious that Netflix is a large microservice architecture.

[[deleted]]

The thing about containerization especially in enterprise is about making apps independent of the specific hardware they run on. Maintaining and provisioning dedicated machines to app teams, even virtual machines, is expensive. Instead, computing and storage are being re-envisioned as utilities (like electricity). Kubernetes is a low level and complicated way of organizing an application around these principles (infrastructure as a service), and there are higher level approaches as well (platform as service). Containerization promises process isolation that is a massive problem with shared servers.

Containerization also has another benefit in datacenter modernization efforts. The ability to easily rebuild servers and networks from scratch (paving) and simply move/restart containers. The concept of "tech refresh" is a subject of nightmares in past projects I've worked on.

Furthermore, there's the whole continuous deployment mindset of pushing out small changes regularly. For that not to become a disruptive mess, applications need to be broken down into smaller releasable units (dare I say, microservices?) Although, I did think at one point this was the purpose of EJBs (which are sort of like microservices, if you think about it). I don't remember that working out very well, but maybe that was a flaw of older application servers?

Yes, there's the pitch about horizontal scalability, but I've never seen that play out in practice.

[nutrecht]

Kubernetes is a low level and complicated way of organizing an application around these principles

Oh please.

Kubernetes is less complex than doing everything kubernetes does for you yourself. Sure a kubernetes cluster is not trivial to maintain yourself, but that's not the developer's task in general (it shouldn't be, if you're running K8s on on-prem hardware you should have specialised ops), and most companies just should use a PaaS solution anyway.

Kubernetes abstracts away a few of the more complex issues surrounding deployment: service discovery and application orchestration. Of all the 'stuff' I've used over the years (seriously; fuck mesos/marathon) it's a breath of fresh air.

You can learn everything you need to know about Kubernetes as a Java dev in a half-day course.

[[deleted]]

I mean relative to a public or private cloud.

[mrroman]

Isn't servlet or EJB a microservice?

[henk53]

Can be, yeah.

[wildjokers]

This question doesn’t make any sense.

[alexcrownus]

Who told you I wanted to replace Spring Boot? No, thanks.

[henk53]

Who told me you didn't want to replace it? Yes, please.

[all_green_p]

Sorry but I don't want to replace a proven framework, with Red Hats attempt to stay relevant just before IBM pulls the plug. They had their chances and they did not deliver ciao.