Perspective on multi-cloud (part 1 of 3) — Thoughts on the cloud providers.
Multi-cloud keeps coming up in conversation these days. In this series I will (hopefully) provide useful perspective on the topic of cloud providers, the utility of decoupled architectures, being smart about cloud provider lock-in, and the tension that exists between private and public cloud deployments.
I don’t claim prescience here, but having been quite active in building a both a public cloud offering (Google Compute Engine), an open source abstraction on infrastructure (Kubernetes), and more recently working with customers running on a broad cross section of infrastructure technologies. I hope you will find my perspective useful.
Since this is a pretty broad topic I will write this series in three parts: (1) some thoughts on the cloud providers and the role of technologies like Kubernetes in multi-cloud deployment, (2) the gap that exists between public cloud and on-premises cloud platforms and (3) (this will be a little more technical) some thoughts around federation, multi-cloud architecture and the roles cloud providers may take.
These posts will be grounded in a set of observations on the current ecosystem, and offer some friendly advice (actual mileage will vary 🙂). Let’s get going:
Observation 1: The public cloud isn’t a one horse race. Microsoft and Google are running. Hard.
Amazon has done some truly remarkable work. They defined a genre and despite the obvious advantages of their emerging competitors (Microsoft and Google) have executed superbly. Today they have a clear lead in this space and are the horse to beat. Every re:Invent conference showcases an impressive array of new services and the pace of innovation is palpable.
Despite the remarkable and obvious execution prowess that Amazon has demonstrated I am nevertheless bullish on the futures of both Microsoft and Google. This isn’t about Amazon’s lack of execution, they have done legitimately wonderful work. It is recognizing and understand the emerging strength of their competitors. Google and Microsoft have strong pre-existing leverage-able assets that they bring to this segment that should be understood.
Microsoft is executing well. Both in the overall quality of their cloud offering, and in their ability to sell it to people. It has been startling to see the overall improvement in the quality of their underlying infrastructure in a relatively short period of time. If you looked at Azure a year ago and decided to pass on the infrastructure, I encourage you to take another look; it is a fundamentally different platform than it was 1 year ago.
Beyond the trajectory of their service quality, they have shown a strong pragmatism with respect to open source software. This is both refreshing and obviously necessary for them to emerge as a true force in cloud. They have obviously moved past a ‘Windows only’ world. Azure’s position with everything from operating system to orchestration technology points to an ‘accept all comers accepted’ world view. If you need an example of this, think about how unlikely it would have been 5 years ago to see Microsoft join the Linux foundation at the platinum sponsor level.
I look at the trajectory Microsoft is on, and having a decent sense of their relentlessness as a company (I worked there for over a decade), and can unequivocally say they play ‘for keeps’. Keep an eye on them.
Google is the dark horse in this race. They don’t have the sales and go-to-market muscle of Microsoft (yet), but the underlying technology is legitimately good. When you look at their suite of offerings, their network stands out first and is quite unique. Everything transits on their global private network. The core compute offering is also surprisingly good. Beyond the more mundane services they are creating new classes of technology that other cloud providers will struggle to compete with. Look at their Spanner service — using a global array of atomic clocks they have created a highly scalable, globally consistent relational database. I cannot overstate how technically hard this is to accomplish. You will get some of the way there with mundane open source technologies, but in the end without the atomic clocks you will miss the magic. Google’s services offerings are massively differentiated vs what anyone else can deliver. No one else can do this.
Their machine learning offering is also head and shoulder’s above anything else commercially available in the industry from what I have seen: nothing even comes close when you factor in the TPU acceleration of Tensor Flow. (Side note: Amazon and Microsoft invested in FGPA offerings that will likely considerably accelerate things, but there is definitely something to be said for purpose built silicon that is built around the open source base technology.)
First point of friendly advice: Even if you are not ready to go multi-cloud, it makes sense to ‘hedge’ on being able to benefit from the services and capabilities other cloud providers offer (if not now, certainly in the future). Think about open source technologies like Kubernetes and Docker as a way to decouple your developer workflows and apps from your cloud provider.
Observation 2: Nothing creates vendor lock-in like provider specific service dependencies, but that is okay as long as you are being smart about it.
A lot of folks argue that the key point of lock-in is data gravity. Once your data is in one cloud it is impractical to move it. There is some truth to this, but it is technically easy to solve. Amazon demonstrated at the recent re:Invent that there is nothing in the world that can move data more quickly than a semi truck full of hard drives. While those trucks only make one way trips for now, it is reasonable to assume that competitive and legislative pressure could change this.
In my mind the key point of lock-in isn’t data locality. It is cloud provider unique services. Now I am in no ways suggesting that enterprise be afraid of cloud provider services. There are some really useful capabilities that you will only get when you buy into a service. Just recognize that detangling your infrastructure from deep service dependencies will likely be even more difficult than getting your data out of a cloud provider’s offering.
Efforts like the open service broker API working group are tackling the challenge of creating a structured way to map services into a cluster environment. Definitely keep an eye on this work that takes the Cloud Foundry service broker as a working baseline and generalizes it for broader platforms.
Second point of friendly advice: Think about using formal service abstractions that allow more control over which services are made available to your engineers. This space is nascent but will be an important point of control in the future.
Having said all of this, there are times when you really should look at cloud provided management services. Amazon RDS is a good way to manage a database. If you want to go somewhere else you can; it isn’t that intrinsically different than any normal MySQL implementation. Be judicious about betting on services that don’t have an OSS alternative, but recognize that there are some legitimately amazing cloud specific services. Just understand what dependencies you are taking.
Third point of friendly advice: Be judicious about what dependencies you take, and approach each specific service dependency on an ROI basis. Focus on hosted services based on open source software technology; these will not lock you in.
Fourth point of friendly advice: Think about building your own reusable services for your own organizations and delivering them into your environments vs betting on the cloud providers services. (More about this in part ii of this series)
Up next, the difference between public and private cloud…
