Splitting Monolithic Applications

A monolith grows over time. It gets more and more important. It accumulates capabilities, until it reaches a point in which it does not scale anymore. That’s when you need to split it. Yet, doing so is hard exactly because it grew organically without clear separation between its inner parts. When splitting a monolith becomes a strategic necessity, the challenge of executing on the strategy requires specific discipline and skills.

Why split the monolith?

Monolithic applications are appropriate when they are developed by a small team and can live in one single application server. However, as the system grows larger and it needs to scale, splitting it into (micro)services can provide benefits:

  • It allows different teams to release features independently and often faster by separating the development lifecycle of different components.
  • It offers the option for horizontal scaling of selected services.
  • It enables development teams and business people to work and understand features at a finer-grained level, and reduce the overall complexity.

The challenge of splitting the monolith

Splitting a monolithic application into (microservices) requires deep understanding of the system. Such a monolith is often poorly understood and its inner pieces have unclear boundaries. Splitting is typically a long term project involving a clear strategic business decision, a set of specific technical skills, and a team that works in concert.

On the one hand, the reality of the system must be understood in details. Examples of typical technical problems are understanding connections between services, or usages of database tables in different places. These types of problems require deep understanding of the system. At the same time, to deal with the scale of the system, manual reporting cannot keep up. These issues must be captured through automatic tools that are tailored for the system. Indeed, building the tools can have a cost, but once built, they can be a huge long term asset because they can act as guards to ensure that the system is evolved in the right direction. We offer the expertise of building such tools.

On the other hand, such a long term project requires the team to work together with the business and keep track of the progress. This is a problem that has multiple facets. When the problem is large, it is easy to get drowned in details. That is why, the foremost requirement is to have an accurate overview of the current issues, and of the progress. This is where analysis tools can fit in and provide the service of reporting. The team must obtain a common understanding of what is left to do, and work together. This requires a dedicated decision making process based on daily communication in which the data remains at the center. To guide the team, we offer continuous coaching.

Standard offer

Phase 0: Approach the monolith workshop

Splitting a monolith is an ambitious project that requires multiple levels in the organization to work in concert. The goal of the startup workshop is to help all stakeholders gain a common understanding of the challenges implied by such a project, and to get an overview of the technical needs and the associated process.

Phase 1: Identify boundaries

Together with decision makers and technical people we identify:

  • the problematic areas,
  • the initial services and their boundaries, and
  • the deployment and monitoring needs.

phase 2..n: Split the monolith (coaching and project management)

The splitting of the monolith involves an iterative process in which each step involves:

  1. identifying fine grained boundaries,
  2. identify technology choices, and
  3. the concrete code migration.

We work together with the team through continuous coaching and project management.