The Monolith

Many organisation have monolithic application which run their businesses. These are applications that, generally, consist of a large application and, perhaps, a large relational database for data storage. These applications have helped organisations run their business for the last few decades. They could be internal applications to perform business functions or could consist of a web facing application which provides a service to your customers.

Usually heavy investment has been put into these systems but due to the nature of their architecture changes can be costly and time consuming. Release cycles are typically measured in months.  A change in one part of the application can cause unexpected errors in another part of the application due to their coupled nature. In the web, mobile and artificial intelligence age it can be difficult to connect interfaces such as mobile, chatbots or 3rd party integrations to these applications. For a modern organisation it can be difficult to be agile and develop new features quickly to compete with competitors.

Since they tend to rely on one monolithic application and a relational database then scalability can be difficult and costly to achieve.  Disaster recovery and data replication can be difficult and costly if downtime is to be avoided. Many of these monolithic applications also use ‘homespun’ authorisation and authentication methods for user access and security.  This can make it difficult to achieve state of the art security measures such as multi factor authentication or single sign-on.

Whilst a monolith can continually be developed to include new features it can become very costly and time consuming.

Monolith to Microservices and Beyond

When a business realises that it has outgrown a monolithic application it generally considers a more modern architecture such as a microservice architecture. In this architecture an application is separated into a number of independent services that are decoupled.  For example one service might deal with a product catalog, another service might deal with orders, another with fulfilment, etc.. This approach can appear complicated but can offer a number of advantages in terms of improving agility, reliability and scalability.   Agility and reliability can be improved as changes are smaller and, since they can be made within the confines of a service, they have less of a  ‘blast radius’ if things go wrong. Scalability is improved because individual services can be ‘scaled out’ onto different servers.

Cloud serverless architecture such as AWS Serverless take microservices one step further and provide much of the infrastructure to build a modern service based architecture.

So if we decide we want to convert the monolith to an AWS Serverless architecture then we should just rewrite the application in in this new architecture ? Absolutely NOT !!! If you do a ‘big bang’ rewrite you generally get a big bang. Rewrites of systems have a checkered history throughout the field of software development.  A new team come in and fancy getting some new tech under their belt so decide to rewrite your monolith from the ground up. Such projects often run over budget or fail to deliver due to the underestimation of the actual functionality of the application and the effort involved in building it from the ground up.

Moving the Monolith to AWS Serverless

So if we accept that a complete rewrite in a ‘big bang’ approach is risky then what do we do ? Well the answer is we slowly rewrite the monolith into an AWS Serverless application one bit at a time whilst keeping the application running.

We start to split off parts of the monolith into services that become candidates for implementing in AWS Serverless. For example lets say one part of the monolith is a product catalog for your e-commerce monolith. You may look at this area of functionality and move everything relating to it into it’s own service. Any areas of the monolith that require the product catalog can then interface into this new product catalog service. The old code in the monolith, which implemented the product catalog functionality, is now redundant and is no longer used. We then implement another service (e.g. fulfilment service) in AWS Serverless and interface the monolith to this new service. Eventually all parts of the monolith are implemented as cloud services and the monolith becomes an empty bus and can be retired.

The approach is called the Strangler Design Pattern, named by Martin Fowler, and inspired by the Strangler Fig in rainforests which grows around trees and eventually kills the tree. It provides a measured and less risky approach to modernising a large monolith.

AWS Serverless services provide an ideal platform for this approach as they offer much of the components required to build a modern serverless service based architecture. Services such as Cognito, API Gateway, Lambdas, DynamoDB and many more others allow decoupled services to be built quickly and securely helping your to improve the agility of your organisation and break free of the monolith one service at a time.

Ready to start the move from legacy to serverless? Let’s Talk – we offer a completely free 30 minute consultation to determine the best solution for you.