Splitting a monolith

The challenges

Breaking up a monolithic application depends on the complexity of the monolithic application.

  • How do you adopt microservices architectures?

    • How do you pull apart a monolithic database?

    • How can we have an efficient authentication and authorization between fairly independent microservices?

  • How do you take an existing system and re-architect it without having to stop all the work that the organisation is carrying out?

Melvin Edward Conway - Computer scientist, programmer and hacker

Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.

The Approach

The steps usually taken to break apart a monolith are:

  • Identify the components that should be written as independent services. From Conway’s Law, understand the communication channels of the client’s business, as this provides a very good starting point on how the monolith should be broken up. Pinpoint key overall functionalities of the monolith and then further split these functions into small independent components. Microservices must be as simple as possible, otherwise we risk the possibility of replacing one monolith with several smaller monoliths.

  • We then identify and assign team members to develop the microservice, ensuring they have a cross section of skills from developing the front-end to the backend, handling infrastructure related issues for the team, testing and team leading.

  • Create the microservice ecosystem. For this we need the right execution platform with CI/CD capabilities.

    • The execution platform needs to provide deployment management, configuration management, self-healing, scalability, centralised logging, service discovery and routing, load-balancing, microservice level monitoring, traceability, centralised storage service, container orchestration.

    • The Continuous Integration and Continuous Delivery (CI/CD) system provides an automated build and release system, automated testing, centralised deployment.

  • Once the steps above have been carried out, migration of the legacy monolithic application can begin.

The Distributed Monolith

  • More often than not, what usually happens is that some wise crack project manager, in his enthusiasm to ‘economise’, splits the monolith based on its existing module structure, carving out the existing database structure for each module into individual microservices that are still tightly coupled!

  • This means that these systems have to be deployed together. Even though it meets the definition of a service-oriented architecture (SOA), it fails to deliver on the promises of SOA. Distributed monoliths have all the disadvantages of a distributed system and the disadvantages of a single-process monolith, without having the upside of either!

  • This situation usually occurs in an environment where not enough focus was placed on concepts such as information hiding, leading to highly coupled architecture, in which changes ripple across service boundaries. Seemingly innocent changes that appear to be local in scope break other parts of the system.

Getting around these challenges

  • To get around the challenges of adopting an autonomous team approach, it is important that team members treat each other as peers and share their knowledge with each other within the team and outside of the team.

  • It is important for team members to update a centralised document that is easily access by all team members.

Advantages of a Monolith

It is unfortunate that people have come to view monoliths as something to be avoided. People equate monoliths with legacy. And this is a problem.

The monolith architecture is a valid design choice as it has its own set of advantages:

  • Being able to re-use code between modules.

  • It is much simpler to deploy, avoiding many pitfalls associated with distributed system.

  • It results in simpler developer workflows, monitoring, troubleshooting and end-to-end testing.

In fact, with Martin Fowler’s Design Stamina Hypothesis, especially in the beginning of a project, when requirements are not clear, it might be faster to have a monolith until such a time when changing the design becomes more and more expensive, especially if requirements change quite a bit.

In this situation, it might be better to get back to the drawing board and redesign the application from scratch as microservices, because:

  • the requirements would have become a little bit more firmer than in the beginning

  • the team has a better appreciation of the requirements and what is expected of the new application

  • they would have a better idea on what the new design would need to be like and how to avoid previous pitfalls.

  • the resultant architecture is much cleaner and should be designed to handle changes in future requirements

  • more often than not, this cleaner design makes the application much easier and much cheaper to maintain going forward.

The question really boils down to - would management be willing to invest in the short term to go with the new redesigned application for long term savings in cost and maintenance?