‘Complex,’ we use that word a lot in the Kubernetes (K8s) and cloud-native world. Over the last 20 years, developers have seen a tsunami of new technologies, languages, services, open-source products, and libraries. While this progression has handed unparalleled power to a single developer and what they can achieve, it’s come with a price: cognitive overload.

Developers were not only given technologies, along with tools, integrations, and APIs, but were often tasked with understanding how many of the components worked. While DevOps and its principle of shared responsibility enabled devs and engineers to release better quality products faster and automate many repetitive tasks, it has also meant the developer team experience has frequently involved a fair share of configuring, packaging, and deploying most aspects of their containerized apps on Kubernetes and other platforms themselves.

The concept of developer experience (DX or DevEx) is about enabling developers to achieve their best work.

The study of DX includes many factors that impact the effectiveness of software development, including systems, technology, process, and culture. It considers all aspects of a developer's ecosystem, from their work environment to their workflows and tools.

(Developer Productivity + Developer Impact + Developer Satisfaction) c = DX

Recognize this formula? Yes, that’s GitHub’s attempt at creating a formula for developer experience.

Developer Productivity defines how quickly and effectively a change can be made to code, while Developer Impact is how effortlessly a dev can move from an idea to putting that idea into production. Developer Satisfaction focuses on the dev’s happiness and how that’s affected by their environment, workflows, and tools.

The goals of DevOps include streamlining and automating software development and achieving better communication and collaboration between Dev and Ops, which, along with other goals, were designed to create faster delivery, reduce errors, and create better quality software. Ironically, that’s enabled developers to stand up Kubernetes quickly with a few commands, which has increased Developer Impact. However, that hasn’t always meant a quality developer experience with K8s or as much of a bump in Developer Satisfaction.

Floundering: Developer Experience Rethink

While K8s has become the most popular platform for orchestrating thousands of containerized apps and automating their deployment, scaling, and management, it is a declarative system. This intended design feature of K8s means that it doesn't make decisions about how apps are configured or how they communicate or interact with other services without being told first. That’s why developers dream of YAML files (not electric sheep) and being crushed by the weight of all the YAML files they must create or amend.

To twist a famous Star Trek line to suit our needs, devs started to feel like Dr. McCoy, wailing, “Dammit, Jim; I’m a developer, not a plumber.” Something wasn’t quite right with the Kubernetes developer experience as devs spent too much time dealing with infrastructure rather than focusing on features and products.

Additionally, with the security ‘shifting left,’ the US administration’s focus on securing the supply chain, and general K8s security concerns, developers have also found themselves wearing the security hat for all the frequent app deployments they can now do and the accompanying stress that comes with that responsibility. VMWare’s latest State of Kubernetes 2023 report illustrates this point and finds that meeting security and compliance requirements in deployments (as well as operations) has become the second challenge (with worries over misconfigurations being the top challenge).

This recognition that things are not quite right with Kubernetes for developers and cloud-native generally is why we are seeing an increasing interest among enterprise organizations to probe the merits of DevOps thoughtfully and try to carve a more effective developer experience with Kubernetes and cloud-native technologies.

So DevOps is dead then? Before you get your pitchforks out and chase us down for clickbait, we are not suggesting the death of DevOps but that it needed to evolve.

We’ve been through several phases with DevOps, from ‘pick ‘n’ mix,’ where teams chose their own tools, to curating a list of the best-in-breed tools every team used. This standardization for each SDLC stage made it difficult to move changes between tools at each stage, which led to custom solutions for ‘filling the gaps’ that distracted engineers from their core work to deal with maintenance.

That’s why it wasn’t surprising to see Platform Engineering hit the Gartner hypecycle last year, accelerating upwards at a fair rate of knots as a new Innovation Trend.

Fits the Bill: What is Platform Engineering?

Platform engineering revolves around a dedicated platform team that implements and maintains an organization’s chosen engineering platform. Garner anticipates that by 2026, 80% of software engineering organizations will have platform teams maintaining and operating “reusable services, components, and tools for application delivery.”

The rise in platform engineering makes sense, as how you build your platform drives your developer experience.

Platform Engineering hasn’t meant a departure from DevOps back to Dev and Ops silos. Instead, it’s a move towards easy-to-use tools and resources for devs, creating platforms-as-products supported by dedicated teams that supply fundamental building blocks. This approach removes the need for devs to look downward and deal with infrastructure. Instead, it seeks to improve the developer experience so devs can look up and focus on delivering better business outcomes.

When developing a Platform Engineering strategy to achieve a better developer experience, there are three stages to consider:

• Standardization
• Automation
• Simplification

Standardizing across environments, including tooling, configuration, patterns, etc., will enable your platform team to connect the different components of your toolchain for developers. This improves the developer experience and self-service capabilities for the organization. Automation allows repeatable processes, removes configuration drift, and enforces compliance policies, opening the way to simplification. Simplification leads to greater agility and enables a unified approach to solutions and other benefits, such as ease of uptake and upskilling–driving digital transformation, productivity, and, ultimately, profit.

Overhauling: Benefiting from Self-Service

Commonly, the first big project is an Internal Developer Portal (sometimes called an IDP, just to confuse anyone familiar with IdP, a common acronym for Identity Provider) that enhances the developer experience by offering easy access to the tools, resources, and documentation needed to build and deploy applications.

An IDP aims to provide a consistent, compliant, scalable, secure, and unified set of technical foundations, which includes guardrails, patterns, tooling, and associated processes (such as ownership and accountability). Essentially, it provides all the capabilities to support the end-to-end SDLC for an entire organization.

IDPs are often conflated with self-service portals, which are part of an IDP. A self-service portal acts as a web-based ‘vending machine for devs’, dispensing API keys and credentials, provisioning environments, monitoring and logging data, useful knowledge articles, and support tickets on request. The difference is that an IDP will include many more components, such as CI/CD pipelines for better tracking, management of drift and rollbacks, functions for onboarding and training new developers, company forums, etc.

The components included in an IDP tend to vary, but organizations using Kubernetes and containerized apps commonly include:

• Container Registry This is used for storing and managing container images, such as Docker Hub, or a registry from one of the main cloud providers.
• GitOps pipelines Many IDPs apply the GitOps approach to their CI/CD pipelines, using tools like ArgoCD and Git repositories as a way to automate deployments and ensure the desired state of the app or infrastructure is synced correctly with the actual state.
• Kubernetes dashboards For that ‘single pane of glass’ everyone seeks for visibility and management, an IDP often uses a web-based user interface for monitoring and troubleshooting Kubernetes clusters; a popular choice is Kubeapps.
• API / App Gateway & Integrated Storage Providing a single point of entry for API and app calls, a gateway can be used to establish authentication and authorization policies and firewall rules. It also acts as a load-balancer to create a more performant portal that distributes traffic efficiently and provides integrated storage that's secure and reliable.

As you might expect, an IDP–and its self-service portal sub-component–are beneficial not only for organizations that have gone cloud-native but also for ongoing digital transformations and development processes.

Getting Underway: Thinking Holistically

Driving forward a better Kubernetes developer experience isn’t simply about building platforms. It also shouldn’t be solely judged by cold, hard metrics. DORA is excellent for assessing important metrics, such as deployment frequency and mean time to recovery improvements, but they can be gamed and won’t offer a complete view into developer productivity.

Wedging in at least one nautical analogy into our blog, if you don’t teach a new crew member the ropes and set them alongside expert sea hands to gain expertise and soak in the culture, then you’re not creating the right environment for learning and personal development needed to run a ship efficiently or properly.

The ‘C’ in the more holistic SPACE framework highlights the importance of communication and collaboration, so you will want to consider how best to provide concise documentation and provision communications channels where developers can ask questions and get help from other developers and engineers.

You will also want to supply access to a support team to help with incident response, change management, and root cause analysis. Generally recommend a 20% staffing overhead for third-party, subject-matter experts on a team as this enables your engineers to fully dedicate themselves to strategic initiatives that make a significant impact on your organization's growth.

You can also nurture a culture of learning and development by offering training and workshops, access to online resources and tutorials, and encouraging developers to attend conferences and meetups for K8s and cloud-native technologies, such as SpringOne and KubeCon + CloudNativeCon.

Windfall: The Benefits of a Better Kubernetes Developer Experience

DevOps, which is rapidly evolving into Platform Engineering, hasn’t always reduced the friction for devs at enterprise organizations, but by having a well-supported platform team and standardizing and automating manual processes, a developer can have fewer nightmares about YAML and become more productive.

K8s and other cloud-native technologies have always promised to abstract the complexity away for developers, and Internal Developer Portals and self-service portals make it much easier for developers to start new projects and ignore the infrastructure. When combined with improved collaboration, platform engineering can help make developers more efficient, effective, and, dare we say, happier.

Contact Us

Improve your Kubernetes developer experience. Connect with us today to discover how we can support and partner with your platform teams.

CONNECT WITH US