Monolithic applications have been an area of concern for many organisations. One of the main issues with monolithic infrastructures is that they can be difficult to scale and maintain. Because everything is tightly coupled together, it can be hard to scale individual components of the system separately. This can lead to performance bottlenecks and slow response times. With the invention of Cloud computing, businesses are now looking to get away from legacy and monolithic applications and adopt modern technologies like serverless and microservices. This helps them to innovate, scale and yet be cost effective in the modern times.
Devoteam organised a recent podcast where the topic of discussion was breaking down a monolithic application using strangler patterns. The host, Prabhat Handoo, spoke with Ingvar Thorbjornsson, a Principal DevOps consultant at Devoteam, about the best solutions for this process. During the podcast, Ingvar shared his experience using the re-architect and re-platform methodologies, and discussed a PoC design he created for a large financial services institution based in London.
The advantages and challenges of Monolithic Infrastructure
Monolithic infrastructure can be considered as a unified system that comprises all the essential components required for an application to operate, such as service servers, databases, and user interfaces. Historically, this approach was commonly adopted due to its simplicity and straightforwardness in developing an application.
Despite its advantages, there are significant challenges associated with monolithic infrastructure. These include long lead times, fear of failed changes, and difficulties achieving the “fail fast, fail often” methodology of agile. Furthermore, the rise of cloud technologies has led many customers to migrate towards more microservices and serverless technologies, causing monolithic infrastructure to develop a negative reputation over time. One of the main issues with monolithic infrastructure is that the tightly-coupled nature of its components makes scaling and maintenance difficult. As a result, individual components and systems may be hard to scale or separate, leading to potential performance issues and slow response times.
Another challenge with monolithic architecture is the complexity involved in deploying new features, updates, and inventory systems, which increases the risk of downtime and other disruptions. In addition, these systems can be challenging to integrate with other services and systems, thereby limiting flexibility and extensibility.
How can customers effectively address these problems?
One possible approach is the “strangle pattern,” which has been in use for several years but has gained new relevance in the cloud space. Essentially, this approach involves taking a data-driven approach to mastering the application by analysing its patterns and categorising requests into the appropriate domains. This is a crucial first step in understanding the application. When planning the actual migration, it is important to establish real-time monitoring of your API usage. From there, you can gradually reroute API requests from the monolith to microservices.
Approaching Strong Migration: Example of Using Strangler Pattern for Application Re-hosting and API Gateway Deployment
This is an example of how to approach a strong migration, which involves re-hosting the application onto EC2 instances and migrating the database to RDS using identification migration services. Afterward, an API Gateway is implemented to redirect client requests. It should be noted that while this approach may be suitable for certain situations such as time constraints or the need to leave a data center, it is not necessary to re-host to an AWS account to utilise the Strangler pattern. An alternative option would be to maintain the monolith on-premises and employ load balancing between on-premises and cloud environments. If a customer is faced with a pressing matter, such as a two-month data center exit, it may not be feasible to completely re-architect the application within that time frame. Instead, this methodology could be employed to begin the migration process by re-hosting to AWS and gradually transitioning components.
What are the available options for customers at this stage?
One popular alternative to this approach is the use of a microservice architecture. In this approach, the application is divided into smaller, individual services that can be developed and scaled independently. In this example, containers on Kubernetes are used to deploy the microservices. This approach provides flexibility and scalability, as each service can be developed and scaled independently. Additionally, if a change is needed, only the relevant service needs to be updated, rather than the entire application.
The third step is an iterative process where services are deployed one at a time, and their corresponding API requests are rewritten. Eventually, all requests will be routed through the new microservice architecture, and the monolith will no longer receive any traffic.
Testing should be considered as part of the process and the results should be factored in. It is recommended to test each portion of the code after rewriting it, but having real-time monitoring tools like CloudWatch in place is also crucial to track performance and usage and ensure that no issues arise.
In this example of step three, we integrate CloudWatch or similar real-time monitoring tools for user performance monitoring. Once all the requests have been successfully routed through the microservices, we can safely decommission the monolith.
Another option for customers is to utilise serverless architecture, which involves using microservices through the use of functions. This can be compared to the use of containers in a microservices architecture. There are pros and cons to both approaches, and it often depends on the preferences and skills of the developers involved. For example, if a team is familiar with a specific programming language, it may make more sense to use containers. However, utilising serverless architecture can be less of an investment in development since it does not require managing infrastructure.
Many customers express a desire to re-architect or re-platform their applications, but the business case often does not add up due to the required investment. Some customers want to modernise their monolithic applications, but they may not have access to the code or the original developers. The Strangler pattern is a cost investment that keeps the business running, but it may not always result in a positive return on investment. While lifting and shifting a monolithic application to AWS may provide a quick turnaround, the ongoing costs and management of the infrastructure can be expensive. A re-architect or Strangler pattern may involve some initial expense, but it can lead to a positive return on investment over time.
Rearchitect vs Reboost
In a recent project that Devoteam worked on, which was a mid-sized complex application, we provided two different quotations to the customer for re-hosting and re-architecting. As mentioned earlier, the initial cost for re-hosting is significantly lower than re-architecting, as re-architecting involves understanding and rewriting the code, and implementing a strangler pattern, which requires investment. However, when it comes to cloud consumption and managed services, the costs are much lower. For instance, using serverless architecture means that as long as the AWS region is not down, the application will always be up and running. Therefore, our advice to customers who are considering re-architecting or re-hosting is to consult a professional AWS partner and identify the return on investment and the time frame for achieving it. It’s not just about the investment; it’s about utilising innovation, moving towards different architectures, and getting data analytics out of it, which are the things that customers are looking for today. In the case we mentioned, the customer was able to recover their investment in two and a half years.
As you can observe in this example, the re-hosting is estimated to cost around 135k whereas the re-architecting is estimated to cost around 121k. It is important to note that this was a specific case and not all projects may have the same results. However, in general, for a complex application, it is expected to recover the investment within three to four years. Therefore, it is advisable to consider the long-term benefits before making a decision.
How does Devoteam typically approach these types of projects?
We offer a Migrate to Modernise service, where we guide customers through our methodology and journey. Our process typically begins with an initial assessment and a discovery workshop with the customer. The assessment provides a report that aligns with the customer’s cloud strategy, identifying whether re-architecting or re-hosting is better suited to their business drivers and budgeting purposes. This is a significant benefit for our customers as they receive a migration plan that is tailored to their needs and aligns with their cloud strategy. For instance, we are currently working on a POC for a customer that we presented today, and in a few months, we will discuss it further when the application is in production.
If you are facing challenges with your monolithic infrastructure and want to adopt modern technologies like serverless and microservices, Devoteam can help.
