UPDATE: I originally wrote this series of articles more than five years ago after I started working for Microsoft and after I had already been a Solution Architect for an AWS partner. I realized however that it was not currently published on my website and probably not available anyplace else. The content is still very relevant, so I figured that I would make some updates for today and re-publish.
Although we as Cloud Solution Architects (CSA) are required to be very technically knowledgeable, the technology of the Cloud is not always the major hurdle for a customer to actually move to “The Cloud”. Sometimes the migration strategy of taking your existing systems, that are working perfectly fine right now, and migrating them to a Cloud Service Provider (CSP) so that you can save much needed time and money can be daunting. Unfortunately most customers do not have their own dedicated CSA like you would find at Microsoft or Amazon to help them with this move. So I would like to try and help you better understand some of the information that you will need to build such a migration strategy.
Let’s start with the basics of why you should and will want to move to the Cloud. The cost savings, elasticity, and scalability of “The Cloud” provide a level of improvement for existing systems and applications that can be very hard to ignore. These same improvements can be even more impressive if you were to build a new system or modernize an existing system specifically for the Cloud, but we will cover that in another post of this series. The decision to migrate is not really the hard one to make. The tough decision is more around how and what should be migrated based on your existing system inventory and what you may have or need in the future.
There are many ways that a system can be migrated, everything from a Forklift approach, where you are simply duplicating the system as-is within a given CSP environment all the way to a complete re-write of the system. There are also many factors that you should consider when making these decisions such as, time, money, expertise of the people performing the work, etc. What I would like to do within this series of articles is to focus on the methods and approaches for migrating a system to the Cloud. Understanding what the different approaches are should help with the decision making process and therefore better map what can be achieved based on the available time, money, and expertise.
For the purposes of this series of articles, I would like to focus on a standard three tiered, Linux based (front-end, business logic, backend) web application when talking about the different approaches for migration into the Cloud. The size, complexity, or even function of the web application does not really matter, but more of how a web application can be broken down to better leverage the services that CSPs provide.
NOTE: I do realize that n-tier applications are not necessarily built using the most up to date application development patterns, but a lot of customers still have them in place today as part of their legacy footprint. So I thought that it would be good to provide a use case that almost everyone will understand rather than focus on a technology or patter that not everyone is ready for quite yet.
Forklift vs Re-architecture for (IaaS)
The first major approach to consider when migrating a system is the Infrastructure as a Service (IaaS) approach. Within this approach there are two basic schools of thought, there is the Forklift school where you are basically doing nothing more than importing your existing servers as-is, assuming that they are already virtualized, directly into your public Cloud environment. This is only possible if the servers are already virtualized and meet one of the required formats of the CSP. By default, most CSPs support VMs in the cloud using the open, industry-standard VHD (virtual hard disk) format used by a number of on-premises virtualization hypervisors. They also typically support the VM Ware ESX/vSphere format and the Citrix Xen virtualization formats.
However, for those virtualization vendors that do not support one of the supported formats, each CSP usually provide a Virtual Machine Converter tool which can help convert your VMs into the correct format. For extremely old legacy applications, this might be the only approach available.
Using the Forklift approach does not truly take advantage of everything that the Cloud has to offer. It will certainly lower cost, but it will not allow your system to take advantage of the elasticity and scalability improvements that are available and the costs could be even lower with just a little bit of re-architecture. It is this second school of thought that will allow you to take advantage of some of the IaaS based services that your chosen cloud provider offers. Let’s take a look at a few of these out of the box services and how they can be leveraged to help reduce costs even further as well as provide elasticity and scalability and in some cases better security for your web application.
Every cloud provider provides a lot of great out of the box networking capabilities so that you can better mimic or even connect to your current environment or data center. This includes services like Virtual Networks, Load Balancers, DNS, Public IP addresses, and VPN gateways. Deploying your system into a virtual network within a CSP completely segments your system from all other systems that have been deployed within the Cloud. You can then segment it even further by creating subnets within your virtual network and limit the traffic between the subnets thereby creating a multi-layered De-militarized Zone (DMZ). Once the system is in place, and all traffic has been locked down, both internally and from the outside world, you can then provide a cloud based Static IP address, Private or Public, for any endpoints that may be needed for your application.
Why Do This? – Using the out of the box networking services will allow you to place your web application into a clearly defined, segmented, secure networking environment that very closely mimics what you have today without the need for any of the hardware. In some cases, the networking that you define in your CSP could actually be more segmented and more secure than what you have in your data center today.
This is a no cost service which allows for virtual machines to be automatically provisioned or de-provisioned based on certain conditions within the application. Each CSP makes this capability available through different mechanisms, but the end results are the same.
With our web application example, we know that our application has a certain average threshold of users per day, but there are going to be spikes that occur based on certain events. We can configure an Auto Scaling event that when triggered will provision new servers that have the same web application already installed on them and make them available to users when one of these spike event occurs and then de-provision them after the event has completed.
Why Do This? – Using this service provides elasticity for the application allowing for growth that are based on the needs of the application at specific times. It also allows for a more minimal architecture to be deployed and maintained because you no longer need to have an architecture available 24×7 that can support all of the spike events, but only for what is minimally needed on a day-to-day basis. This is therefore a prime driver in reducing your costs when migrating to the Cloud.
Most web applications have a need for a lot of static files to be used within different areas of the application. Some files are images, whereas others might be PDFs, media, etc. In large scalable web applications, this usually requires the need for a separate file server to offload the processing from the main application servers. In the Cloud, this entire tier of your web application can go away with the use of Shared Storage. Now, it can be as simple as moving all of those static files to a Shared Storage service and then link to them through the URL that the Shared Storage service provides, either Public or Private.
Why Do This? – By leveraging Shared Storage, you are greatly reducing the cost of your overall application and increasing the scalability and fault tolerance of the architecture. Most Shared Storage services provide a very minimal cost based on the amount of storage being used and they provide an extremely high SLA for the content because of their automatic redundancy.
Most cloud providers today provide both their own systems as well as some hooks into third-party systems (Chef, Puppet, etc.) that can allow you to automate the operational management of all pieces of your web application once it has been deployed within the Cloud. All CSPs provide some kind of Infrastructure as Code (IaC) deployment model that can be used to actually define your application in a scripted way through a template file using JSON or YAML. The template file can be modified which can then be used to automatically update your deployed environment. Once the application environment is in place, a Configuration Management Service like Azure Automation DSC or AWS Opsworks based on Chef and Puppet, can be used to automate the update of the OS or the Application Server software environment.
Why Do This? – Using IaC templates will allow you to more easily define a single environment, replicate it, and automate the updates of all those environments in a much more efficient and consistent manner. Once the environments are in place, Configuration Management services can be used to reduce costs by automating the starting/stopping of VMs within non-production environments and automate the process updates of production servers to reduce downtime to your customers. All of this translates to cost savings for just one single application.
All of the above points are just a few of the items that should be considered when looking to migrate an application to the Cloud. There are many different methods and services that can be leveraged and some of them can provide many different benefits, such as lowering cost, increasing scalability and elasticity of the architecture, as well as improving the fault tolerance of the overall application. Even more importantly is that the architectural services can usually be taken advantage of without a tremendous amount of work or customization to your application, but a Cloud Solution Architect should really do a thorough analysis to make that determination.
In the next articles of this series we will look at some application specific (PaaS) services that can be leveraged during the migration process and how they can potentially provide even more ROI for our web application.
If you are locked-in on a IaaS based migration model for your systems, then you might want to also take a look at my articled related to Infrastructure Modernization when migrating to the Cloud: Cloud Migration: Infrastructure Modernization. This article goes a step further down the migration discussion to talk about how to use more Cloud-Native services that support your IaaS deployments there by further reducing costs and providing efficiencies within your Operations organization.