Don’t just move your servers to the cloud

The cloud has now been around for a while and has transitioned from being a place where the cool kids play to an integral part of any companies IT and application strategy. The first and most obvious step is to handle compute power not within the own data center but rather the cloud. Spinning up a server in the cloud is just quicker and especially for very large corporations adding compute power is an issue. I have been in a situation when “finding a plug for a new server” was an issue that made it on the agenda of executive meetings.

This strategy is referred to lift and shift and is of today a main driver for cloud adoption as the immediate benefits are obvious. While there is nothing inherently wrong about moving your existing compute workload to the cloud, it isn’t a great idea either. The simple reason being that these applications have never been designed to run in the cloud. How should they? They have been built before the cloud as we know it today existed.

The core of the problem is, that running non-cloud applications in the cloud is highly inefficient. These applications are designed to run and utilize big machines so there is enough capacity for the lifetime of the application. They were also built as monolithic pieces which made it impossible to just add capacity as desired. Back when they were designed this would not have been an option anyways.

This article just got my attention [1]. Obviously Azure seems to have some capacity issues in the UK and seems to ask customers to other locations. The really interesting part is that customers seem to be mostly using the biggest possible machines available. This could be for like specific application requirements that only need this type of infrastructure like massive big data processing. More likely, however, people need this machines because they just run workloads that were designed for the data center rather the cloud. These would exactly use machines with a massive footprint.

Cloud workloads, on the other hand, are built around the concept of Micro Services. These are small loosely coupled pieces of software that can be scaled quickly on demand and also have a smaller compute footprint.

Beyond that there are certain services that used to be run on servers that are consumed as a service in the cloud. Databases are perfect example here. When you move to the cloud, you don’t run your database on a cloud compute node, but rather use the cloud providers database services. The leading providers AWS and Azure are both offering these services and encourage customers to use them. Using these service versus run-on-your own also has the advantage of lower operations cost as you don’t need to care about software updates, capacity or fail over.

So when moving to the cloud you should follow a set of core guidelines to ensure you can really benefit from the cloud and also ensure future growth.

• Map you infrastructure requirements. Before moving to the cloud, map your application landscape and understand the compute requirements. This will help you understand which of your applications are cloud ready.
• Start adopting cloud native principles. Cloud applications are built in a specific way to run in small units called Micro Services that can be easily scaled and distributed. The 12 factor app paradigm [2] offers a good starting point.
• Reassess your hardware requirements. Use monitoring and capacity planning to understand whether you really rightsized your cloud instances. Most people want to play it safe and highly overprovision their cloud capacity [3].
• Try to leverage cloud services as much as possible. Just because you used to run certain application services “from the ground up” does not mean you should do the same in the cloud.

In summary, keep in mind that moving to the cloud is about more than just literally move to the cloud. The leading cloud providers offer support and expertise to make the move easier and also help you to get the most benefit out of it. At the same time, you should also be clear that a cloud migration strategy will have a deeper impact on your application development than just deciding where to run your servers.