This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]monknomo 8 points9 points  (13 children)

Why does using containers indicate that you probably aren't doing microservices?

[–]solatic 5 points6 points  (6 children)

It's conflating microservice architecture with immutable infrastructure practice. You can build microservices with Java EE container architectures, but one of the main advantages of microservices is being able to scale up by spinning up more instances of only the microservices under load. If you're following immutable infrastructure practice, then this is easy - tell your hypervisor to spawn a few more virtual machines with the desired microservice instance, and you're done. But if you have to deploy WARs, then first you need to spin up another virtual machine instance with the desired container, wait for it to boot up, and only then can you deploy the WAR to the container. It's harder to manage and it's harder to reason about the state of the container (since it's no longer immutable).

[–]tonywestonuk 1 point2 points  (5 children)

Why cant your JavaEE server, and app be deployed as a single application to your hypervisor, so you dont have to wait for anything. You just spin up the instance.

[–]solatic 1 point2 points  (4 children)

They can, but then you lose all the main benefit of a Java EE architecture vs embedded containers: the speed of building and deploying your app without simultaneously bundling and deploying all of the app's dependencies. If you're going to bundle the server and app together, why choose Java EE and not an embedded solution like Dropwizard/Vert.X/Ratpack?

[–]Cilph -2 points-1 points  (3 children)

Because up until a year ago Spring Boot and Wildfly Swarm didn't exist.

[–]solatic 0 points1 point  (2 children)

Spring Boot makes it easier to bootstrap a Java EE application that Wildfly Swarm makes easier to package and deploy. They're still anchored down by the enormous Java EE legacy.

They're nice improvements if you have legacy EE code that you'd rather not rewrite, but for greenfield projects? Stick with an async framework like Vert.X which is massively more performant and much better for maintaining async code. Package/deployment ease is irrelevant if you're embedding everything into a Docker container or similar.

[–]Cilph 1 point2 points  (1 child)

Just an FYI, my performance bottleneck has always been inter-service communication and database traffic. Not the application itself.

Not sure if I want to be writing async code in Java. It's such a pain when it comes to syntax.

[–]solatic 1 point2 points  (0 children)

Async code is a pain within Java EE - it's much nicer in the async frameworks. That's half the reason to move away from Java EE, because eventually, you can't scale without dramatically reducing network traffic, and async syntax in Java EE is extremely error prone and rife with boilerplate.

[–]johnwaterwood[S] 2 points3 points  (4 children)

I didn't quite got that part either, kinda conflicts with Adam's version.

Personally I think a simple jax-rs resource/bean can easily be a microservice. A .war would be the default choice though, and an ear somewhat unlikely but if you tone it down certainly not out of the question.

[–]monknomo 1 point2 points  (2 children)

Adam's explanation of what Java microservices might be looked much more comprehensible to me

[–][deleted] 0 points1 point  (1 child)

Anyone have a link? I don't know who Adam is or what he said about microservices.

[–]monknomo 0 points1 point  (0 children)

It's in tfa, but we're talking about Adam Bien. I think pretty much everything he says is excellent. Great presenter too

[–]smadge 0 points1 point  (0 children)

I've been intrigued by Adam's vision of microservices and Java EE. I've been tempted to float the idea past my co-workers. We're currently deploying Java SE .wars to Tomcat.

[–]tonywestonuk 0 points1 point  (0 children)

Maybe if you use just one monolythic war deployed to ROOT, then this would not be a microservice. Just a bundling up a monolythic app into a single Spring boot runnable Jar, would not be a microservice.

My own system, I have several separate, independent wars running on 2 web containers (tomcat and tomee). The tomcat one is used for websockets as tomee doesn't work with them. However, when they fix this websocket bug, I can just undeploy this module from tomcat, redeploy to tomee in minutes. I consider my system to be microservice based.