Microservices: how to develop ?

[Claude Moore]

Microservices are definitely gaining a lot of interest and momentum in IT community. While I was able to find literally tons of documentation, tutorial, examples about developing one single microservices, I cannot find anything about developing a whole, complex application based upon microservices.
While is pretty straightforward to deploy a single microservice in Docker, or play with Spring Boot, with Node.js, or with NancyFx for .NET, I wonder how one could organize a large program, what are best-practices and so on.
For example, if all microservices were Spring Boot based, I could image to launch  all of them within the same IDE (for example, using Spring Boot Dashboard). It would pretty the same if I had a traditional EAR application.
But what about if the whole application used different technologies and languages ? As far as I can guess from what I read about MSA, using docker + kubernetes seems to be the only way to go.
Could you provide any suggestion / hints ?
Thanks in advance !

[Marco Behler]

Hi Claude,
probably not the answer you would like, but:

In one of my last projects, we had 19 (!)) microservices. Orchestrating these microservices, i.e. booting them up for an integration tests, or from inside your IDE for manual testing was a real pain. Let alone having enough memory on the Jenkins server to run builds in parallel (feature branches, main build etc). And luckily enough they were all just written in Java, NOT different languages/technologies ( this utter mess inspired me to come up with the "Microservices: The Good, Bad & Ugly screencast series on my site)

My suggestion is, if you start out with a "new application", greenfield, than start out with a monolith. Nothing is crazier than starting out with a microservice approach right away. The complexity in deployment/testing/ops is just unreal. And that complexity unfortunately noones talks about.

My 5 cents

[Claude Moore]

Hi Marco,
thanks for your answer. Yeah, you're right, answer you provided isn't the one I would have liked to hear, nevertheless it's one I guessed I would have heard. Apart the "very pain" you described in having a local development enviroment, there is another concern I have about MSA: I wonder if Java - no
matter the framework you are adopting - is well suited do develop microservices. I have read - and personally experienced, even with toy services - that running java microservices consumes a lot of memory. For example, for Spring Boot based microservices I usually reserved about 512 MB per service, and the most of
such RAM is eaten up by JDK + spring fx classes. I currently work to develop and extend a pretty big Java EE application (with +50 EJBs and at least 5,000 service classes) running on a traditional appserver (4 core, 8 GB, at least 200 users). How much memory and CPUs  would be required to build the very same features in a microservices based application ? Lot of services imply lot of memory.
Moreover, since MSA is an architectural style, I wonder why I could not simply create a single WAR module for each microservice, and deploy them in a local instance of , let's say, Wildfly or Tomcat. I understand the risks associated with this approach - a malfunctioning service may compromise other services deployed in the same java container, requiring a reboot of the application server. But on the other hand, I could save much memory, it would be much easier to develop locally, and if I really need to containerize my services, I could create fat jar instead of war artifacts very easily via Maven.
What do you think about ?

[Marco Behler]

Hi Claude,
let me split up my answer.


a) The Spring Boot camp did some performance measurements a while ago, https://spring.io/blog/2015/12/10/spring-boot-memory-performance , an in theory you could probably keep the memory overhead quite small-ish, but then again small (as in 128mb-256mb) STILL adds up over time + old legacy applications usually have no small memory footprint.

b) I don't really see the point of creating multiple .war-modules and deploying them in the same container like tomcat. Your scenario is definitely a possible case, but here's what you should think about more (seen that MULTIPLE times in production). Usually, your microservices will talk REST to each other. And usually your http client uses a thread pool. Now when A calls B, and B , for whatever reasons hangs or delays all calls -it does not quite crash, but it just takes 50seconds to return a response. Then your thread pool from A will get saturated and _also_ not be able to process any other requests anymore. Which basically brings your whole service chain down. So there will be a multitude of problems, no matter if running in the same container or in fat jars.

c) i haven't mentioned versioning the microservices yet, and then it becomes real fun.


My actual point being: What problem are you trying to solve? What pains are you having?

Microservices make sense, if and only if, you have a huge legacy monolith (which you seem to have) and are able to carve out functionality, that could entirely exist in its own domain, without your monolith. (think, "billing system", or "analytics".) Splitting out anything else just for the sake of it is like swapping the "extract method" refactoring with the "extract microservice" refactoring - just with a ton more pain.

[Claude Moore]

Hi Marco,

here some points:

Marco Behler wrote:

b) I don't really see the point of creating multiple .war-modules and deploying them in the same container like tomcat. Your scenario is definitely a possible case, but here's what you should think about more (seen that MULTIPLE times in production). Usually, your microservices will talk REST to each other. And usually your http client uses a thread pool. Now when A calls B, and B , for whatever reasons hangs or delays all calls -it does not quite crash, but it just takes 50seconds to return a response. Then your thread pool from A will get saturated and _also_ not be able to process any other requests anymore. Which basically brings your whole service chain down. So there will be a multitude of problems, no matter if running in the same container or in fat jars.

That's true, indeed I was not suggesting that deploying all microservices within a single Tomcat (or any Java containers) would solve any problem; maybe, it could alleviate problems related to having to deal with multiple containers (docker containers) just while developing.
You mentioned an application made of 19 microservices. I suppose that everyday you had to start 19 containers, and any time you need to update a service after modifications, you had to update the corresponding container. Looks cumbersome.
If all your 19 modules where simple WAR modules, you could simply start your local Tomcat instance and enjoy Tomcat's hot redeploy.

Marco Behler wrote:
My actual point being: What problem are you trying to solve? What pains are you having?

Honestly I'm investingating microservices only for sake of knowledge, I just think it's something any senior developer should know.

Marco Behler wrote:
Microservices make sense, if and only if, you have a huge legacy monolith (which you seem to have) and are able to carve out functionality, that could entirely exist in its own domain, without your monolith. (think, "billing system", or "analytics".) Splitting out anything else just for the sake of it is like swapping the "extract method" refactoring with the "extract microservice" refactoring - just with a ton more pain.

Fully agree.

[Marco Behler]

You mentioned an application made of 19 microservices. I suppose that everyday you had to start 19 containers, and any time you need to update a service after modifications, you had to update the corresponding container. Looks cumbersome.
If all your 19 modules where simple WAR modules, you could simply start your local Tomcat instance and enjoy Tomcat's hot redeploy.

Actually we weren't containerized. Some of the microservices were running as fat-jars, some were local tomcat instances. Of course, most of them were clustered and load balanced, so x2 the instances.

Honestly I'm investingating microservices only for sake of knowledge, I just think it's something any senior developer should know.

Yup, and I hopefully didn't come across as too pessimistic

[Tim Holloway]

There's no virtue in designing an app out of microservices just to say you did it. As noted above, there's a great deal of pain that comes with trying to ride herd on a program that's fragmented all over the landscape.

Where microservices get useful is when you have a small unit of work that either runs essentially stand-alone or could benefit by running multiple instances, or is best executed on a different machine, or can be shared by multoiple applications where it's not beneficial to simply bundle a copy of the service in each application.

Containerizing something doesn't make it a microservice. I have my Jenkins and Nexus servers in Tomcat containers and they are full-fledged services in their own right. On the other hands, I have a Docker container that contains an Apache ServiceMix server and it has several microservices within it. One scans a daily email of supposed "remote" jobs and removes all the postings that actually say things like "This is not a remote position" before posting it to my inbox. Another one looks at bulletins from the National Hurricane Center and makes them more readable. A microservice might be a web services app in a Tomcat server. A good example might be one that checks (encrypted!) requests containing a user ID and password and returns whether they are valid. This could be a web service microservice that might be invoked by custom security Realm.

A microservice defines itself by being something that's part of one or more larger somethings where there is benefit to not simply including that smaller something into the large somethings wholesale.

[Claude Moore]

Tim Holloway wrote:There's no virtue in designing an app out of microservices just to say you did it.

That's ok Tim, but to get some experience, you need to do practice. And to do practice, I personally need to play with a "toy" application. No matter if microservices were or were not the right choice for a given scenario.
I would not use MSA just to use the latest cool approach, at least not in a real world application. It's really  interesting to see that both you and Marco pointed out that using microservices bring a good dose of pain, that they're difficult to manage, and so on; reading about microservices I learnt that they have to be loosely coupled, that they have to rely upon some discovery service, they must not rely of availabilty of other services, they should have their own database.. a big portion of troubles.

[Marco Behler]

I learnt that they have to be loosely coupled, that they have to rely upon some discovery service, they must not rely of availabilty of other services, they should have their own database.. a big portion of troubles.

Yup - in theory. In practice, this is basically going down the painful, crazy road  To me, microservices, as they are being marketed, are indeed nothing more than "the diet of the month", let's say the Paleo diet. And the terms "loosely coupled" and "own databases" makes we want to jump out of a window to be honest.

Other than that, I can pretty much second everything Tim said.

If you want to play with it, simple create two or three Spring Boot applications, that talk rest with each other, and their own databases. Then do the same thing, but from 1 main class ;) (this is pretty much what I demonstrated in my screencasts...from 1 app -> 2 apps).

And that already will let you feel some of the pain and give you some good experience.

[Claude Moore]

Maybe as often happens in IT, an innovative approach like microservices needs to be really proven in real world scenarios, or, more simply, needs to be 'adapted' applying more practice and less theory.  The "own database" pattern for example as Marco noticed seems actually excessive; service discovery makes me to remember UDDI services in SOA world - who ever really used them in a relatively small / mod sized projects? and so on... Years before microservices, OSGI services (thought limited to a Java world) imposed a loosely coupling discipline among parts of an application, solving potentially some problems monolithic applications suffer. But Osgi wasn't so much merchandised, so nowadays it doesn't enjoy much hype.