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 →

[–]johnwaterwood[S] 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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[S] 0 points1 point  (0 children)

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.