Over 8,000 people are at KubeCon in Seattle. Every major tech company and businesses I've never even heard of are here and trumpeting their Kubenetes distros -- about 80 of them. IBM recently bought Red Hat for a cool $34-billion. I, and others, think they did it to get Red Hat's Kubernetes expertise. Why? To answer this question we need to look into the hybrid-cloud model.
First, IBM CEO Ginni Rometty said that the top customers want to move their corporate data "across multiple cloud environments with no lock-in." That means a hybrid cloud.
A hybrid cloud is one that runs simultaneously on a public and private cloud. Historically, that's been done with three models: Hybrid-cloud management software such as HPE Helion; vendor-native hybrid cloud platforms, such as Microsoft with Azure and Azure Stack; and Platforms-as-a-Service (PaaS) clouds, including Cloud Foundry, which can bridge over Infrastructure-as-a-Service (IaaS) clouds.
Also: Understanding the Cloud Computing Stack: SaaS, PaaS, IaaS TechRepublichttps://www.techrepublic.com/resource-library/whitepapers/understanding-the-cloud-computing-stack-saas-paas-iaas/post/?regId=&asset=3343303
There are places for each of these approaches, but the first two tend to be difficult to deploy. The PaaS model is easier... if you want to run a PaaS.
Wouldn't it be nice if you could easily run your workloads on both your own datacenter and private cloud and, when needed, a public cloud? That's what Kubernetes, the container orchestration program, promises. It also helps that the wildly popular Kubernetes runs on essentially every cloud platform in existence.
IBM is far from the first company to see how Kubernetes can make hybrid clouds simpler to run, manage, and deploy. A partial list of other companies, which are working on Kubernetes-based hybrid-cloud offerings includes Cisco, Google, HPE, and VMWare.
So, IBM makes the biggest software company acquisition in history just to be compete better with the others? No, Big Blue bet the company because it believes Red Hat's exceptionally strong developer team can fix Kubernetes' fundamental hybrid-cloud problems.
You see, I said Kubernetes makes making a hybrid cloud easier. I didn't say it was easy. That's because it's not yet. The promise is there. The reality isn't.
First, even to keep up with Kubernetes is a full-time job. Next, running a hybrid cloud can be very labor intensive. Google itself, Kubernetes' dad, states to administer and control each Kubernetes cluster as an individual entity in a hybrid cloud you must manually create the pods and services in each cluster. That's no fun.
You can, of course, script away much of this donkey work. Melanie Cebula, an AirBnB software engineer, explained that's what AirBnB does with its massive Kubernetes deployment in her KubeCon keynote. This helps a lot, but it's still not as automatic as most cloud developers would like.
Next, you must use data center-aware service discovery mechanisms such as Consul or Linkerd, to facilitate cross-cluster and cross-environment service discovery with multi-cloud Kubernetes deployments. Again, that's not easy.
Let's say you want to delegate your hybrid-cloud Kubernetes pods to run on specific nodes. For example, you might keep your back-end data on your private cloud while using a public cloud for your front-end interface and compute. You can do that with Kubernetes Labels and Selectors or Kubernetes virtual cluster namespaces, but again there's some manual work required. That's not what you want from a cloud.
To solve some of these issues, we need a simpler way to manage multiple clusters. Specifically, we need to sync resources across clusters and cross-cluster discovery, which auto-configure DNS servers and load balancers with backends from all clusters.
There is such a way. It's called Federation V1. But, here's the bad news: It's largely alpha software. Here's the other bad news: This application programming interface (API) is almost certainly not going to make to general availability.
The good news -- yes is there some -- is there's a Federation V2 effort in train to implement a dedicated Federation API. This API will provide the multi-cluster administration and application management needed to automate hybrid clouds. Besides delivering on the alpha promises of the automated Federation approach, it will also support the batch workflow-style continuous deployment systems of programmers like Spinnaker.
This all sounds good, but Federation V2, as I write this in late 2018, is still a work-in-progress. It's not even alpha code yet.
We'll get to the promise of easily deployable hybrid clouds. But, for now, everyone working on Kubernetes-based hybrid clouds is having to deploy their solutions the hard way.
Once that's done we'll see which companies do the best job of delivering these services to their enterprise customers.