While there is much talk about cloud-native, 12-factor applications, the vast majority of enterprise applications are based on a 3-tier model, where the application logic tends to be monolithic. The advantages of lifting and shifting these legacy monoliths to the cloud are compelling, and well documented elsewhere. Once the initial lift and shift has been accomplished, additional benefits of being hosted in the cloud can be realized by decomposing the monolith into microservices. But more on that later. Today, we are going to focus on the first step: the lift-and-shift of a monolithic application to the cloud.
The first tier of a 3-tier application is just the user-interface – hopefully done in a browser. The middle tier contains the application logic, and the databases live in the third tier where, presumably, only the parts of the application with proper credentials can access them. Most organizations have a goal of strengthening the security and reducing the operational complexity for the migrated monolith, but achieving that goal can be challenging.
A logical first step in migrating a monolith is to look at the technology stack used. All of the popular cloud providers allow you to stand up a virtual machine, and a wide variety of operating systems and the frameworks are supported. Sizing the app in terms of number of servers, cores and memory footprint will be critical to inform yourself about the sizes of VMs that you will stand up, and their projected cost per month. Specialized hardware such as FPGAs or solid-state storage, software services, or subtle differences in pricing policies, may sway you toward one cloud provider or another.
Storage is a substantial consideration. As the model varies so drastically, the existing application uses enterprise storage systems that provide predictable performance, high availability and a full complement of enterprise data services to cloud-based blobs. What are you using today for name resolution and communication protocols? How is the application being secured? What supporting services does it require? Where are the user identities being stored? What is used in the way of certificates, SSO and IAM protocols? These are all crucial questions to be asked. They are important to define authentication and authorization of users, but also to establish trust between applications services for mutual authentication or establishing TLS communications, as well as for secrets management such as the credentials used to access the databases.
Up until this point, we have not been concerned with containers, just VMs. Containers won’t be needed until we add our first service outside of the cloud-resident monolithic application. Until then, we have processes. Even monolithic applications are comprised of a collection of processes, for modularity, security, resilience, and to achieve parallel operations. Linux namespace and cgroups provide better isolation than ever, and many monoliths are taking advantage of these features today. Another important concern (that we will defer for now) involves session state – a big no-no for scalability regardless of deployment model.
Migrating to the cloud is a journey of discovery – not only about what you can use out there, but as to how your legacy application works. With proper planning, executive buy-in, and appropriate resources allocated, the sweetness of victory will be had. Once you get the monolith running in the cloud, take a moment to appreciate what you have accomplished, take a victory lap with your co-workers (without gloating), then we’ll take it to the next level in part two of this blog – Breaking Up the Monolith. Sign up to our newsletter to be notified when it’s released.