AWS is not building Hybrid Cloud (as we know it)

AWS is not building Hybrid Cloud (as we know it)

Chris Evans Cloud, Opinion Leave a Comment

The main keynote at AWS Re:invent has turned into something of a marathon that isn’t for the faint-hearted. At three hours long, CEO Andy Jassy packs a huge number of announcements into a single monolithic presentation (ever heard of micro-services/micro-presentations, Andy?)

Thankfully, this year I watched from the comfort of my lounge and via the benefits of YouTube (and the pause button). As the presentation came to an end, I was struck by the lack of reference to hybrid cloud, despite the announcements of AWS Outposts (now GA) and AWS Local Zones. Both technologies deliver hybrid cloud in all but name – however, it’s not hybrid as we know it.

Hybrid Cloud Defined

A reasonable definition of hybrid cloud typically assumes disparate on-premises and public cloud infrastructure. Locally, enterprises continue to use technologies from HPE, Dell and VMware. In the public cloud, the specifics are obfuscated from the customer. Much of the adaptation to hybrid/multi-cloud focuses on how to move data back and forth, how to run applications on disparate hypervisors and how to bring non-standard services together.

Inevitably, this model exists because most enterprises have large amounts of on-premises infrastructure, hardware, and software to amortise and staff with skills that are heavily invested in traditional technologies. Moving to the cloud means integrating these platforms with cloud technology.

Hybrid Defined

Update 18 December 2019: I added the following comments in response to my friend W Curtis Preston’s podcast on Outposts.

The definition of “hybrid” from Collins dictionary states:

hybrid is an animal or plant that has been bred from two different species of animal or plant.

Collins Dictionary

You can find more details on how the term hybrid is defined by following the link. It’s clear that a hybrid system is built from multiple “species”, which in the case of cloud seems reasonable to assume different cloud implementations. This could be on-premises with public cloud or an integration of multiple public clouds.

Outposts is clearly not a “hybrid” because it’s the same “species” of technology simply running in a different location. AWS also now offers Local Zones which is an “off-premises” implementation of AWS infrastructure in a local data centre to clients (initial Los Angeles). This isn’t hybrid cloud either, because it’s the same infrastructure as core AWS. For me, hybrid means bringing together disparate implementations of technology, not running the same technology in multiple locations.

End of Update.

The AWS Cloud

AWS clearly sees things differently. Whether the hardware exists in the customer’s data centre, in a local data centre or an AWS mega data centre, the platform and infrastructure are all the same. There’s no attempt to bridge technologies from Dell, HPE or Cisco into an AWS configuration. You (currently) can’t run AWS locally on anything other than AWS hardware. You can’t run any other software/applications on AWS hardware other than AWS solutions (except for VMware on AWS).

This isn’t hybrid cloud as we understand it.

Assimilation

Should we care about this approach? Does it matter that customers will rent hardware that has no other purpose? I think that depends on what the long-term goals for AWS will be.

Until Outposts was announced, it seemed that every AWS offering was focused on moving data and applications into the data centre. Even in this post, I made an assumption that we were only looking at techniques to get more applications and data into the AWS platform. Initially, Outposts looked like a solution for hybrid cloud. But as I pointed out in this post, I think Outposts is a method of extracting applications from the data centre.

Resistance is Futile

Think about it for a moment. Step one, AWS offers hardware to run VMware workloads locally. Outposts is charged monthly, moving existing workloads from a Capex to Opex model, with little or no management changes.

Step two, AWS offers to run some of those workloads centrally in AWS. Again, there’s little or no management change and potentially some Opex change (which AWS is likely to make attractive).

Step three, AWS offers to analyse your workloads and provide migration services to move them natively into AWS offerings. The transition is made attractive from an Opex perspective.

Over several years and through a series of iterations, applications move into AWS, providing constant growth for the company.

It’s Not All Bad

Although I’ve deliberately used Borg analogies, this process isn’t necessarily bad. I imagine many customers will want and like this transition process because it allows the adoption of the public cloud without a big-bang approach. If I was a customer today, then I would certainly be thinking of this type of migration strategy.

The risk for the enterprise is that there is no (easy) way back if AWS public cloud doesn’t work. The customer eventually owns little or no hardware and so has to start from scratch with capital purchases. On-premises skills will dwindle.

The Architect’s View

This post may read as overtly negative, but that’s not my intention. Actually, I think AWS is playing a very clever game that both reduces barriers to entry for new customers and erects barriers for leaving. Business is all about building friction into leaving (whilst of course, delivering value to the customer). AWS is achieving that very well indeed. My only caveat is to highlight the implications of moving to an AWS-style hybrid cloud. It’s not hybrid at all, just AWS in a different location.


Copyright (c) 2007-2019 Brookend Ltd, no reproduction without permission, in part or whole.  Post #4be8.