KubeCon + CloudNativeCon took place in Seattle last month and had twice as many attendees as the last conference, all there for a brand new vision of Kubernetes and the projects in its environment. They weren’t disappointed, and KubeCon + CloudNativeCon Seattle 2018 was all about moving forward and just being done with the old way of doing things like trying to run Kubernetes all by yourself. The new vision is all about not reinventing the wheel, never having to rewrite code, and having a crystal clear picture of where you and your tools fit in this giant thing called a Kubernetes stack.
Drilling down at KubeCon: The CNCF stack
Google Cloud Platform’s Kelsey Hightower pointed out in his interview at KubeCon that the so-called “Kubernetes Stack” is basically just Kubernetes at the core and then building on top of it and while Kubernetes is great on its own, there are still a lot of gaps in the stack. Up until recently, these were the gaps that consumers would have to fill on their own with some open source stool or the other, but now the CloudNative Computing Foundation is the place to go to fill those gaps. He explained how people used to take pride in building their own Linux distros up until a point where they realized it was a waste of time and just switched to RedHat or Ubuntu instead.
That’s where Kubernetes is at the moment and rather than building custom Kubernetes stacks with open source tools, consumers are finding more value in consuming all that as a service so they can focus on the tasks at hand. With regards to the tools in the environment, anything you need or are planning to build has probably already been built by someone at some point and the CNCF is the one stop shop to figuring that out. Chances are that you can stop whatever you’re doing and just download something instead.
Knative and Serverless
Serverless was definitely a big buzzword at the conference and multiple vendors including Red Hat, Google, SAP, and IBM announced that they are coming together to support the open-source Knative project. The fact that IBM is doing so in spite of its own OpenWhisk project is a perfect example of where the enterprise is today and how seemingly competitive tools serve to support and even complement each other. Often referred to as Functions as Service, serverless enables organizations to execute functions called by triggers hence removing the need to first provision a long-running persistent server.
The Knative project is basically an open source serverless platform that provides a common foundation for everyone who wants to go serverless. It does this by enabling developers to build, serve and manage container-based serverless applications that can be easily moved between cloud providers. Knative is still incomplete, however, and doesn’t interact with Azure functions or AWS Lambda functions, there are also “improvements” still needed to fully enable an open ecosystem for serverless. While it may not be what Kelsey Hightower calls the gold standard in serverless technology aka AWS Lambda, several of Knative’s primary developers announced that they have implemented it in their cloud-native solutions nonetheless.
What developers now want is a way to build functions-based systems that have the flexibility to move around between clouds or on-prem, hence the buzz around hybrid or multicloud. A major unique selling proposition for Kubernetes is you can use it anywhere and the big question to be answered is whether Kubernetes really multicloud capable? Can you take Kubernetes from Azure over to AWS and still retain the same controls and configurations? The answer lies in the layers, and while the first few layers that involve moving containers and their logs, securing access and load balancing are now pretty standard, stuff like CI/CD, which is the next layer is still not standard. This is because all clouds at the moment have different Identity and Access Management Solutions (IAM) in addition to security and networking features that are not the same.
Keeping on-premises and cloud environments as similar as possible can spare IT teams painful learning curves. Quite a few serverless platforms were on display at the conference, one of which is the Cisco Container Platform that’s on-premise but looks identical to what you find in the Kubernetes environments at AWS or at Google. IBM’s Multicloud Manager is another great option for the hybrid cloud users as it allows customers to manage and move their Kubernetes clusters across different clouds and datacenters using a single dashboard. Additionally, Arista has integrated the containerized version of its network operating system with Red Hat and Tigera software to support containers running on public, private and hybrid clouds.
Containers and VMs
Now while containers themselves are going to be pretty standard for a long time, the way we perceive and package them is changing. Going into 2019, it’s going to be the cloud providers that find value in providing container orchestration or Kubernetes as a service which includes running it, patching it and upgrading it. Consumers who have been running Kubernetes on their own are now realizing Kubernetes is just the beginning and a medium to facilitate other parts on top like Knative or CI/CD tools, hence finding value in consuming it as a service.
While the initial trend with containers was to build them on Docker, it wasn’t long before consumers began to realize there was a significant security trade-off. Since VMs were already known to be secure, a lot of people were using them for containers. Now having a VM for each container might sound like a huge waste of resources but those were traditional VMs and the new ones are optimized for containers and load in milliseconds. One of them mentioned at the conference was FireCracker, which lets you launch lightweight micro-virtual machines (microVMs) and implements a virtual machine monitor (VMM) that uses the Linux kernel-based virtual machine (KVM).
The fabled ‘end-game’
Moving into 2019, the container environment is maturing to a point where the most crucial task is figuring out what you can consume as a service and what you need to build yourself. In a neat demonstration during his keynote at KubeCon, Hightower first ran a simple function in Kubernetes and then extracted the binaries to run them on Lambda, stressing that rewriting code should never be necessary. He also jokes about how anyone with an important task at hand has to first learn Docker and then Kubernetes and then a bunch of other stuff before they can do anything, so the future needs to be about putting a hood on all that stuff and calling it infrastructure.
Figuring out what you’re not doing right and finding someone who can do it better seems like an easy enough game to play, but unfortunately, it wasn’t always so simple as there wasn’t as much clarity as there is today. With the CNCF bringing standards to the different layers of the stack, it’s a lot easier to see exactly where you fit in. Bottom line: 2019 is going to be all about finding your vendors and not wasting time on anything except the end game.
Photo credits: Flickr / CloudNative Computing Foundation