Starting an internal Kubernetes offering

Kubernetes has become the de facto standard in the containerized and cloud-native world. Development teams can leverage various useful abstractions that enable them to build highly scalable and resilient services. Despite all the charm and popularity of Kubernetes, it remains a very complex platform. Operating and maintaining it requires a highly skilled and specialized team. In this article I would like to share how we tackled the problem of building an internal Kubernetes offering to help our development teams getting most out of Kubernetes.

In the following sections we will uncover some of the developer pain points and problems on an organizational level when there is no centrally managed Kubernetes platform available. From there, we will apply a customer-centric product thinking approach in order to identify the most important requirements for a compelling product, emphasizing best developer experience. Based on those requirements we will derive a high-level platform design and the key features of a successful Kubernetes offering.

Motivation

Assuming there is no centrally managed Kubernetes offering available in our organization, development teams will be responsible to stand up and run their own clusters. To get started quickly and reduce the maintenance overhead, those will typically be managed services (GKE, AKS, …) with a lot of additional time and effort required from each development team.