Kubeconf 2018: The Overview
I attended KubeConf 2018 in Seattle a week ago. I’ve decided to distill the core concepts that I think are important from the conference into this blog post.
I can categorize what the conference was trying to push into 5 concepts:
- Observability is King
- Do 1 Thing Well
- Choose Tools Appropriately
- Everyone Needs to know Cloud Ops
- Be Cloud Provider Agnostic
These aren’t new ideas but they were so prominent and spoken about in so many ways that they seemed novel and obvious.
Observability is King
observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.
Observability was pushed so much at Kubeconf and was the star of the show. It seemed that all the major tools and new features in Kubernetes were all about increasing visibility into the systems that you run and the systems that you rely on.
Envoy and Istio are chosen not only for performance reasons but because people needed a way to observe the network they rely on.
Working in the cloud, you quickly realise that not every scenario and failure can be tested for. It’s a much better idea to observe what is going on in production and when the alert when things fail.
Prometheus has now been used extensively in production and has been rolled out in many, many different ways across people’s systems. It along with Jaegar seem to be where the industry is moving and consolidating around.
Even Kubernetes has increased its metric output as it realised that it was required to better maintain the cluster.
Do 1 Thing Well
In an architecture, doing 1 thing well means making sure that each individual part of the system does 1 thing, and has a clear boundary around that 1 thing. This clear boundary means that things become easier to debug, easier to reason about, and easier to compose into something larger.
In the tooling space, pick the tool that is easiest to compose with other tools and that only does 1 thing. This allows you to fully leverage it and compose it into your system.
In business, doing 1 thing well is about focusing on what is core to your business and outsourcing what isn’t. Making sure to do 1 thing well, allows you to be agile enough to change and compose what you provide as necessary and gives focus to the product.
Being able to seperate out each part into the 1 thing it does also allows for a better idea of how that thing is being used. This means, that backwards compatibility becomes easier to manage and reliability then increases 10 fold.
Choose Tools Appropriately
Everyone loves tools. Everyone has too many tools. Consolidate into what is necessary, and discard what isn’t.
Choosing the right tools is incredibily important and they should be chosen with care. An acronym that was mentioned was:
AEIOU:
- Applicable: does this tool solve the issue at hand?
- Enterprise Readiness: Is this tool ready for scale?
- Integrate: Can this tool be easily integrated into the platform?
- Overhead: How much maintainance does this tool require?
- Useful: Is this tool actually useful?
Using this acroynm helps to better evaluate if a tool is right for the job or whether doing something in house is needed.
Everyone needs to know Cloud Ops
To really embrace the cloud, you need a large amount of knowledge in using the cloud. It’s synonomous with relearning how to run a server except now its much more complicated.
Being able to get everyone trained up to understand how things run in the cloud (or on Kubernetes) means that it’s easier for them to reason about how the system interacts. Developers and others need to know how to run and debug their code in any environment.
The good thing is that now that Kubernetes is becoming the defactor standard, its becoming much more valuable to learn how things run on Kubernetes and the learnings are much more standardised and universal than ever before.
Be Cloud Provider Agnostic
Kubernetes is a great platform for shipping code anywhere. Your servers, your customer’s servers, or someone else’s. This also means that writing your code to be cloud agnostic is vital.
If you want to truly be able to deploy anywhere, you need to minimise your dependencies on anything that isn’t installable on kubernetes.
There were a few case studies about how a multitude of products were shipped on their customer’s servers through the use of kubernetes.
Hopefully, these concepts will bring the same amount of inspiration that KubeConf has done for me!