Five patterns for infrastructure migration to the cloud

As an architect, I spend my days designing ways organizations can reach their business goals through technology. For many, that means expanding into hybrid cloud architectures.

Migrating workloads to the public cloud has become a common practice, but it still poses challenges to IT organizations that are traditionally on-premises. Your organization will face several immediate choices as it moves into the public cloud. Each one will affect the skills required to run the cloud, and that makes each option essential. Building a cloud is not simply choosing your favorite brand. It's determining how your team builds today, who the team hires in the future, and what services are available when you need them later on.

Here are the essential factors I keep in mind while deciding what cloud architecture will be right for the team.

Prerequisite choices (and their

consequences)

The first decision you must make is to select a cloud vendor. The three major players (Microsoft, AWS, and Google) all have similar service offerings, and in most scenarios, the deployment costs are going to be similar. When helping a client choose a cloud provider for their primary services, I like to take a step back and look at their overall software portfolio and the staff's skills. Suppose you are considering migrating many systems to Platform as a Service (PaaS) offerings. In that case, you should evaluate your cloud vendors for that technology, as it can be a point of differentiation between vendors.

Once you have decided what cloud to migrate systems into, you need to start planning a migration project. In some cases, external factors may drive your project's timeline, such as an expiring lease on a data center or hardware aging out of support. This leads to several different cloud migration approaches, depending on the timeframe and the IT organization's skills and size. I want to highlight five typical patterns I have seen in the wild. These patterns focus around levels of "lift-and-shift" migrations, which are a common first path into cloud computing. If at all possible, you should take a step back and dedicate some extra time to assess your architecture and make more informed decisions.

Pattern 1: Disaster recovery

A common pattern for entry into the cloud is as a disaster recovery site. Many organizations only have a single data center or want to expand their availability options. This pattern provides for a well-defined path when you decide to execute a full migration. The nature of disaster recovery implementations varies, depending on budget, from as simple as shipping backups into cloud storage all the way to running a full environment with asynchronous data replication between your data center and the cloud. I particularly like this pattern for smaller organizations that may lack the robust infrastructure options for availability that are common in most larger enterprises.

Pattern 2: Cost savings

Your software portfolio can provide benefits and cost savings. The biggest example of this is Microsoft Windows and SQL Server with Azure virtual machines, where existing on-premises licensing can provide cost savings. While the cost savings are nice and can be substantial, having staff with cloud experience is one of the biggest challenges in any migration. This can give you a big head start on your migration. In the longer term, it allows for better architectures that save money. If your organization lacks cloud expertise, ensure that budget, time, and money for training are available to get your engineering staff up to speed. While this migration can mean a healthy shift from CapEx to OpEx, it adds a responsibility to manage cloud services and any networking, security, and storage required.

Pattern 3: Rehosting

Another pattern is rehosting. This is where you leverage a tool from your cloud vendor (AWS VM Import/Export, Azure Migrate) to execute a large-scale migration of your on-premises environment into the public cloud. This gets the hard part out of the way by moving large volumes of data and applications to the cloud provider. While this approach is great for the migration, it can lead to expensive cloud bills for applications that may not be sized properly. However, since your data is already in the cloud, it is much easier to optimize and even re-architect applications. This pattern abstracts a lot of the network and storage architectural decisions you need to make and generally just reproduces your on-premises environment, which can be good or bad. The other issue is that rehosting is the most expensive way to execute a cloud migration.

Pattern 4: Replatforming

The more common approach that I've seen in practice is called replatforming, which, to borrow a phrase from Stephen Orban, is to "lift, tinker, and shift." This is more than simply migrating your VMs. It is trying to achieve some tangible benefits from your cloud migration. This can be achieved in several ways, but some common areas include moving web servers into a PaaS app service, using built-in cloud load balancing instead of expensive third-party appliances, and taking advantage of cloud-native backups. This is a more deliberate approach than rehosting, and while it may take more time to complete your migration, in my experience, replatforming leads to more successful outcomes. The nuanced approach of this migration pattern allows you to more easily plan for workloads that benefit from cloud services.

Pattern 5: Embracing PaaS

To really benefit from the cloud, you need to move up the stack and take advantage of the Platform as a Service (PaaS) offerings. While there is a valid concern for vendor lock-in with PaaS offerings, they allow more flexibility, reduce your operating overhead (by managing patching, high availability, and backups), and in many cases, permit autoscaling.

A good example of this is using a MySQL database service, which is available on all major cloud platforms. While MySQL is trivial to install with a virtual machine, setting up a highly-available MySQL solution in an Infrastructure as a Service (IaaS) environment can be challenging and may even require paid support options. In the PaaS, you can simply deploy a database and have your application start using it. Similar options exist for web servers, massively parallel data warehouses, Hadoop, and many other solutions. One of the key architectural tenets of these analytic solutions is that storage is decoupled from compute. You only need to pay for compute when it is in use.

An example of application modernization is shown here:

Image

While these solutions provide the same functionality, the means of implementation is much easier with PaaS. The web service and the database service are deployed together with minimal installation and configuration. In the VM model, you would handle the deployment of the VMs, configuration of the network, and configuration of the services yourself. The Platform as a Service model may also offer autoscaling and pausing, which can reduce your deployment's overall costs. This type of effort is not common in the first phase of a cloud migration, however, as organizations usually need more time to get more comfortable with the services available in the cloud.

Conclusion

The public cloud has a vast number of offerings that can be confusing to both novices and experts, as many of the services overlap. The other cloud challenge is that the service offerings landscape is constantly changing. However, to execute a successful cloud migration, you don't need to be on the bleeding edge of services or using a hybrid cloud Kubernetes solution from day one. Replatforming specific parts of your on-premises environment is a good first step to executing a cloud migration. Still, you should look for opportunities to modernize your applications, to reduce costs, and gain flexibility along the way.