Editor’s note: This interview with Rahul Rai was recorded for Coding Over Cocktails - a podcast by Toro Cloud.
In a Cloud Microservices Market report, it was found that the cloud microservices market was valued at USD 831.45 billion in 2020, and it is expected to reach USD 2,701.36 billion by 2026. This is a clear indication of how microservices are currently driving the market, encouraging organizations to break their applications into smaller components and leave their "traditional" monolithic architecture behind.
However, before we dismiss monoliths entirely, cloud architect and author Rahul Rai argues how microservices aren’t a cure-all to the challenges and pain points associated with monoliths.
"In fact, in most of the cases, monoliths are a better design choice, and some monoliths, such as the single process [monolith] or modular monolith, have a whole lot of advantages as well." Rai says during an interview on Coding Over Cocktails, a podcast by Toro Cloud.
Rai added that it is much simpler to deploy a monolith, as it is easier to avoid many of the pitfalls associated with distributed systems. As a result, monoliths can have much simpler developer workflows.
But why do they have such a bad reputation?
According to Rai, monoliths have a bad reputation because "the application concerns [can become] poorly segregated, which makes it hard to decouple parts of the application, and for developers to deploy them independently".
"That being said, as a monolith grows, [it reaches a point of] diminishing returns – and one of the biggest advantages of microservices is isolation." he states.
How do we choose between monolithic and microservice architectures?
Rai advises that if the teams are very small and the application concerns are not massive, you shouldn’t start with building services for each and every concern.
"And more so if your team is very small. Don't start with microservices because developers would be better off focusing their time and attention on a single code base and deploying it together, rather than focusing on a ton of services and managing them." he added.
What teams can do instead is to create a well-segregated monolith first. And then, as the code base of that monolith grows, its domain specific concerns can be broken down into smaller modules.
Rai compares the process to playing with Lego blocks: "You start by putting all of these blocks together instead of building a single structure from it. But when the time comes, you can take a set of blocks and deploy it independently from everything else. And as the team grows and as the business concerns grow, start segregating them. But, you don't just jump with this idea that you will start off with microservices, even when the domain boundaries are not very clear and you don't know what you are going to do."
"So, microservices give you this benefit of experimenting with something. And, if it doesn't work out, you can throw it away." Rai explains.
The monolithic design can also be modular, as it can eventually be split into independent services, which then allows you to evolve the code base into microservices.
Nowadays, a lot of companies are adopting this kind of approach, where the monolith has become too unwieldy and too unmanageable, that they have to break it down into smaller, independent services.
The challenges associated with microservices
Most of the time, organisations are experiencing a difficulty with adopting microservices, not because of the technology per se, but because of the barriers that people tend to put up when going through change.
Rai echoes this by talking about Conway’s Law.
"Conway's Law states that any organisation that designs the system will produce a design whose structure is a copy of the organisation’s communication structure. But many people think that the organisation’s communication structure in Conway's Law represents the organisation hierarchy. However, it rather represents how the various teams and organisations communicate with each other."
He then adds how massive architectural representations of such organisations may be too complex and impossible to maintain.
However, using Conway’s Law in conjunction with Domain-Driven Design can actually help an organisation enhance its entity to create scalable and maintainable solutions.
Rai presents the following example:
"In an e-commerce company, teams may be structured around domain components rather than the application layers that they specialise. User interface, business logic, and database is not how teams should be structured – you can have clearly structured domains that you've set up teams across these domains. And then the teams won't need to interact with each other too frequently."
He states that such team layouts are very commonly employed by successful organisations, Amazon and Netflix for instance, that have implemented microservices.
Rai stresses that most new organisations that are trying to tackle a new problem do not fully understand the domains of the microservices that they want to make. This, he says, can be a very costly mistake to make.
As such, he advises segregating domains, which "might lead to solving some of the most complex problems of distributed computing in the future, for example, distributed transactions, data consistency, and latency."
"So, I recommend that organisations take some time to discover the domain using tools such as brainstorming workshops or domain discovery workshops before embarking on the journey to brave microservices." he adds.
Rahul Rai provides a more in depth look at microservices and how to facilitate communication between domains in this episode of Coding Over Cocktails - a podcast by Toro Cloud.
Coding Over Cocktails is a podcast created by Toro Cloud, a company that offers a low-code, API centric platform for application development & integration.
This podcast series tackles issues faced by enterprises as they manage the process of digital transformation, application integration, low-code application development, data management, and business process automation. It’s available for streaming in most major podcast platforms, including Spotify, Apple, Google Podcasts, SoundCloud, and Stitcher.
