Monoliths, Microservices, and Microliths

I was speaking with JJ Jeyappragash (Twitter?and?LinkedIn) and Varun Talwar (Twitter?and?LinkedIn) and found we had some similar ideas on the topic of microservices. Microservices are the bread and butter of Tetrate, Istio, and Envoy, but are they always the best solution? We felt the answer is no, but that has qualifications.

Monoliths are bad. Microservices are good. Now that’s been declared. But let’s explore.

Monoliths are easy to get started with, easy for infrastructure management, and so long as your team and codebase is small it’s easy enough to manage. But it doesn’t scale technically, people, or process-wise. The more code you add, the more you have individual service spikes, the more your infrastructure bottlenecks and increases in cost. The more developers you add the slower your delivery due to commit conflicts, defects cross impacting, and processes to orchestrate amongst the sizable team.

Microservices require more planning and infrastructure overhead but scale phenomenally, both technically and the people process of development. You can keep adding new services, your code for any particular service is pretty small and contained. You don’t usually need to add very many people to a single service, you scale horizontally with new services. It works wonderfully, but it adds complexity. You mitigate the complexity with technologies like side cars and a service mesh but you’re still dealing with this deployment overhead and the transactional boundary complexities.

Now what is this about a “microlith”, the monolithic microservice? Microliths are essentially domains in DDD, a collection of capabilities for a particular set of entities creating a bounded context. By deploying fewer service domains we reduce the total complexity of delivery yet embrace the impact of a slightly larger code base & impacted delivery model. Microliths are deployed like microservices (preferably with a mesh) but have the advantage of increasing simplicity of cross-code calls while having the detractors of larger codebase and (for both good and bad) combined compute & disk for more than a single endpoint.

Consider a simple Customer model: Demographics, Address, Payment (credit card, etc.), Purchased Product(s), etc. In the microservice model each of these are independent services. They can scale independently, deploy with little ceremony, have their own build pipeline, etc. But this also means we have to manage unique configuration for firewall, logging, application server, database, etc. We also get the complexity of transactional boundaries (e.g., creating a customer & address at once is not easy if a rollback is required). With lots of little compute & database instances, we pay more than we would with fewer sized instances. Is it worth it? That’s the key question to consider when developing microservices or microliths. The answer is simple: sometimes.

Should I create a microlith for the Customer domain? It will simplify transactional boundaries. It will require fewer servers, fewer network routes, certificates (an evil by itself!), etc. The key question to ponder here is: how big is the domain? Does it need the purchased products? Does a customer exist without such an entity? If the answer is yes then break it out. If no keep it conjoined and deliver the multiple features into a single deployment package…a microlith.

To embrace a microlith is to embrace one set of complexity in favor of another. It is contained unlike a monolith. It simplifies the domain model and the interaction between the entities versus a series of microservices. It costs less for compute & database but can also run into contention for those same resources. It eases development for everyone working on the domain, but adds overhead of coordinating patches, releases, etc. Every negative is an emphasis for keeping the domain strictly constrained yet more comprehensive the domain is the more it mitigates the concerns while embracing the advantages.

The right answer, of course is all three. Monoliths are great for POCs and first-version software that you know you are going to rewrite. Microservices are great for technical and process scaling, embracing simplicity while creating some complexity. Microliths are great for bridging the two, a very small domain that is technical and process scalable, reduces some of the service management complexity while eliminating the monolith’s overhead.