Migrating to "The Cloud".......so Many Possibilities (IaaS)

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 on my team 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 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 a future 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 Cloud Service Providers (CSP) environment all the way to a complete re-write of the system. There are also many factors that you should consider when making those 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. 

Use Case

For the purposes of this series of articles, I would like to focus on a standard three tiered, non-Windows based (front-end, business logic, backend) web application when talking about the different approaches for migration into the Cloud. Although I do work for Microsoft, Azure is a completely agnostic cloud environment. We support many of the most popular open source solutions on the market, including Linux, Apache Web Server, Redis Cache, and MySQL, just to name a few. 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.

Forklift vs Re-architected 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 (assuming that they are already virtualized) as-is directly into your new public Cloud environment. This is only possible if the servers are already virtualized and meet one of the required formats. By default, we support VMs in the cloud using the open, industry-standard VHD ( virtual hard disk ) format used by a number of on-premises virtualization hypervisors, including our own Windows Server 2012 Hyper-V. However, for those virtualization vendors that do not support the VHD format, we 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 (Microsoft Azure) 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.

Networking - 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, Reserved IP addresses, and VPN gateways. Deploying your system into a virtual network within Azure 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 then limit the traffic between the subnets thereby creating a multi-layered 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 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 Azure could actually be more segmented and more secure than what you have in your data center today. Azure's default posture with respect to networking is to close all traffic between different areas of your virtual network as well as between your virtual network and the outside world unless you explicitly open the necessary access routes.

Auto Scaling - This no cost service allows for virtual machines to be automatically provisioned or de-provisioned based on certain conditions within the application. 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 a specific time. It also allows for a more minimal architecture to be deployed and maintained because you no longer need to have an architecture available 24x7 that can support all of the spike events, but only for what is minimally needed on a day-to-day basis. 

Shared Storage (i.e. Azure Blob Storage or Azure Files)  - 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 Shared Storage and then link to them through the URL that the Shared Storage service provides.

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 (i.e. AWS S3 = $0.03/GB per month to start) and they provide an extremely high SLA for the content because of their automatic redundancy. 

Automation/DevOps - 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. Microsoft Azure is really at the forefront of this by providing two distinct systems, Azure Automation and Azure Resource Manager (ARM), that can help with all of this. ARM will be used to actually define your application in a scripted way through a template file. The template file can be modified which can then be used to automatically update your deployed environment. Once the application environment is in place, Azure Automation can be used to automate the update of the OS, automatic processes that need to occur within your systems or to even automate the starting and stopping of your deployed VMs.  

Why Do This?  - Using ARM 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, Azure Automation 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 use cost savings for just one single application.

Conclusion

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 future articles 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.