A friend of mine claiming to be Italian (we are still trying to determine if he qualifies or not) who read this article before it went online told me that he could not recognize me. He found my introduction to be surprisingly soft. I somewhat agreed. For once I tried to be nice but apparently managed to disappoint people around me. Therefore, if for any reason I managed to hurt your feelings, that is not my fault and I will be more than happy to share his Twitter handle with you (who knows he might even get a follower or two).

Therefore, I decided for the sake of his Twitter stats and profound passion for straight-talking to start this way.

Private cloud is not a cloud. The thing we call a private cloud today is at best an automated VM provisioning platform built around the idea that if we close our eyes we can prevent things from happening, that we can change the course of reality. When VMware showed up in early 2000, a very similar thing happened, a complete corporate denial. There was so much love for those Intel powered 4U boxes and eventually we let them go. Denying reality today is a very expensive hobby not only because you are wasting money in something that will never be as scalable, resilient and secure as the AWS cloud platform. You are also wasting time that is necessary for this inevitable transition to happen. Cloud is so much more than a VM hosted elsewhere and billed hourly. Do not let them fool you, global reach, infinite scalability, managed services, possibility to build different types of applications that could never run in your datacenter, is what the public Cloud is really all about.

As History taught us, we do not stay in denial forever. I guess that as an industry we need time to readjust, fight our fears, and unlearn in order to learn again. In order to illustrate graphically where we are today let us have a look at the following graph.

As you can see, that “Oh Fuck!” moment is a crucial element here and this is where things start accelerating. When it comes to public Cloud deployments, we are way behind that point. Reasons why this is happening over and over again are hidden in the darkest corners of the human soul or even our society and would require sociological and philosophical analysis that is way beyond the scope of this article. For now I will try to focus on Microsoft Workloads on AWS and maybe tackle one or two urban legends.

I guess you are already familiar with one of them stating that AWS is very Linux friendly platform. That is of course fundamentally false. AWS is “common sense” friendly platform. Reason why there are so many Linux workloads running in the AWS Cloud can be explained by a combination of “Oh Fuck!” enterprise IT adoption cycle, and the fact that the “Rest of World” runs a lot of Linux systems. The simple fact that more than 80 percent of on-premises server boxes are running some version of the Windows operating system does not say anything about how Windows friendly the AWS platform is, it just emphasizes the fact that enterprise IT is just not there yet.

This brings us to a second urban legend stating that the other Cloud providers are having the best platform for running Microsoft enterprise workloads. This make sense intellectually speaking but is also completely wrong. Let us try to illustrate why with a very basic example. One of the first things you require when running Microsoft Enterprise workloads in any Cloud environment is a capacity to automate the creation of an OS golden image that matches your corporate standards to be further used for deploying different types of applications and services in your environment. You want this golden image to be private and you definitely do not want your Cloud provider to modify it in any way otherwise you could not guarantee that it will still comply with your corporate standards. AWS provides this by allowing you to build private custom AMIs that you can deploy worldwide. Cloud-provider-who-must-not-be-named does not have an equivalent today. The amount of black magic required for creating something as simple as Windows golden image is beyond human comprehension. A golden image that once deployed will complete a sysprep, join the domain and bootstrap some custom PowerShell code. Deploying a machine from that image is unfortunately a completely new chapter. I can assure you this is not a joke but if you want to build a server from that image, they must share the same storage account. That requires further scripting if you have more than one storage account in order to pre-copy your image prior to launching a server build.

I hope this concludes the Windows friendliness debate.

If you are still reading me, you are probably asking yourself the question of where do we go from here. How do we move those Microsoft Workloads to AWS?

Well an enterprise IT is a very complex system, and as all complex systems contain changing mixtures of failures latent within them. Eradication of all latent failures is limited because it is difficult before the fact, to see how such failures might contribute to an accident. The failures types change constantly because of changing technology, work organization, and efforts to eradicate failures. There is a huge amount of infrastructure entropy accumulated in enterprise IT during these last decades. A big part of above described complexity comes from the inherited entropy in our systems. That is why we have the impression that building Cloud native apps is easy and moving enterprise workloads to the Cloud is hard. Entropy, there is no escape from it. Entropy can be significantly reduced by making intelligent architectural decisions and applying new operational models.

Changing ways you are doing things is probably the best way to begin your cloud journey. The AWS Cloud platform has many qualities but black magic is not one of them, it will not transform your applications for you. You will need to learn how your applications are working in order to experience the real power of the platform once they have migrated. Alternatively, if you suck on-premises today, you will be pleasantly surprised by the lack of change when moving to AWS. You need to learn stuff first, start small, experiment, deploy, automate, use managed services, reiterate… The more you learn, the more you will realize that the AWS Cloud platform combined with automation is a very efficient entropy-killing machine.

Prior to design your application migration options, it is essential to assure that you have a fully automated and deployed AWS core infrastructure stack. You will also need to make sure that you have connected your datacenter with AWS in a highly resilient manner and that you have enough bandwidth to support this model. Active Directory and DNS infrastructure need to be extended in the VPC in order to support your applications. Efficient identity management needs to be in place from the beginning in order to support scale. And one more thing: try to make it as simple as possible providing that it complies with your requirements.

When it comes to migration options that involve engineering effort, we can identify three possible migration approaches :

• Rehosting
• Replatforming
• Refactoring

Efficient migration strategy is a combination of all three trying to reach the infrastructure equilibrium where infrastructure entropy and cost are balanced. That is extremely tough to achieve and it is not an exact science.

Lifting and shifting hundreds of boxes to AWS will not make your applications interactions will be more efficient or more resilient nor reduce your infrastructure entropy, or make those Windows 2003 / 2008 machines go away. The benefit with this approach is that you can go relatively fast. On the other hand, when implemented correctly, refactoring and replatforming can reduce the entropy and create more value to the business.

Let us concentrate a few seconds on refactoring and replatforming. The common denominator of both of them is app-holistic migration approach that requires time, preparation and engineering effort. They are both iterative and rely heavily on automation allowing you to mix your traditional enterprise applications with AWS managed services in order to maximize the migration benefit. They are both production non-intrusive and can be fine-tuned for blue-green deployment scenarios before the decision to press the button. In the unlikely case of a migration failure, falling-back on-premises is extremely fast. Automating application and server deployments allows us to build loosely-coupled systems relying on balanced usage of open source automation layers, enterprise grade software and modern operating systems. Bottom line, creating application and infrastructure automation stores allows you to rebuild quickly and reliably using the flexibility and global reach of the AWS cloud platform.

More than three years ago, when we first deployed our corporate Windows stack on AWS, I felt the platform had huge potential. In less than three hours, we managed to fully deploy a Multi-AZ Citrix stack for our customer using Packer for windows AMI automation, chocolatey as a package manager, myget as nuget code repository and AWS S3 for storing installation binaries.

Today the number of applications and infrastructure elements we have automated has grown exponentially and during that time AWS Windows support got better and better. We have direct access to AWS services from Windows PowerShell and AWS SDK for .NET. Official support for C# in Lambda opens a completely new spectrum of possibilities when it comes to modern management and automation of corporate infrastructures. Recent announcement of Amazon EC2 Systems Manager is another step into the right direction when it comes to managing Microsoft Workloads. The Amazon EC2 Systems Manager enables you to remotely manage the configuration of EC2 instances or servers in your on-premises environment and to maintain a consistent configuration baseline. Combine wide variety of managed services, tons of different storages and instance types and you got yourself an extremely powerful platform capable of running virtually anything you can imagine.

Like it or not AWS has profoundly changed the IT landscape and there is no going back. Organizations or individuals refusing to accept this are slowly but surely sliding into oblivion. It is time to move on. Today we have a true opportunity to make Windows great again and the AWS Cloud platform is providing everything we need to make that happen. The real question is what are you going to do about it…