Aristotle's golden mean can be a powerful driver in good software design. The summary of the golden mean is that you get to pick a point (not necessarily a statistical mean/average) between two extremes (excess and deficiency). Software design can be quite subjective, significantly more often than not, when engineers tend to cling onto their comfortable/favorite theory/practice.
You can create multiple competing models and accept one and reject others to help us achieve the golden mean. When should you go for microservices, and how much is under/overdoing? A list of questions helps to drive such a discussion in the team.
How these patterns are generally seen?
Monoliths often looked as legacy: Should you keep all API endpoints, workers, and resources into one massive project because creating microservices left and right is a huge headache, maintenance, and cost implication? Should you remain less collaborative and not make some part of the monolith independently reusable?
Microservices often seen as a validation for good design: Should you create a microservice that has only 1-2 API endpoints? Microservices promote share-nothing philosophy. Should you create an entire database for 1-2 tables instead of reusing existing ones? Should you keep one microservice from talking to another's database religiously? Should so-called design purity triumph the practicality of daily deployment, support, and costs?
How to be less wrong?
The correct answer to how to be less wrong is whatever answer you feel good about, as much cliche as it sounds. If you search for the answer, you will get it. It requires a little bit of exploration.
However, if you don't explore and jump into coding, beware of the forthcoming expectations mismatches, firefights, compliance nightmares, interoperability issues, and burnouts. But, how do you create competing models and find an answer you feel good about it?
The solution proposals
Come up with some combinations of monolith and microservices. My favourite model is start with a core monolith and branch out to microservices when it warrants a different genre (HR module in an e-commerce storefront) or different compute behaviour than the most of the monolith.
- Model A: Extreme monolith, all code must be in a single service promoting complete control
- Model B: Extreme microservices, create smallest possible microservices promoting ultimate flexibility
- Model C: A well-defined combination of some microservices and one monolith
- Model ...: Another well-defined combination of some microservices and one monolith
- Model Z: Another well-defined combination of some microservices and one monolith
The design worksheet
Here's an example worksheet to navigate (in one way) which combination of monolith and microservices is the right combination for you.
|What is the number of different runtimes/stacks to deploy?|
|What is the number of different programming languages/frameworks used?|
|What is the expertise level of the team in the chosen frameworks?|
|Is it purely a design effort or an attempt to retrofit the solution in a favourable cloud provider's supposedly "magic bullet"?|
|Should microservices share databases? Explore pros/cons.|
|Is complete shared-nothing practical for the problem being solved?|
|What is the cost:benefit of shared-nothing approach?|
|From the maintenance perspective, do you have enough workforce to deal with the service dependency (hell)?|
|What would it take to maintain architectural sanity for the services (security, communications, separate logging, environments, storage, caching, etc.)?|
|What is the total performance? Consider communications overhead.|
|Is there any better way to increase reasonable performance without increased cost?|
|What is the scaling plan? Who is being deprived and where is the waste?|
|Is there any better way to optimize scalability without increased cost?|
|What is the cost of change across the services?|
|Is there any better way to reduce cost of changes in the proposed model?|
|What is the current and future cost of conformance to compliance and documentation?|
|Does this model support future inexpensive ways to meet/exceed compliance expectations?|
|What are the benefits of the silos (possibly due to microservices) in terms of cost of change and maintenance?|
|What are the negative impacts of the silos (possibly via microservices) on cost of change and maintenance?|
|What is the cost of security (e.g. new design/deployment, patches, cybersecurity, etc.)?|
|How can security be made inexpensive in the proposed model?|
|What are the conveniences/challenges of VCS and CI/CD management for this model?|
|Is the degree of context switching while coding for multiple services tolerable?|
|What would it take to make the context switching for developers more tolerable?|
|What is the billing implications of compute, network, storage, licensing and rate limits?|
|Does this model leave room for improving billing situation in the future?|
|How does this model thrive in favourable conditions? E.g. increase in external factors headcount, resources, time|
|How does this model get challenged in unfavourable conditions? E.g. decrease in above|
|Why is this model a nightmare?|
|Why is in this model everybody wins?|
You ask all these questions in your brain daily, but this gives you a basis for the minimal thought exercise and reference you need in the future to say that you didn't jump into code based on interests, ego, whims, and other motives. Instead, you made an educated design that saves time and money and offers sanity and tranquility, etc., and doesn't get in the way of growth.