I recently participated in a webinar, and one of the questions I was asked made me think about a great first topic for this blog: What are the key drivers to keep an application and “lift and shift”?
If you’re in a company that has a plan to move to the cloud, you’ve probably been asked what it is going to take to move an existing application to the cloud. In one of my previous roles, our CIO gave us the mandate that we were going to move everything out of one of our expensive data centers to the cloud within two years, so I saw a lot of “lift and shift” requests. But not a single one of those requests resulted in a lift and shift.
Let’s review the benefits of running in the cloud and then see if we can characterize the types of applications that will run well in the cloud.
Benefits of the cloud
There are many benefits to running in the cloud, but for the purposes of this discussion, I would like to focus on just one: elasticity. The cloud has, for all practical purposes, infinite resources. We can run 10 instances, 100 instances or 1,000 instances, all with the click of a mouse or automated by a set of rules. The benefit to a company is that the cloud allows us to scale up to meet high demand and scale back down to conserve costs.
For example, an e-tailer may require 100 servers during the day and 20 servers at night, but it needs 500 servers on Black Friday (see figure 1).
When running in a traditional data center, you would need to build your environment to support the full Black Friday load, leaving most machines at 10 percent or less utilization for 95 percent of the year.
The cloud allows us to avoid this by paying only for the resources that we use, but it means we need to size our environment correctly at all times, otherwise we will overpay for resources we do not use.
Applications that run well on the cloud
So, what type of application runs well in the cloud? We can identify a few different criteria for applications that are well suited to run in the cloud:
- Horizontally scalable
- Fast startup times
- Resiliency to servers coming and going at will
First, applications must be horizontally scalable, meaning a single instance can service a small number of requests but thousands of instances can service a large number of requests. To do this, applications need to be architected for scalability. That means services must be stateless. At any given time, any service running on any machine can handle a user request.
Consider a service that returns a “page” of data from a database. We could implement this in a couple ways:
- Execute a query to the database and maintain a row cursor that points to the result set. When the user makes a subsequent request, we use that row cursor to retrieve the next page of data.
- Build the query in such a way that we can retrieve an arbitrary page of data, based solely on input parameters.
The former approach maintains state in the service, which means the user’s request must be directed to that specific service. If the service is scaled down, then the user is out of luck. The latter approach does not maintain state and allows any service to satisfy the user’s request. It is a contrived example, but many applications running in an on-premises data center are implemented with the former approach and will simply not work well in an elastic environment.
Applications also need to startup quickly. The value in elasticity is that it allows us to quickly add instances to meet a change in user demand. If an application takes 15 minutes to start up, then it will be too late to the game to help alleviate the load.
Finally, applications need to be resilient to instances scaling down. We always give instances time to complete their requests before shutting them down, but we cannot count on any server being available from request to request.
Lifting and shifting applications
It has been my experience that applications that have been implemented in a microservices architecture are prime candidates to move to the cloud, but moving traditionally architected applications is only going to create problems. If you try, you are going to find yourself recreating your data center topology in the cloud, which will both be more expensive than you anticipate and won’t give you the elastic benefit that the cloud provides.