Seems like every 5 to 10 years our industry, especially in the Enterprise Integration, or enterprise application space, we get introduced to some new methodology or architectural style thatâs the best since sliced bread and will make you 10x more productive and make your enterprise more agile, flexible, able to respond to change, and whatever else that CIOs are willing to spend gobs of money on. Weâve seen Enterprise Application Integration, Web Services, SOA, Component based architectures, ESBs, and on and on.
Today: Microservices
Well, guess what: chances are youâre not going to get microservices architecture right.
Honestly, Iâm not saying that to dump cold water on your burning desire to try out new things. I do think there is legitimacy to microservices and itâs an approach that grew organically over the years of watching failed committee-driven implementations. But guess what? There is a foundation of pre-requisites that must be in place first beforehand to be successful with this architecture (or any architecture 
) that, based on my observation, is lacking at more places than itâs prevailing. By all means, fire up Spring Boot or Dropwizard, or no container. Youâre not doing microservices just because youâre following the lemmings away from the App Server. Places like Netflix, Amazon, etc seem to have some of the right combination of pre-requisites to make it work⊠But ask your VPs of engineering, ask your Directors of computing what they would say if their internal teams were organized like Amazon. They would spoil their pants. Your company probably doesnât and probably wonât get microservices right.
Most organizations are not structured for microservices
We all hear about Conwayâs law, but this fact is the strongest reason why youâre not going to do microservices. People win. Culture wins. Paper processes and paper structure does not win. If you have a UI team, DB team, âservicesâ team, each specializing in its own right, youâll end up with systems that look like those tiers. Thereâs nothing wrong with that per-se. But a tree-like structure and layers of managers above technological-grouped teams is an impediment to microservices-based teams.
REST is not a silver bullet
REST is great! I like the concepts, and that for enterprises itâs basically the HTTP implementation we talk about. Iâm happy to get away from SOAP. HTTP and REST is understood, has great tools, networking equipment, proxies, etc are all built with it in mindâŠBut REST is not a silver bullet.
Modularizing applications is hard
How big should the service be? How deep should it be? Single responsibilities? Domain Driven Design bounded contexts, etc. This is all difficult to get right in practice. Doing it a few times and failing is the best (in my opinion) way to learn how to avoid the sharp edges, but properly modularizing your applications and your domain services is not easy.
We still donât understand how to do event-based architectures
Why are we still connecting everything by RPC!?!? This one aggravates me the most that we still donât know how to do Event driven architectures correctly, and that when a ânewâ architectural style comes about, we relive all of the same mistakes we did with the previous. BTWâŠ. Microservices != REST.
Alright, this was a bit of a complain session, but just wanted to bring some reality to the discussion around microservices.
At the end of the day, isolating âservicesâ or systems at the process level is still not really loose coupling or âdecoupledâ systems. Runtime coupling is still very much present and maybe even more so. Never mind that the Fallacies of distributed computing still hold true. So maybe when we re-invent architectural styles, we frame them within the lessons learned?
| Reference: | Youâre not going to do Microservices from our JCG partner Christian Posta at the Christian Posta – Software Blog blog. |
