AWS Cloud Enterprise Strategy Blog
The Enterprise Cloud Journey
“Do the difficult things while they are easy and do the great things while they are small. A journey of a thousand miles must begin with a single step.” –Lao Tzu
I had an amazing experience at re:Invent this year. I was lucky enough to attend each of the previous conferences as a customer. This year I got exposure to dozens of enterprise customers and a much broader perspective. The amount of new content, services, and customers of every size from every industry, not to mention the growing size of the partner ecosystem, is breathtaking. Three years ago, I could walk through the sponsored booths in 10 minutes. This year it took me over an hour.
Something about the enormity of it stuck out, which Andy reinforced in his keynote.
Cloud is becoming the new normal.
Getting to the cloud is a journey. It doesn’t happen overnight. In my last post I wrote about some of the characteristics seen in enterprises that are well along their journey. An enterprise’s journey to the cloud can and should be fluid. On this journey you have the opportunity to lower costs, move faster, develop new skills, and deliver more reliable, globally available, services to your customers.
Enterprises who have not begun their journey are considering how they’ll introduce cloud into their existing environments. This will allow them to take advantage of what cloud has to offer when the time comes to invest in each of their areas of concern.
At Dow Jones we had enterprise architectures from every decade dating back to the 1970’s. In this case much of the infrastructure and processes, frankly, didn’t work. We were also much too slow to get new initiatives going, making failure very expensive. As we gained experience and competency with AWS through new initiatives, our pace increased. We started with a new application, later setup a VPC to connect that to services behind the firewall, migrated some disaster recovery applications, and, after we gained some experience, moved an entire data center in 6 weeks. Only then did we decide to move 75% of our infrastructure to the cloud over a 3-year period. We learned so much along the way that suddenly we found we were better and faster at building things in the cloud then we were atop our on-premises infrastructure. We began to think of our infrastructure as the superset of AWS and our own data centers, heavily favoring AWS for each initiative.
I’ve found, both through personal experience and talking to customers, that once your journey is underway and you gain experience things will move at an accelerating rate. The benefits will become apparent, and as you understand how to deal with the new normal, things that may have seemed infeasible will become migration candidates. At each stage you can decide whether or not you will lift and shift, redesign for the cloud, use the AWS marketplace, augment with open-source, or some combination thereof. The right path will present itself as you learn.
That said, the plethora of available AWS services and the constant improvements being made to them may seem overwhelming when you are considering how to introduce cloud computing into a large technology organization. You may be wondering how you adapt AWS within your established network topologies, server and storage models, internal virtualization, desktop management, and governance models.
I have good news for you….
AWS is not an all-or-nothing proposition. There are well known strategies for using AWS alongside your existing investments. How quickly you migrate is completely in your control and should be dictated by business needs and pressures.
Your goal on day one will not likely be to move everything into the cloud. It is not reasonable to put the business on hold solely to migrate existing infrastructure, especially in cases where existing infrastructure serves its purpose.
We hear from many customers that they find it incredibly easy to try AWS without modifying their existing infrastructure. After that, it doesn’t take much more effort to establish connectivity between your existing infrastructure and AWS. Once this connectivity is established, almost anything becomes possible. At this point, your journey has begun.
A Typical Enterprise Cloud Journey
Over the past few months, I’ve had the opportunity to speak to dozens of our enterprise customers across many industries, hailing from all over the world. Combining this with my experience transforming Dow Jones and News Corp into a cloud-first enterprise, I’ve noticed a common journey pattern emerge:
1. AWS pilot project. This could be a well-defined project or an R&D effort with vague success metrics. Common initial use cases in the enterprise include simple websites, mobile application back ends, disaster recovery sites, additional capacity in development and test environments, non-mission critical application migrations, or the desire to create a new standard for upcoming work.
2. VPC integration. This establishes the connectivity so that AWS can be used as an extension of existing corporate networks. Network engineers should do this thoughtfully so not to expose anything that would make the organization uncomfortable, but otherwise this is a very straightforward exercise that should take hours, not days or weeks.
3. Hybrid workloads. Most workloads in the enterprise will fall into this category. Generally there will be some critical asset that sits within existing infrastructure that will take time to move to the cloud. There are likely other, more nimble, systems that depend on this asset that are immediate migration candidates. Focusing on these systems first will reveal significant benefit while building the experience and confidence needed to move the shared asset later. It will be easier than you thought once you’ve done this a few times. I am seeing a growing number of customers that, once they gain significant experience running hybrid applications, adopt a cloud-first policy. This encouraging paradigm reverses the burden of proof. Rather than having to prove how a project can be implemented in the cloud, the organization must prove why it can’t. This is often coupled with a predisposition to use hosted SaaS solutions for common corporate back office functions, such as HRIS, e-mail, and collaboration systems.
4. Direct connect. Setting up dedicated connections from on premise data centers to AWS facilities may be required for network intensive applications operating in hybrid mode. In my experience you’ll know when you need this. It should not be viewed a prerequisite to trying hybrid workloads.
5. AWS native ecosystem. As more assets move into AWS and take advantage of the features of the platform, an organization may reach a tipping point where it becomes more capable of implementing entire systems in the cloud than in a hybrid environment. Several companies have come to this conclusion and have adopted an “all-in” cloud strategy– Infor, Sun Corp, and Kempinski Hotels are a few examples of this.
Does this match what you’ve seen in your organization? Feedback welcome.
Keep building,