The Achilles Heel of Monoliths

Mike Hahn, COO of Tiempo Development and one of the panel members on the special Nearshore Americas’ webinar, is exploring the drive towards microservices and how organizations can get it right in this sponsored series. Registration for the webinar is now open. 

When it comes to monolithic applications, lack of scalability and flexibility coupled with old code can be the Achilles heel.  The software industry is demanding that development companies become more agile, more flexible, and increase the velocity of their development efforts – and many companies are turning to microservices as an architectural design choice.

A monolithic is an application that uses a monolithic architecture and is the traditional model for designing and developing software. The monolithic application consists of a single self-contained unit in which all code exists in a single codebase, and in which modules are interconnected. At deployment time, the entire codebase is deployed, and scaling is achieved by adding additional nodes.

While microservices are increasingly gaining favor, not all companies are turning their backs on monolithic applications, and for good reason. When applications are small, adopting a distributed architecture like microservices can result in an unnecessary increase in complexity and overhead. When companies are setting out to build an application, or provide a proof of concept, it is important for them to evaluate which architectural design style will best meet their needs. Small, monolithic architectures are simple to develop and deploy, easy to understand, and simple to scale, test, and debug. It is not until monoliths grow large, that the case for microservices is made.

This is when that vulnerability, the Achilles heel, of lack of flexibility and modularity becomes apparent. So what are the issues of monoliths that drive organizations to microservices?

Using a Single Development Stack

The tight coupling that monoliths are known for means they can only us a single technology stack, which creates issues with flexibility. Developers are not free to choose the best programming language or data store that features the functionality that best suits the need of a given process. As monolithic applications grow, the data that is stored can be very heterogonous with varied processing requirements.

Difficult to Understand

Tight coupling and the many interconnections between modules in a monolithic application can result in a codebase and interdependencies that are difficult to understand in full. New developers will need to have a good understanding of how the entire application fits together. This can make the on-boarding of new talent a daunting task.

Resiliency, Fault Tolerance and Isolation

One of the major disadvantages of a monolithic application again is the result of tight coupling and low cohesion. Changes to the application present a high-risk situation. Because a monolith is a single unit with many inter-dependencies, a bug in one part of the application can cause issues in another part of the application, or even bring the entire application down. Due to the possible chain of faults that can occur, it is also difficult to isolate the source of the issue. As a result, developers need to be sure to test each module, because it may be impossible to predict the outcome of even minor changes to the codebase. Recovering from failures is also not an easy task. Once a bug is isolated and corrected, the entire application needs to be rebuilt and re-deployed.

Deployment

Large monolithic applications can take very long to develop and deploy, oftentimes in the range of months, or years. A slow deployment velocity can result in a long timeline for users to receive new features, product hitting market late, or falling behind competitors that have embraced a nimbler development approach such as microservices.

There are many more issues related to their lack of scalability, declining quality of code, and lack of flexibility that arises from large development teams, and traditional development methodologies like waterfall that are commonplace with monolithic applications.

This is the point at which companies look to microservices. Microservices are relatively new, and there is no agreed upon definition as to what makes a microservice. However, all microservices share some commonalities:

• Services should communicate over a network with lightweight technology agnostic protocols.
• Each service must be independently deployable.
• Services should be small in scope and focus on a single business goal.
• Each service can leverage a different technology stack.
• Microservices should be failure resistant and fault tolerant.

Microservices should not be confused with Service Oriented Architecture (SOA).

Microservices Solve Monolithic Issues

Now that we have a good understanding of what microservices are, let us examine how this approach can address the issues related to monolithic applications.

Each company needs to make its own assessment of whether monolithic or microservices is the right fit for their organization. In some cases, a monolithic application is still a great choice. Microservices do not align with every company’s culture, processes, and application. Nor are they some magical fix-all that can be adopted without careful planning and consideration.

Whether you are trying to plan the design of a new application, or looking to decouple a monolith, it is important to make an informed decision.