…but is it for play or production?
Some time back, one of my colleagues scheduled a call between myself and several sellers (sales representatives) from Amazon Web Services (AWS). These are/were sales reps or account executives at AWS either selling the entire AWS portfolio or focused specifically on VMware Cloud on AWS. They posed a fairly straightforward question to me…
“Why is this so hard?”
Over the past 4 years I have received many questions similar in nature…
- “Why does it take so long?”
- “Why does it cost so much?”
- “Why is it so complicated?”
- “Why is the networking so complex?”
- “Why can’t we do this faster?”
You can see there is a trend here somewhere… Essentially, the team wanted to understand why customers aren’t able to “move to the cloud” as fast as they want…. After all, a developer can log into AWS and build something in minutes or hours, right? Everything is built with an API, so you can automate it all, right? AWS has everything you need to build anything you want, right?
So if I have a number of applications I want to move from my own data center out to the ‘cloud,’ why does it take so long?
Indeed, AWS, Azure, Google – all of them have a powerful array of readily available infrastructure and application services. An infrastructure administrator or a developer can log into the cloud console and deploy a new service or application in minutes or hours. If you take advantage of advanced capabilities such as AWS CloudFormation templates, or leverage an API through a framework such as Terraform, this time can be reduced dramatically.
Yet over and over, what I have observed is once a customer has made the decision to go “all in” on cloud, invariably it takes longer and is significantly harder than they expect… and frequently significantly more expensive. This differs wildly from the perception (and advertisement) that ‘cloud’ is easy, fast, and cheap.
After all, for those of us that work in IT – either as developers or as infrastructure admins – who hasn’t taken a class, spun up a free instance of something in AWS / Azure / Google, and later been able to declare – “Hey look! I built something!” It is absolutely true that the ‘cloud’ offers an abundance of building blocks that are immediately available to help you build something new. And that right there is the major difference – are you building something new, or are you looking to ‘cloudify’ something that already exists? To understand this further, I propose we examine the problem through the lens of both use cases.
Building something new
As a cloud user, if I am building something new, how am I likely to start? Probably I will sign up for a free account, and deploy a bunch of infrastructure or application services that will incur no charges (or very minimal costs). I can deploy new services at will, frequently with no regard or thought to my corporation’ security posture, governance, billing, networking strategy, IP scheme, and so on. This works for me because after all, most likely I am learning about the capabilities of the service(s), and trying to prove out an idea.
After I have built a thing, after I have proven out my idea for how a system or application may be built in the cloud… then I can think and worry about all those other things. First Gartner, then AWS have built out a framework of strategies for migrating applications to the cloud – rehost, replatform, repurchase, refactor, retire, retain. Once I have proven an idea, I can then start to discuss with my company what strategy makes the most sense. It is at this point we start to discuss ‘landing zones,’ building out an account structure for use with the corporation and other users, working through the billing / cost structure, network connectivity, IP addressing, resilience and disaster recovery, etc.
In other words, it is at this point that things slow wwwaaayyyy down.
Essentially the company has to embrace the idea of building a new data center… in the cloud… on someone else’s physical infrastructure. As you might imagine this poses a LOT of challenges that many customers struggle with.
The lesson here? So long as you are not required to actually put something into production – the cloud is easy, fast, and (sometimes) cheap.
Working with existing systems
On the other hand, if your goal is to move existing systems / applications to the cloud – regardless of your “R” selection – much of that hard work must ‘shift left.’ In other words, we have to take all that corporate governance, process, security, networking, resilience, etc, and dddrrraaggg it to the front of the process. After all, you can’t reasonably take something that is currently processing transactions for your business and just move it without thinking through the implications to networking, security, connectivity, access, performance, etc.
For a company that has not yet addressed how to do business in the cloud using these services, there is no way around it – you must do the hard work. In my experience, it does not matter:
- how much technical debt has been eliminated on premises
- how well your company has adopted DevOps / DevSecOps
- how much automation you have adopted
- et cetera…
You must extend your thinking, governance, security, connectivity, IP strategy, and so on to accommodate a new enclave of computing that previously was not available to you.
A note about resilience
I want to focus for just a moment on resilience, as this is something of a confounding variable in the “R” conversation – particularly with existing applications. None of the cloud providers really promise more than 99.9% availability of their services (with some exceptions like DNS, S3, etc). the overriding presumption is that whatever you put out there must be able to tolerate any number of types of failures…. failure of the underlying physical host or components, networking, or even an entire data center or region. This makes perfect logical sense – the infrastructure doesn’t belong to your company, therefore every effort should be made to ensure your applications and services can survive multiple types of outages.
The obvious problem here is of course that over the past several decades literally the entire IT infrastructure industry has been innovating new ways to provide resilience for the infrastructure that is deployed in your company’s data center. Therefore, moving an existing application from your data center into the cloud also means giving up the inherent resilience built into the infrastructure on which your company has spent millions of dollars. Where will that resilience come from? How will you accomplish that in the cloud?
It doesn’t matter, really, which approach you take… You may need to spend some time learning what the cloud has to offer, and there are great, fast, easy, cheap (often free) ways to do so. But putting something into production in the cloud is a very different affair that requires a great deal more consideration and planning. Some platforms like VMware Cloud can accelerate some of that by providing many of the same infrastructure capabilities in the cloud that you benefit from on premise, and can therefore eliminate much of the time and complexity associated with refactoring or re-platforming an application. Simply ‘Relocate’ the application onto new VMware infrastructure in the cloud!
My two cents? The takeaway here is that putting anything into production in the cloud is a fundamentally different challenge than just building something for test / dev / lab in the cloud. Just because you can say “Hey, mom – look, I built a thing!” doesn’t mean you are ready to move it into production.