I recently had the opportunity to attend Kubecon / CloudNativeCon in Seattle. This was the 3rd annual North American conference put on by the Cloud Native Computing Foundation (CNCF) and they did an incredible job.
If you are unfamiliar with the term ‘cloud native’ check out the formal definition. In short, the CNCF is committed to fostering open source cloud technologies that allow users to avoid vendor lock-in. I had a great time at the conference and Seattle’s Washington State Convention Center was an amazing venue.
Kubernetes has exploded in popularity since its inception in 2015 and has undoubtedly come out on top in the container orchestration war. Kubecon topped 8,000 attendees this year, up from ~200 for the first conference in 2015. Over half of all Fortune 100 companies are using Kubernetes in some capacity with more adopting it everyday. Companies like Chik-fil-a are finding creative ways to run kubernetes at the edge by running a cluster in every one of their stores nationwide. All of the big 3 cloud providers (AWS, Azure, GCP) are offering managed kubernetes clusters. In addition there are many other providers trying to get a slice of the growing pie such as IBM, Redhat, Mirantis, and many more. Here is a list from earlier this year. Thankfully, I was able to haul in a substantial amount of vendor swag, including 10+ t-shirts, a hoodie, water bottles, and hundreds of the o so coveted laptop stickers.
Google donated Kubernetes to the CNCF in 2015 shortly after Kubernetes reached its 1.0 release. Since that time the community and ecosystem has exploded. Kubernetes has lead to the birth of over 20 open source CNCF projects including Prometheus (a monitoring service), Envoy (an open source proxy donated by Lyft), and Istio (a service mesh built on top of Envoy).
Impressions
Now that we’ve gotten some history I’d like to dive a little deeper into my top impressions from the conference.
1. Kubernetes is not for developers
This point was a theme of the conference and changed my perspective quite a bit on how I look at Kubernetes moving forward. While Kubernetes is a very stable project, there is a huge learning curve to managing a cluster and deploying applications to it. And if you aren’t familiar with Docker and containerization that learning curve just got even bigger. Application developers generally do not like writing undifferentiated code. That is, code that they do not feel directly contributes to completing business objectives or feature objectives. This is the job of the platform engineer and all platform engineers should be striving to make the app deployment process as streamlined as possible for application developers. This means doing things like wrapping kubectl so app developers don’t have to remember so many commands and making the kubernetes dashboard easily accessible. It also involves limiting the options available to deploy an application to Kubernetes, or better yet having a template project that has building and deploying built in so app devs don’t even have to think about deployment. There were several great talks I would recommend checking out that discuss this in more detail. My favorite was a Keynote delivered by Melanie Cebula, a software engineer at Airbnb. Check out the talk: Keynote: Developing Kubernetes Services at Airbnb Scale.
Additional talks:
Kubernetes Is Not For Developers and Other Things the Hype Never Told You
Kubernetes is Still Hard for App Developers, Let’s Fix That!
2. Service Meshes are the New Hotness
If you’re like me you had heard the term service mesh before but didn’t completely grasp the concept. Service Meshes were a big topic at Kubecon this year due to a large amount of interest and some high velocity open source projects like Istio. I learned that service meshes are a way to obtain reliable communication of ‘east-west’ traffic within your microservices architecture because, as we all know, the network is not reliable. ‘East-west’ meaning communication between microservices, in contrast to ‘north-south’ traffic that would be communication into and out of your service layer from elsewhere. A service mesh has multiple use cases but it’s more notable features are related to reliability, observability, and security. A service mesh abstracts these 3 tasks away from application developers and makes them a feature of the platform. A service mesh will retry failed requests between services, observe traffic for abnormal latency, and enforce security rules. This frees the application developer up to focus on their business logic instead of worrying about timeouts and retry loops in their code base. Istio and Linkerd are some of the more popular open source projects available while vendors have also gotten into this space with offerings like AWS App Mesh and Azure Service Fabric Mesh. Great talks from the conference on Istio and Service Meshes in general can be found here:
Istio - The Packet’s-Eye View
Keynote: Kubernetes, Istio, Knative: The New Open Cloud Stack
Service Meshes: The Production Readiness Checklist for the Rest of Us
3. Kubernetes has Exploded
I touched on this briefly earlier but I’d like to reiterate just how much adoption Kubernetes has gotten over the last 3 years. I talked to many developers across many industries from healthcare, to defense contracts, to oil drilling, to fast food chains. Kubernetes has seen wide adoption as a platform for running containerized workloads and avoiding the dreaded vendor lock-in. The cloud native philosophy resonates with businesses around the world as there is a ton of value in being able to pick up and move your infrastructure in the case of rising prices, poor customer service, or poor performance. There is also value in being multi-cloud in the case of vendor or datacenter downtime when your business cannot afford downtime. There were several really awesome case study talks given from businesses that have recently invested in these technologies. My favorite was the Weave & Chick-fil-A: Managing Fleets of Kubernetes Clusters talk but I encourage you to check out all of them.
Thanks for reading! I highly encourage anyone interested in Kubernetes or other Cloud Native technologies to attend this conference next year. I recommend familiarizing yourself with Kubernetes and other Cloud Native projects before you go though, as the amount of beginner material available was somewhat limited. If you can’t make it out for a conference you can check out all the talks from this years conference for free on YouTube here. If you are interested in hearing more about the conference or just want to chat about cloud native architecture, dev-ops, CI/CD pipelines, etc., please feel free to reach out on LinkedIn. Finally, a new Cincinnati Cloud Native group is starting on MeetUp. I plan on checking it out and I hope to see you there!
