3 questions to ask in a microservices oriented architecture review
Microservices oriented architecture is all the rage these days. Why not? It’s hard to ignore the faster deployment rates and reduced costs that are the essential promises of microservices oriented architectures.
Yet for most companies that take the plunge, development activity is more about the transformation of an existing monolithic application into a microservices oriented architecture, which can be a source of frustration and conflict on many levels.
While greenfield microservices oriented architecture implementations can adhere to the strict interpretations of current microservices-design principles, the decomposing, legacy applications in a microservices oriented architecture live with shades of gray, if for no other reason than to satisfy budgetary and time constraints.
Somewhere in the corporate food chain, there is a business executive who looks at the decomposition costs associated with these legacy apps within a microservices oriented architecture, and compares it to the value already provided by the legacy code. Once the development costs exceed the perceived benefit, the business exec might very well pull the plug and cancel the project.
This happens. A lot.
Thus, development managers are under enormous pressure to get the code out the door as soon as possible. “Good enough” becomes the desired goal of the transformation.
Now, this isn’t necessarily a bad thing. The ability to ship working code is always preferable when compared to waiting for the dream to arrive. But, “shades of gray” is hard to manage and the problem in lies where to draw the line at “good enough.”
And so, the conflict begins. One side wants to ship things as they are and the other side wants to do more refinement.
For you, the challenge is to not let these different schools of thought create an endless fight over what are essentially belief-backed opinions. If you do, it will create a situation where no code gets shipped at all. Now, conflict can be beneficial to synthesize the best idea from many competing ones. But, it can be deadly when the discourse degrades into a never-ending conflict.
I manage these sorts of situations with discussions that focus on the following three questions to avoid such conflict:
- What is the justification for the design?
- What are the risks?
- What is the risk mitigation plan?
Allow me to elaborate.
What is the justification for the design?
When you evaluate the design of a microservices oriented architecture, the challenge is to move past opinion and onto rationale analysis. Its creation comes largely from the decomposition of a monolithic application. Any design might be “good enough,” provided you can justify its benefit and value.
For example, one of the preferred styles in microservices oriented architecture design is to take an event-driven approach to inter-service communication. Concretely, this means you use a message broker to pass messages between microservices in an asynchronous manner. However, while asynchronous communication is more flexible and extensible in the long run, message system implementation is more complex than a design that uses synchronous HTTP calls between APIs that “fronts” the microservices. Thus, when time-to-market is a concern, it’s entirely justifiable to refactor a feature in a monolithic application as a standalone microservice that’s represented by way of an HTTP API.
Synchronous microservices are usually less complex to implement than asynchronous ones.
Synchronous communication isn’t necessarily the optimal choice for the long run, but given all the other work required to get a standalone microservice extracted out of a monolithic application, synchronous is “good enough” for the first release. Hence, a valid justification.
However, this isn’t to say that a synchronous approach is without risk. In fact, there are many risks. When it comes to review a microservices oriented architecture design, justification alone cannot be the only factor. Risk must be articulated too.
What are the risks?
All designs have inherent risks. In the synchronous design example described above, this approach to inter-service communication can incur a risk of type coupling between services, increased latency due to the nature of synchronous HTTP communication and others.
The important thing is to make the risks known so they can be weighed in terms of the justification for the intended design. If the risks are overwhelming, no amount of justification will suffice. On the other hand, some risks might be acceptable given the demands at hand. The trick is to make sure that risks are clearly communicated as part of the review process. A known risk under discussion is always preferable to a hidden risk that can strike down the road. Also, if you know the risks before, it allows you to plan how to better move forward in future versions as the microservices oriented architecture matures. This is where risk mitigation comes in.
What is the risk mitigation plan?
A sign of a wise application designer is an ability to identify their design risks and then have the vision to articulate a way(s) to mitigate those risks once identified. Risk identification without proper mitigation techniques is a sign of incomplete thinking.
If a microservices oriented architecture design has risks galore and marginal plans to address them, then the design team needs to give serious consideration to its viability. Also, if the mitigation plan is impractical — beyond the expertise and budget of the project — the design’s viability needs to be questioned too. It’s all a matter of balance.
A well-balanced microservices oriented architecture design is justifiable in terms of the conditions it’s intended to satisfy weighed against its inherent design risks and the mitigation plans intended to address them.
Put it all together
Conflict is an essential part of the creative process. Highly creative people tend to have tenacity about their ideas. So, when you put them in a room and ask them to come up with a single design for a microservices oriented architecture, tensions are bound to rise. That’s how it goes. But take heart! Conflict is good.
Fortunately, with a rational approach to review a microservices oriented architecture design with the three questions I described above, you can foster objective discussions that produce software to meet your needs in a timely manner. No design will ever be perfect, particularly those that are a decomposition of a monolithic application. But, there is a significant benefit in the delivery of a microservices oriented architecture that’s good enough to be operationally effective in the short term and flexible enough to continuously improve in the long term.