Kubernetes Pains? Platform Engineering Can Help
Let’s paint a picture of developers in the modern cloud native setup: The tooling landscape is rapidly growing, both in terms of volume and complexity. Organizations’ engineering setups often demand that developers have an end-to-end understanding of not only Kubernetes, but infrastructure provisioning, deployment pipelines and configuration management as well. In the past 10 years, developers have become responsible for an increasing portion of the software delivery process.
All of these shifts have created cognitive load for developers. And, as many developers are now sharing on Twitter, Reddit and at conferences, this cognitive load is interfering with their ability to execute their most important task: shipping features.
Inspired by Daniel Bryant at PlatformCon 2022
Kubernetes is one brick in this wall of complexity for developers. As such, in this article, we’ll address specific problems organizations encounter with Kubernetes and how they fit into the larger problems with DevOps adoptions that platform engineering aims to solve.
Mismanaged Expectations
A lot of Kubernetes pains are a result of mismanaged expectations. Some organizations expect Kubernetes to be easy to use and maintain, that it will save the organization money and that it is cloud vendor agnostic. What they fail to realize is that, to realize the potential benefits, they still need the prerequisite functional systems and security expertise previously held by multiple people with multiple career paths.
Without strong configuration management, appropriate documentation and a mature integration with CI/CD systems, implementing Kubernetes (or any other technology) becomes very difficult. You have to get the technical implementation details right the first time.
Platform engineering is not a magic wand that will make this fundamental requirement go away. However, the product approach required to build your platform might help illuminate areas where your organization isn’t quite ready to support Kubernetes.
If you haven’t yet adopted Kubernetes, conducting user research and establishing a strong feedback loop might also help set more realistic expectations for what Kubernetes will do for your organization.
Lack of Developer Confidence
In some DevOps setups, developers lack the confidence to get their hands dirty. They fear breaking things every time they touch the Kubernetes-related parts of their delivery setup.
But you need to achieve true self-service for a Kubernetes setup if you don’t want to slow down. Developer self-service means that engineers can self-provision and consume the technology that they need to test, secure and deploy their apps and services without having to wait on Ops to provision resources or spin environments for them. It does not necessarily mean that developers need to master their entire toolchain.
Internal developer platforms provide levels of abstraction that reduce the level of Kubernetes expertise developers need to have to get the job done. Similarly, enabling developer self-service does not mean that any developer should be able to influence production infrastructure. In fact, well-designed platforms allow developers to spend less time fiddling around with infrastructure and more time shipping features.
When it comes to repetitive tasks like spinning up new features or preview environments, enabling developer self-service is essential in saving teams time and resources. Without it, organizations risk creating more bottlenecks and key person dependencies, which slows down their lead time, deployment frequency and time to market for new features and innovation cycles.
In Humanitec’s 2022 Kubernetes Benchmarking Study, we found that teams with strong performance across DORA metrics also enabled developer self-service. In 73.4% of these teams, developers can self-serve Kubernetes namespaces for feature and preview environments.
New Namespaces for Feature or Preview Environments
Furthermore, developers are able to deploy to dev or staging independently and on demand in 89.1% of high-performing teams. This is true for only 32.9% of low-performing organizations. Furthermore, nearly a third of low performers reported that, even though everyone at their organization can deploy to their Kubernetes clusters in theory, a fear of making a mistake prevents many people from following through.
In these setups, lead time increases and deployment frequency decreases. These teams need to be able to deploy with confidence. Internal developer platforms can provide the support developers need to feel more confident when interacting with Kubernetes (and guardrails that make Ops feel more confident also).
One Size Does Not Fit All
The rise of platform engineering reflects a degree of brokenness in the relationship between dev and Ops, a brokenness caused by organizations copying and pasting a one-size-fits-all approach to DevOps into their organization. In DevOps Topologies, Matthew Skelton and Manuel Pais outline a handful of antipatterns many organizations fall into when trying to implement DevOps.
One antipattern arises when organizations decide that they don’t need dedicated Ops roles anymore. They inadvertently pass on these tasks to experienced developers. This misallocates some of the organization’s most valuable resources and creates more of the inefficiencies DevOps was introduced to solve. Humanitec’s 2021 DevOps Benchmarking Study found that in 44.9% of cases, senior developers take over the role of operations to help less-experienced developers.
This so-called “shadow operations” model creates all sorts of inefficiencies. Evidently, many organizations are struggling to implement DevOps principles in a way that’s compatible with their teams and existing resources.
Platform engineering avoids this pitfall by taking a product approach. For internal developer platforms, developers are the customer. Platform teams gain a holistic understanding of their developers’ needs by conducting user research and soliciting regular feedback. This line of communication is how platform teams decide which features to build first and which aspects of the platform they need to iterate on.
A product approach also requires understanding different stakeholder groups and marketing the platform to them. This ensures that the platform doesn’t fail from lack of adoption or support from executives. Done correctly, a product approach should reveal where developers are struggling with Kubernetes and what kinds of abstractions they need to succeed.
Internal developer platforms might also ease some of the tension between dev and Ops when it comes to Kubernetes. The platform replaces a lot, though not necessarily all, of the ad-hoc work that a DevOps engineer does. Those people have the opportunity to transition into a platform engineering role and translate their expertise into a better developer experience across the organization.
Developers can spend more time coding and less time fiddling around with infrastructure and other Ops tasks. Ops can move upstream to more critical tasks like managing networking or physical hardware. Alternatively, they can also become platform engineers. Overall, internal developer platforms enable dev and Ops to focus on the core responsibilities and strengths of their jobs. and DevOps engineers to have a broader effect across the organization.
Conclusion
When it comes to Kubernetes growing pains, platform engineering isn’t a silver bullet. However, platform engineering has embedded in it practices and approaches that can help organizations avoid or mitigate the challenges that often arise.
Want to dive deeper into platform engineering? Download the 2022 State of Platform Engineering Report to learn more.
