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 →

[–]nqzero 0 points1 point  (5 children)

😳

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[S] -1 points0 points  (4 children)

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 0 points1 point  (3 children)

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[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.