This is the first installment in a “Monolith to Micro” series of posts. These posts will follow a typical journey from moving from a monolithic architecture to a microservice-like architecture. In this installment, we will take a look at some of the cautions in this migration that should be taken into consideration.
Are Microservices for You?
The first question to ask is hopefully the most obvious. Are microservices for you? On top of the technical challenges of microservices, they also need a certain cultural shift as well. These cultural changes can many times be the hardest part of a migration. At the same time, it would be folly to take a leap into microservices, with all the hard changes required, if this architecture cannot actually benefit you.
Let’s start with some of the major benefits that a microservice architecture should enable. Take a look at if these are requirements for you, simply “nice-to-haves”, or even not beneficial at all.
- Team Independence
- The strict boundaries between microservices enable teams to work on and adapt their services independently of other teams.
- Small, rapid change
- Because microservices should be, well, micro, they can change very quickly because each service should have relatively low impact. While individual changes are faster, each change is small, and you may need many changes to get to what might be considered a “minimum viable product”.
- Contained Complexity
- While many other places may list “simplicity” as a benefit of microservices, I think this term fits better. Distributed system and simple do not tend to go together. But the draw for microservices is that the business domain is split into manageable chunks.
- Organizational Clarity
- It becomes very clear who owns what in a microservices wold. It gets very murky as to who may own the various pieces “between” services.
Of course all these items also come with downsides. We will dig into some of those next.
The Dark Side of Microservices
Because “microservices” is still a hot technology buzzword, many places still gloss over the pain points of this architecture. Focusing on the benefits listed above, each one has downsides that can be directly related.
- Team Independence
- Silos of knowledge. While teams can become experts in their own areas, they can easily be novices in other areas. Centers of practice/excellence and robust Architecture teams can help offset this.
- Dependency hell. Because teams can move independently, they will. It is easy to see what can happen when team A upgrades something that team B uses, and wishes to deprecate the thing team B does, but team B has no capacity to change this within a reasonable timeframe.
- Small, rapid change
- Probably the biggest downside to this is organizational. Sometimes Product has a hard time with these small changes. Some product features may need to span multiple services, and the organizational politics involved with multi-team coordination can be difficult to navigate. The microservices architecture can sometimes “bleed” up into product stories and start diluting the actual intent of the stories.
- Contained Complexity
- There will be complexities that live somewhere. A noticeable issue here is either with shared code, or duplicate code. There will be some similar problems across services, and they may need similar solutions. Do you bite the antipattern of sharing code in microservices, or the antipattern of duplicating code?
- Organizational Clarity
- One of the “enablers” for microservices is a “you build it, you run it” mantra. However, this tends to leave out the global, or shared, services. Who manages the network? Who provisions VMs? Moving to a cloud platform can help answer those questions, but what permissions do developers really need? Who gets called when the “site” is down?
Organization
The last bit to look at would be if your organization is ready, or at least amenable to a microservices world. Many “prerequisites” should be in place before a step into microservices. Teams should already be agile. Continuous delivery, to somewhere, not necessarily prod, is required. A strong testing mentality and practice, from unit tests to integration to “user journey” tests, needs to be in place. The “business” also needs to have a strong view of the business domain.
And, of course, you need to have a team of amazing Architects that can help pull everything together!