A Hybrid Cloud Architecture Ah-Ha! Moment

Each week I meet a few more executives that are transforming the way technology delivers value to their business using the cloud. Motivation for getting started with the cloud varies, but a consistent theme in my conversations is that the cloud allows organizations to devote more resources to their core business, move faster, and be more secure.

This transformation won’t happen overnight, and I often refer to the process as a Journey. During this time, your enterprise still needs to operate its existing IT assets in order to keep the business running. While most enterprises I speak to are in the process of migrating some or the entirety of their IT portfolio to the cloud, they’ve also realized the cloud is not an all-or-nothing value proposition. As each enterprise realizes this, they’re able to bridge their on-premises IT assets with the cloud and use that bridge to migrate the gravity of their IT portfolio to the cloud over time.

Last year, I wrote about three myths around hybrid architectures in the cloud, which I still encounter when discussing hybrid cloud architectures with executives today. If you’re still shaping your organization’s hybrid cloud architecture perspective, I encourage you to consider the points I made in that post.

The rest of this post details the “ah-ha!” moment my team and I had when I was the CIO at Dow Jones and we first implemented a hybrid cloud architecture.

A Hybrid Ah-Ha! Moment

In 2012, my boss (and then CEO of Dow Jones) had a hypothesis that we all felt was a great business opportunity: If all subscribers of the Wall Street Journal, one of Dow Jones’ flagship B2C products, had much of the world’s wealth, and all subscribers of Factiva and Dow Jones Newswires, Dow Jones’ B2B products, managed much of the world’s wealth, we could create a valuable platform by giving them a mechanism to connect and communicate with one another.

We were starting from scratch and wanted to move quickly. We assembled a very small team of engineers and designers to build this concept out, giving them the freedom to choose whatever tools they thought would get the job done. Six weeks later, with a little bit of open source, automation, AWS services, and a lot of hard work, we had a highly-available and disaster-indifferent application up and running. Our newfound ability to deliver technology to the business quickly became our “hero” project, and helped us encourage my team and executive stakeholders to come on the Journey with us.

As we integrated this application into more of our products, we found that we also needed to integrate it with some of our internal-only identity management systems. Some of these systems were not (and should not be) exposed to the internet and were therefore unreachable from our application running on AWS in the public internet.

Engineers across our networking, infrastructure, and development teams began to look for a solution to this problem. After a little bit of research, we found we could leverage Amazon VPC to create a virtual network within our internal IP address space and put our application inside of the VPC.

After reading the AWS documentation and deciding how we would manage the integration of AWS Security Groups with our internal firewall rules, the team went to work. Inside of 45 minutes, they created the VPC, took a snapshot of the instances we were running on the public internet, brought the instances up in the VPC where they were assigned IP addresses from our internal subnet, routed inbound traffic to the new instances, enabled connectivity from the instances to our internal identity systems, and completed the migration.

We were amazed at how simple this was to set up, and even more amazed by the opportunity we realized we had for enhancing and extending our existing legacy systems with systems we built in the cloud.

Over the next several years, our DevOps team (otherwise known as our Cloud Center of Excellence) codified what we learned during this exercise by automating VPC creation and governance into a handful of reference architectures for different areas of our business. With this simple but powerful strategy, we used this hybrid architecture model to build and enhance all of our existing systems in the cloud without having to migrate everything at once.

Since then, I’ve spoken to many executives who have had similar “ah-ha!” moment experiences. Once they realize they don’t have to scrap all of their existing infrastructure investments and can still take advantage of the cloud, a number of possibilities open up. This gives their teams time to learn, ride out existing investments/depreciation schedules, and still benefit from the elasticity, agility, security, and cost characteristics of the cloud.

Have you had an ah-ha! moment setting up your hybrid architecture? I’d love to hear about it!

Keep building,
–Stephen
@stephenorban
orbans@amazon.com

Note: Implement a hybrid architecture is the sixth of seven best practices I’m writing about in my Enterprise Cloud Journey series. The other six are: provide executive support, educate your staff, create a culture of experimentation, engage partners, create a cloud center of excellence, and implement a cloud-first policy. Stay tuned for more on each of these, and check out the e-book collection here.