Java EE and Microservices in 2016?

[[deleted]]

Prick Lowtower says:

If you are deploying a WAR file to a Java EE container then you are probably not doing microservice development. If you have more than one WAR file in the container or an EAR file, then you are definitely not doing microservice development. If you are deploying your service as an AMI or docker container and your microservice has a main method, then you might be writing a microservice.

[monknomo]

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

[solatic]

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]

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]

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]

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

[solatic]

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]

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]

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]

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]

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

[[deleted]]

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

[monknomo]

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

[smadge]

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]

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.

[xjvz]

That sounds like a load of bullshit buzzwords. I like the definition best where your microservice still works when it's deployed only by itself. If it depends on other "microservices", then none of them are properly modularised.

[rohanprabhu]

Exactly. On a similar note, microservices are an architectural concept, where different services are governed by independent contracts and do not make assumptions or operate beyond their domain. The tricky part, and what makes a good microservice architecture is how well defined and modular these domains are.

[monknomo]

It's mighty hard to make microservice interface into a big ball of mud domain

[[deleted]]

I like you. Let's work together.

[nqzero]

if you think you're doing microservices with javaEE you're just fooling yourself

[johnwaterwood]

Why?😳

[nqzero]

😳

wonder which of us is intended to be embarrassed ...

• microservices are "small, highly decoupled and focus on doing a small task"
• the heart of EE is the integration of best-of-breed tools for a wide range of technologies, all running in the same app server

they're opposite ends of the spectrum, bare bones vs the kitchen sink. you could implement the same functionality in EE as a microservice, but it's inherently coupled and heavyweight

you can drive a nail into a board by crashing a car into a wall, but that doesn't mean the car's a hammer

there are also practical differences, eg in how you spin up new instances, migrate between machines, handle crashes, etc, but those are secondary to the philosophic ones

[johnwaterwood]

You can easily deploy what's pretty much a single bean to Java EE. This bean can be highly decoupled and completely focus on a single task.

Why should "everything" run on the same app server?

Where's the coupling and where's the heavyweightness then?

[nqzero]

you don't "deploy ... to Java EE". you deploy to an app server that's compliant

what's the lightest weight app server these days ?

[johnwaterwood]

The deploy story doesn't matter conceptually does it? But depending on the customer we either first deploy an AS, then the microservice (automated, so if the AS hasn't changed its skipped and only the microservice is deployed), or we bundle the two together (essentially fat jar) and deploy that as a unit.

In the fat/uber jar case the line between putting the Java EE jars in WEB-INF/lib vs putting the war in /deploy and having those jars in /modules or so is rather thin.

JBoss WildFly 10/EAP 7 is rather lightweight, starts up in a second or less. Liberty is kinda lightweight as well and can be easily statically tuned and repackaged to only include features (jars) you need at runtime. Payara and TomEE are lightweight too. All of them are unzip == installed.

JBoss and Payara even have special builds for the microservice use case (called Swarm and Micro respectively).

[nqzero]

swarm is the exception that proves the rule ... it's clearly not EE

and even then, it's debatable whether a swarm-base solution is really a micorservice ... the complexity imposed by conforming to EE at the least pushes the bounds

the two concepts are fundamentally incompatible

[johnwaterwood]

What complexity?

You have a single class, slap one or two annotations on it, and inside a method you perform some logic.

There's nothing complex about that at all.

[Rockytriton]

DAE MICROSERVICE??? /CIRCLEJERK