Traditionally, a monolithic system means a single deployable application that contains the logic to serve different aspects of an end-user-facing enterprise application. But with cloud services like AWS, Azure, and Google cloud overtaking traditional infrastructure, even a mid-sized startup has micro services deployed.
Heard of teams that are simplifying their architecture by breaking it into microservices?
Microservices are often presented as a one-stop-shop solution to solve the problem of non-agility that is inherently present in monolithic systems. However, even after spending many SDE years building microservices, teams are frequently unable to achieve the agility they desire. Due to the advent of cloud services, most modern systems are built on a set of microservices but are not flexible enough to meet new customer demands. These types of systems are called distributed monoliths. These systems deceive even experienced developers that their teams are moving in the right direction to simplify the architecture. But what they achieve in the end is an increased number of services to manage without the desired benefit.
The objective of this article is to save crucial SDE hours from getting wasted on building micro services that don't help businesses. Most of this article contains my learnings while building and evolving systems for the world's largest fulfilment network at Amazon.
The objective of this article is to save crucial SDE hours from getting wasted on building micro services that don't help businesses. Most of this article contains my learnings while building and evolving systems for the world's largest fulfilment network at Amazon.
What is the solution to monolithic?
It's simple—not really. While working at Amazon, what I have learnt is that the solution to monolithic is to build non-monolithic systems and not just micro services. I strongly think that the reason why micro services alone couldn't solve the problem with agility is hidden in their name. The name "microservices" has too much focus on rewriting systems into smaller services such that teams lose focus on the primary reasons for doing the same.
Explained: Non-monolithic workloads?
Non-monolithic systems belong to a team that is laser focused on the key engineering excellence metrics instead of focusing on re-architecture to micro services. These teams are focused on optimizing their systems for four key things in the order of priority below:
- The workload is laser focused on enabling one and only one specific business capability, nothing more than that.
- The workload has very high unit test and integration test coverage with full CI/CD implemented.
- It could be owned by smaller but autonomous teams.
- Their workloads have no schema or data coupling with any other workload.
Non-monolithic workloads are about the engineering culture of an organisation along with well-defined characteristics of the architecture. In Part 2 of this article, I will write about bullet-pointed strategies for identifying and building non-monolithic systems.
