This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
The microservice approach is a great architectural choice when building software. A small collection of services keeps your system decoupled, lightweight, and independently deployable, making it easier to scale and integrate with newer technologies to target specific use cases.
That said, no architectural approach is a silver bullet that works for every situation. Microservices are hard, complex, and require engineers and tech leaders to adopt some radical ideas. You also need to go “all in” with the microservice idea or risk finding yourself building the dreaded Distributed Monolith.
Bottom line, you need to absolutely sure that your enterprise is ready for the microservice journey or it’s destined to be a very painful, costly one.
How do you know if you’re ready for this ride? It’s difficult to answer, as every project and enterprise is different, but as a general measuring stick, your enterprise should be able to satisfy ALL of the following criteria before getting on.
This may seem obvious, but you’d be surprised. The microservice approach is still relatively new and not clearly defined, so different people may interpret things differently. Or they hear one thing, but think of another.
Everyone in a leadership role should be in agreement of what microservices are, what problems they attempt to solve, their advantages and disadvantages, common pitfalls, and how they compare to an alternative monolithic approach.
This journey will be very challenging and test your resolve early and often. When things begin to go south there will be strong temptation to loosen the commitment to microservices and fall back to familiar territory. This is a common trap that can destroy a project, but it’s easily avoided if everyone at the top knows what they’re getting into and is committed to following through with it.
Conway’s Law is a phenomenon commonly associated with the microservices approach. The idea simply states that the systems that organizations design will most likely be modeled after the organizations themselves. In other words, if you have three teams building a system, you’ll most likely end up with three major sub-systems.
In a microservices world, the system is broken out into self-contained features, with teams owning the entire lifecycle of one or more features. So rather than have one team of the “database people”, and another of the “UI folks”, and another making up the “DevOps / System Team”, you’re better off having a representative of each category and assign that team a feature that they own end-to-end.
Microservices that are owned by several teams or contain cross-cutting logic is often a path to a Distributed Monolith.
It’s hard for a director to be comfortable with a system that’s comprised of several different languages, requiring dozens of different skillsets, operating systems and licenses. It’s even harder for them to swallow the fact that each team has total control of what they can/can’t do in terms of technology choices.
On the surface it seems risky, if not reckless, as well as costly. What if someone leaves? How can we replace someone on that Java-based team when all we have is C# people? Why does that team over there use that framework, but this team uses something completely different? Why is code being repeated all over the place? This is chaos!!
Actually, it’s not. Not exactly. But that anxiety is very real and stems from arguably the most common source of fear in all human beings – lack of control.
For microservices to work well, teams have to be in control of their own decisions and have access to monitor and maintain their own services. It’s the cornerstone of achieving the level of speed and flexibility that make microservices such an attractive pattern. If your leadership is not comfortable letting go of that control or giving teams direct access to debug their own services, stick to a monolith.
Forcing teams to use centralized libraries and common tech stacks slow things down and lead to, you guessed it, distributed monoliths. Not allowing a team to access their own services in production is also a common trap that is both unfair and frustrating.
Leadership has to trust teams to follow best practices and learn to relinquish some of the control they’ve been used to. It’s hard, trust me. But if they do, they will be rewarded with a flexible system and highly productive, happy engineers.
If Criteria #3 is “Leadership, give us freedom!”, this one is the “Now prove that you deserve it”.
I said it before, I’ll say it again – microservices are hard. You better have a platoon of highly-skilled engineers capable of building and maintaining pipelines, understand testing strategies, DevOps, and know how to debug an issue involving 3 or more services.
If your engineers are highly dependent on others to provide them tools and frameworks, or are incapable of debugging their own problems, you may want to reconsider this whole microservices thing.
As noted in the previous criteria, this pattern involves giving your engineers the keys. They better know how to drive or you’ll end up here.
One of the main benefits of microservices is independent deployability. Another is decoupling services. But if you have a system of 5 microservices, and all 5 need to be up and operational for an end-to-end test to pass, guess what you just built?
One of the biggest challenges I’ve seen when working with an enterprise transition to a microservices architecture is getting them to open their eyes to the fact that integration tests are a scam.
If you have an organization that simply cannot feel comfortable deploying code to production without seeing the whole thing work as a whole, microservices is not for you.
On the other hand, if you trust your teams, empower them to make their own choices, and learn to embrace mocking and consumer-driven testing with tools like Pact, you’ll forget why you ever had end-to-end tests in no time.