If you’re doing a lift and shift cloud migration with your monolithic on-premise apps, you’re missing out on the cloud’s performance improvements and cost savings.
According to the latest Intricately Market Report, more than 1.5 million businesses are purchasing cloud hosting products with a combined estimated spend of over $130 billion in 2022, per the latest Intricately Market Report. However, despite so many companies “migrating to the cloud,” the results aren’t the same for everyone. One area that causes the most problems is moving traditional, on-premises software applications (i.e., monolithic apps) to the cloud without making the necessary updates, which we’ll explore.
Why Monolithic Apps aren’t a Fit for the Cloud
Traditional apps are built as a single unit comprising three parts:
- A database consisting of many tables, typically in a relational database management system.
- A client-side user interface consisting of HTML pages or JavaScript running in a browser.
- A server-side application that handles HTTP requests, executes domain-specific logic, retrieves and updates data from the database and populates the HTML views to be sent to the browser.
To make any changes to the system, a developer must build and deploy an updated version of the server-side application.
The challenge with moving monolithic apps to the cloud (a process called “lift and shift”) entails buying server space, processing power and storage the same way you do on-prem, i.e., more than you need. Besides overspending on IT resources, your workloads may not perform as well in the cloud due to latency problems that prevent you from fulfilling the original on-premises service level agreements (SLAs). Or, perhaps you previously solved a high I/O block storage demand challenge for a workload by running it in a physical server using multiple host bus adapters (HBAs). After re-hosting the workload to the cloud, however, you may find an unexpected cost increase or worse – it may be unfit to run in the cloud due to the unavailability of computes that can handle the aggregate of all the original I/O spread across the on-premises HBAs.
In the worst case, your migration efforts fail, and you have to bring everything back in-house. Unfortunately, this situation isn’t rare. A State of Hybrid Cloud and Migration study from Arlington Research found that 72% of the IT leaders surveyed said they had repatriated workloads after migrating them to the public cloud.
Lift and shift can be a viable option if you have an application you’re planning to retire in the next couple of years or if it’s going to be too costly, too risky, or too long to refactor. Still, it’s vital to investigate your options using the industry-accepted 6-R methodology:
- Rehost
- Re-platform
- Refactor/architect
- Retain
- Retire
- Replace
Working with an unbiased third-party expert is also highly recommended.
The Benefits of Using Micro-services
One of the “R”s from the 6-R methodology, refactoring, is of particular interest because it entails modernizing an app by breaking it up into loosely coupled micro-services. Each micro-service can be independently tested and deployed, and each can be implemented in different languages and frameworks.
Working on micro-service based architectures allows organizations to split their teams into smaller autonomous groups. As a result, each group can work in parallel with others and accelerate the overall velocity of the project.
Another significant driver of micro-services is improving operations by isolating issues down to a much smaller component, reducing the time it takes to repair a particular workload. Similarly, switching to a micro-services architecture increases an application’s resistance to failure.
And finally, micro-services fit perfectly with the elastic nature of cloud computing, allowing organizations to quickly (and automatically) scale precisely the resources they need when they need them in a pay-as-you-go model.
Not all Micro-services are the Same
When refactoring to micro-services, you have two options: cloud-native or cloud-agnostic. While both have inherent benefits over monolithic applications, it’s important to choose a framework that fits your organization.
Refactoring a web application to cloud-native in AWS, for instance, could mean using S3 for storage, CloudFront and an API gateway for networking, Lambda for backend processing, and DynamoDB for databases. You may also choose Cognito for authentication. These services talk to each other natively within AWS using Amazon Resource Names (ARNs).
If you require simplicity and ease of management, cloud-native may be the way to go. However, cloud-agnostic is a better option if you wish to avoid vendor lock-in and have the staff support for more complex deployment frameworks.
With cloud-agnostic, each micro-service is a container that can run anywhere Docker, or another container runtime, such as Podman, containerd, or LXC is available. The benefit of cloud-agnostic is you can run an application on-premises or in the cloud, with or without Kubernetes orchestration.
For the best of both worlds, Amazon ECS on Fargate is an excellent start to running micro-services without maintaining infrastructure. Additionally, you can choose a blue/green deployment for Agile software development, which separates testing from production runtimes by creating two distinct environments. One environment (blue) runs the current application, and the other (green) runs the new application.
Final Thoughts on Monolithic Apps and Micro-services
In many cases, refactoring a monolithic app via a micro-services architecture will be the best option for a company. However, there are some important considerations regarding the best way to go about the process. One issue you want to avoid with your application modernization efforts is cloud vendor lock-in. This situation occurs when the cost of switching to a different vendor is so high that the customer is essentially stuck with the original vendor. Vendor lock-in can happen to organizations using a micro-services architecture if all their micro-services are held by one account. Instead, the micro-services should be spread over multiple accounts and loosely coupled between accounts. Remember, a multi-account setup is a prerequisite for multi-cloud.
Cisco has done an excellent job preventing its users from cloud lock-in. It’s development relations (DevRel) engineering team has been developing all its applications as micro-services and running these on a Kubernetes based Cloud Native platform for 5+ years. In addition, Cisco’s micro-service authorization framework has gone through architectural update 3 times as Cloud Native ecosystems have evolved.
If you’re considering a cloud migration, don’t forget this final point: you don’t have to go it alone. There are experts (e.g., Presidio) that have already done what you’re looking to do and can save you a lot of time, money and headaches if you follow their advice.
