One thing that I hear all of the major Cloud providers talk about, especially from their Sales and Consulting folks is the importance of App Modernization when customers are moving their systems to the Cloud. I definitely agree that it is important to try and take advantage of Cloud native technologies that can improve your software or systems and deliver better cost models and better efficiencies of scale within your application.
However, not every customer is ready or willing to sit down and make a bunch of code changes or go through a rigorous testing cycle that would be required when trying to move their custom or even COTS based software into a native Cloud application deployment model. Does that mean that customers shouldn’t consider moving their systems to the Cloud or that they can’t achieve cost improvements, scaling or administrative efficiencies when only focusing on Infrastructure migrations? ABSOLUTELY NOT.
I would like to talk about a concept that I have not heard Microsoft, Amazon, or Google talk about and that is, Infrastructure Modernization. This concept is primarily focused on those customers who either want or need to focus on Infrastructure as a Service (IaaS) for their first workloads in a Cloud environment. How can they migrate into the Cloud using that model while still taking advantage of cost improvements, scaling, and efficiencies that the Cloud environments have to offer?
NOTE: For all services that are discussed below, links to additional information about each one will be provided at the end.
What is Infrastructure Modernization?
Let’s start by giving an introduction into what exactly I mean by Infrastructure Modernization. The key is keeping all of your Compute, Networking, and Storage that you are used to as close to the same as possible. Instead, you take advantage of some of the cloud native services that can be used to replace some of the ancillary services that you have to manage your environment. I am referring to some of the following types of services:
- Disaster Recovery & Backup
- Configuration Management
- Monitoring, Logging, and Alerting
These are just some of the ancillary services that many of the major Cloud providers provide as a service which can then be leveraged to reduce the overall management footprint that is required to maintain your existing environment after it is migrated to the Cloud. This particular list is also the easiest to implement as part of your migration project. Using this list, let’s take a look at each of them in a little more detail while also talking about the one item that should be implemented for all migration projects and that is Right-Sizing and Scaling.
Right-Sizing and Scaling
First of all, the basics of Infrastructure as a Service (IaaS) are Compute, Networking, and Storage with everything from the Operating System and up being managed by you. There are not that many differences between the different Cloud providers with respect to these areas of the Cloud. All three of the major players provide the same feature sets in pretty much the same way.
With this as a starting point, everyone that is migrating to the cloud, should consider the idea of right-sizing and scaling when migrating their IaaS deployments. Most customers like to look at the Cloud as an immediate improvement just by doing a Lift and Shift into their chosen Cloud provider. However, this can actually be more expensive in the long run because the architectural requirements for deploying applications and systems in a data center is very different from those of a Cloud environment. In a data center, you need to architect for the maximum load that your systems may need to support. However, in the Cloud you only have to architect for the minimum and then allow the Cloud environment to adjust based on need.
This where the right-sizing comes into play. Based on the typical load, not maximum load, of your Compute and Storage, you determine what the best size is for your Virtual Machines (VM) and then start from there. Implementing the right-sized set of VMs can then be automatically adjusted using a combination of automation and scaling, but only when the demand actually specifies it. Doing this allows your standard and long-term architecture to be made up of much smaller VM sizes than if you were to duplicate what is currently in your data center while still being able to scale out or up to what your maximum requirements might be when needed.
The above video is an example of how to setup an automated scaling solution in Azure using IaaS, but this same capability can be implemented within AWS or Google as well and this is a must first step towards Infrastructure Modernization when migrating your workloads into the Cloud.
DR and Backup
The next thing to think about are some of the ancillary services that you have in place within your data center to support your infrastructure. One of the most common that all customers have in place, especially when it comes to production level systems and that is Backup and Restore. Within this same area of focus, Disaster Recovery can also be considered for discussion.
To make either of these happen within a Data Center can be quite expensive. The Backup and Restore function requires a good amount hardware and software, especially with respect to storage. This is even more true with respect to Disaster Recovery. If you are doing everything in a Data Center, then you probably need to have access to a second Data Center that is at least 50 miles away from the primary location and then you need to have access to hardware and software so that your applications and virtual machines can be replicated to the secondary location.
Both of these functions can be very easily replaced by leveraging Cloud based services there by reducing costs tremendously. What exactly does that mean?
In the case of Backup/Restore, Microsoft provides a service called Azure Backup which can work with both On-Prem and Cloud based Virtual Machines providing backup and restore capabilities for the entire VM or just Files/Folders and it is a very non-intrusive service. The cost is strictly based on a small per/VM cost and the amount of storage required to keep the Backups around based on your defined retention policy. This is all controlled through the installation of an Agent into your VM which talks to the Azure Backup service.
A very similar function can be provided for Disaster Recovery, called Azure Site Recovery. In this case, another Cloud based service can be used to replicate VMs to another location and then stored. This can be done from Data Center to Data Center, Data Center to Azure or Vice Versa and of course from Azure region to Azure region. The cost point for this service is a little more expensive and there is a larger configuration requirement, but when using Azure regions as a secondary location, you can make sure that the distance between primary and secondary locations is of an expected distance when in a disaster recovery scenario.
Configuration Management
The next area of focus when talking about Infrastructure is around all of those virtual machines that you are managing and their corresponding Operating Systems and Applications that are installed within. Making sure that all of your VMs are of a particular standard from a configuration perspective and stay that way over time can be a full-time job for many people if handled manually.
Most companies have implemented some form of Configuration Management within their environments to help alleviate that using tools such as Chef, Puppet, Ansible, etc. Unfortunately, this requires one to many VMs to deliver on that Configuration Management which of course adds to your Infrastructure footprint. What if your Cloud provider could give that to you as a Service thereby reducing the overall infrastructure overhead required to manage your entire VM footprint? Microsoft can actually take that a step further, by also providing Update, Inventory, and Change management features on top of the standard Configuration Management.
Both Amazon and Microsoft can provide Configuration Management as a service, with Amazon providing a more robust set of options where as Microsoft is the only vendor that can also provide Update, Inventory, and Change management capabilities. In both cases, the cost is very minimal where you only pay a per VM cost for the Configuration Management piece and in the case of Update, Inventory, and Change management from Microsoft, the cost is strictly based off of the cost to store the logs generated from your VMs which are then used to determine when something changes or needs to be updated.
Monitoring, Logging, and Alerting
Last and certainly not least, is what I like to call the Operational management of your Infrastructure. This is where you are getting Live information about the performance of your environment as it is being used. This kind of data comes from many different sources and needs to be able to be seen by those that are actually supporting the production level environments.
To provide this functionality when you are in a Data Center, there is going to be a pretty hefty requirement for both Hardware and Software much like was discussed with Backup and Disaster Recovery. However, when in a Infrastructure based Cloud environment, all of the major Cloud providers can deliver this same level of functionality and most of them do it for free. You may have to pay storage costs for Logs that you need to create queries against and you may need to pay for specific Alerts that you define, but overall, the cost of monitoring and logging within your Cloud environments are going to be very negligible when using Cloud Native services.
In the case of Microsoft, they provide the Azure Monitor service completely for free which provides Real-time monitoring of many different performance metrics for your VMs, Networking, and Storage services. It also provides for Diagnostic Logging and Auditing of actions within your Azure subscription and in this case the only thing that you have to pay for is the storage of your Diagnostic Logs. This is just the start of what Microsoft provides from a Operational Management perspective and the majority of it for free.
If you would like to learn more about each of the features, you can take a look at my Azure Monitoring & Logging 101 Part 1 post, which talks about each of the items that I mentioned and others.
Conclusion
I realize that this blog post does not go into a tremendous amount of depth with respect to any services mentioned above. Hopefully though, it does at least provide you with some food for thought when thinking about how to migrate your Infrastructure based workloads into the Cloud. In my opinion, you should not be thinking only about Lift & Shift options, but spend a little time trying to determine if you can take advantage of some of these modernization services that I mentioned to help alleviate some of your administrative and cost burdens. All of this will make the move to the Cloud all the more attractive to those making those kind of decisions.
