Monolith to Microservices : Ep1 : Are you ready ?

Overview

Microservices are the services that have been modeled around a business domain that are independently deployable. Nowadays, Microservices architecture is becoming a hype, since most of the tech organizations tend to port or migrate their existing architectures into Microservices. This article is all about moving from Monolith to Microservices architecture. The key objective of this article is to educate the reader on the aspects and considerations that should be taken into account when moving from Monolith to Microservices architecture.

What is a Monolith?

‘Monolith’ is a one unit of Deployment. When all artifacts/binaries in a system had been deployed together, we consider it as a Monolith. Monolith architecture is usually portioned in two ways. Which are as the Technically Partitioned and Domain Partitioned.

Figure 1: Technically Partitioned Monolith
Figure 2: Domain Partitioned Monolith

Single Process Monolith

These are the most common type when discussing monolith, where all of the code is deployed as a single procedure. These single process systems, shown in figure 3, always end up reading data from or storing data in a database, as simple distributed systems since they could be processed in their own right. Additionally, a vast majority of the monolithic systems that people tend to struggle with are likely to represent these single-process monoliths.

Figure 3: Single Process Monolith- All code is packed in a single process

Distributed Monolith

A distributed monolith comprises multiple services. However, in the deploying process, this whole system has to be deployed together ( one of the main reasons behind this is shared databases). The definition of a ‘service-oriented architecture’ may be well met by a distributed monolith. Also in an environment where not enough focus has been placed on concepts such as hidden information and business functionality cohesion, distributed monoliths typically do try to emerge.

Third-Party Black Box Systems

As part of the migration effort, we can also consider some third-party software as monoliths that we may want to “decompose”. These could include things such as payroll, CRM, and HR systems. In this case, a common fact is that, since its software is already developed by other individuals, you don’t get the ability to change the code.

Is Monolith Bad?

Using Monolith is not bad at all. This technology was practiced for years and years. Pursuing this further, let us now move on to understand the usages and challenges which could encounter when using Monolith.

Usages

  • It is a much simpler deployment topology that could avoid many of the pitfalls associated with distributed systems.
  • It can lead to much simpler workflows for developers; can also greatly simplify monitoring, troubleshooting, and activities such as end-to-end testing.
  • Within the monolith itself, monoliths can also simplify code reuse.
  • With the user choices, it is much easier to work with monoliths.
  • If you are a startup, it is better to use Monolith in most of the cases than moving on to Microservices
  • If you need just crud operations monolith could be used when obtaining solutions.
  • When you have a limited functional application with a definite number of users (ex: On-premise application)
  • When your requirement is just a PoC or a Pre-Sale
  • When you are not sure about the future of the application

Challenges of Monolith

The monolith, whether it is a single-process monolith or a distributed monolith, is frequently more susceptible to the dangers of high coupling and low cohesion. This happens when they could get in each other’s way as you have more and more individuals working in the same place. Confusion may occur over who owns what, and who makes choices. These difficulties of confused lines of ownership are usually referred to as a ‘dispute of delivery’.

What is a Microservice?

It is crucial that we have a general, shared understanding of what microservice architectures, shown in figure 4 before we dive into how to work with microservices. As in the definition of Microservices, mentioned at the beginning of the article, Independent deployability is the principle where, without needing to use any other resources, we can make a change to a Microservice and deploy it in to production . It is most important how you treat your systems of deployments and sometimes it could be identified as a discipline you practice as well.

Figure 4 : Microservices

Why do you want to move to Microservices?

Before answering this question you could ask yourself these three questions.

  • Have you considered alternatives to using Microservices?
  • How will you know if the transition is working?
  • Do you want to scale your system with increasing number of users?
  • Do you need Elasticity?
  • Do you need to roll out bug fixes quickly?
  • Do you need high Resilience and Robustness?
  • Do you need to scale your development?
  • Do you have performance issues where you cannot solve in current architecture?

Microservices Tax

The following are some of the factors you need to consider if you are moving to Microservice architecture.

  • Service Discovery
  • Service Orchestration
  • Fault Tolerance
  • Circuit Breakers
  • Build and Deployment Automation
  • Testing Automation
  • Polyglot technical stacks
  • Technically capable teams

So when to start the Migration?

Apart from the technical feasibilities that I mentioned earlier, you should get support with the following items as well within your organization.

  • Developing a Vision and Strategy
  • Define short term goals
  • Communicating the change vision
  • Change organization culture (Try to get rid of dedicated teams for tech stacks. E.g.BA, Dev, QA, Support, IT, Infra, Deployment etc.)
  • Anchoring the new approach and culture
  • Identify the components for decomposition using one of the collowing techniques
Figure 5: Identifying the components for decomposition Ref :Monolith to Microservices by Sam Newman

CTO @ ZorroSign | Seasoned Software Architect | Expertise in AI/ML , Blockchain , Distributed Systems and IoT | Lecturer | Speaker | Blogger