The Monolith
Monolithic applications are common within many organisations. These applications usually consist of a large software application coupled with a relational database for data storage. These applications have allowed organisations to run functions of their business for the last few decades. These systems could be internal applications to perform business functions or could consist of a web facing site which provides a service to the organisation’s customers.
These monolithic applications have usually been built and adapted over a number of years but, due to the nature of their architecture, changes can be time consuming and costly. Changes to these systems can take months due to the size and complexity of the application. Testing can take an inordinate amount of time due to the size and complexity of these systems. A change in one part of the system can cause unexpected errors in another part of the application due to the fact that a large amount of code can be coupled in a very large application. For a modern organisation it can be difficult to be agile and develop new features quickly to compete with competitors.
Scalability can also be troublesome and costly to achieve as the entire application is deployed as one monolithic application and a relational database. It can be difficult to scale up and scale down these applications to suit demand. Disaster recovery and data replication can be difficult and costly if downtime is to be avoided since all the data is generally stored in one database which must use expensive proprietary replication technology to maintain a ‘hot standby’ version of data. Authorisation and authentication methods for user access and security, within the application, are usually handled by custom code which can be expensive to maintain as well as difficult to achieve state of the art security measures such as multi factor authentication or single sign-on.
Whilst monoliths can be incrementally developed to support the evolving needs of the organisation, it can become very costly and time consuming.
Breaking the monolith
When an organisation realises that a monolithic application is no longer ‘fit for purpose’, because of the reasons above, it often considers a more modern architecture such as a microservice architecture. In a microservice architecture an application is decomposed into independent services that are decoupled. For example one microservice might deal with a orders, another service might deal with product catalog, another with warehousing, etc.. Whilst this approach may seem complicated it offers some advantages in terms of improving agility, reliability and scalability. Since any changes are being made to smaller decoupled services then changes can be smaller and the agility of development and reliability of the application can be improved. Any changes are usually within the confines of a service, so any bugs have less of a ‘blast radius’ if things go wrong. In a microservice architecture a single bug may cause single service to fail rather than a single bug in a monolithic application which can cause the entire system to fail. Scalability is improved because individual services can be ‘scaled out’ onto different servers.
Azure Serverless architecture takes the concept of microservices one step further and provide much of the infrastructure to build a modern service based architecture. Azure offers many services, such as authorisation, compute, storage, AI, etc., which can run parts of an application. These services can be built quickly and easily. The concept is often compared to building a children’s model using Lego; many of the bricks are already there to build things quickly.
Once the decision has been made to convert the monolith to an Azure Serverless architecture then what should the approach to this be ? Should the application just be rewritten in this new architecture ? Absolutely NOT (at least that should not be your default approach) !!! Large software projects often fail or overrun. If you perform a large rewrite of a system then there is a strong probability that your project could overrun or worse completely fail.
Moving the monolith to Azure serverless
So if a redevelopment approach is risky then what do we do ? The answer is we rewrite the monolith into an Azure Serverless application bit by bit whilst keeping the application running.
Parts of the monolith can be identified and these parts can be split off into services that become candidates for implementing in Azure Serverless. For example one part of the monolith could be a service which manages a product catalog. You may look at this area of functionality and move a functionality relating to product catalog 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 legacy code in the monolith, which originally implemented the product catalog functionality, now becomes redundant and can be removed. We can then repeat this process with another service (e.g. fulfilment service) in Azure Serverless and also interface the monolith to this new service. After several iterations of this process then all parts of the monolith are implemented as cloud services and the monolith becomes an empty application and can be retired.
The approach was labelled as the Strangler Design Pattern named by Martin Fowler. This design pattern was inspired by the Strangler Fig in rainforests which grows around trees and eventually kills the tree. This approach provides a measured and less risky approach to modernising a large monolith.
Azure 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 Azure Functions , CosmosDB, Azure Storage and many more others allow decoupled services to be built in an agile manner using modern, on demand computing resources. Using these service and with a bit of planning you can break free of the monolith one service at a time.
Ready to learn more? Contact us for a free consultation on how to start breaking up your legacy monolith systems and move to Azure Serverless.
