Best of 2022: A Better Kubernetes Experience for Developers is Key in 2022
As we close out 2022, we at Container Journal wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.
As more and more organizations run Kubernetes in production, they’re finding that application developers are having to focus too much on Kubernetes and not enough on their actual applications. This year, I predict that we’ll see a major shift to remove this friction to speed up application release cycles and still get all the benefits of Kubernetes.
Kubernetes Momentum Exposes Developer Friction
According to VMware’s State of Kubernetes 2021 Report, Kubernetes production use has gone up from 59% to 65% between 2020 and 2021. Everyone is getting more experience with Kubernetes, and the ecosystem is developing quickly. In many cases, however, application developers put up with too much extra work because they’re asked to interact with Kubernetes directly. Kubernetes is designed for operations and infrastructure people. It standardizes how cloud infrastructure is described, used and run. In my estimation, Kubernetes has achieved this goal.
But, the Kubernetes experience for application developers is still challenging. While the infrastructure level is simplified, developers are still left to configure just about every aspect of how their applications are packaged, configured, deployed, communicated and run. Let’s look at two examples of this extra work that create developer friction.
The YAML Mutterers
You’ve probably heard people complaining about yaml: “The wall of yaml,” “yaml hell,” and other delightful sayings. Here, what the sardonic mutterers mean is the time developers spend describing and configuring how their applications are deployed, configured and how they interact with other services like networking, storage and other applications. On its own, Kubernetes doesn’t automatically do this or, really, provide any starting templates. Kubernetes doesn’t really know the type of applications it’s running or what those applications need. That’s not its job! So, developers have to define all that plumbing. The flexibility and openness of Kubernetes is beneficial if you’re building a platform, but it becomes overwhelming if all you want to do is build applications.
Shifting Left Security Without Smothering Developers
With all the security problems of the past couple of years, the idea of a secure software supply chain is front and center. Briefly, the concept means that you have much more control of what third-party components are included in your software and have the ability to track down and fix those components when the security breach of the week comes around. When developers are deploying applications weekly (if not daily), you need to automate checking, enforcement and remediation of problems to achieve the level of security control needed. Here, Kubernetes has little to offer because—you guessed it—that’s not its job. Developers are often left to handle security requirements on their own. This is not only a lot of extra work for developers, but is incredibly error-prone because, well, developers are not security experts and tend to prioritize features over security—because the business asks them to.
Apple Pie Without all the Universe Creation
“If you wish to make an apple pie from scratch, you must first invent the universe.” –Carl Sagan
There are many more examples of friction, but you get the idea: Application developers do their best work when they’re focusing on the actual application layer; the features, screens, business logic and workflows in their software. All of this plumbing work is not fun for them and also distracts them from improving how their business functions by adding features to their applications.
After several years of exploring Kubernetes strategies and deploying applications to Kubernetes, we’ve suddenly discovered this developer friction. Now, the urgency to remove this friction is driving the ecosystem to focus on developer experience. I hope that in 2022, we will see increased focus on improving the Kubernetes experience for developers and, in turn, a better developer experience that allows for more innovation, flexibility and increased productivity.
The good news is that we have a long history of solving this problem to guide us.
Reduce Friction with Application-Aware Platforms
My colleagues working on the VMware Tanzu projects have been developing the idea of an application-aware platform. This is based on the developer experience thinking that drives the Spring framework. You can reduce a lot of how Spring works down to providing templates, sensible defaults and automating a lot of the plumbing mentioned above. Java developers who use Spring spend very little time on all of those tasks. This is because Spring is an instance of an application-aware platform.
To make Kubernetes application-aware means to provide a good set of starter templates, sensible defaults, configuration methods and supporting services like CI/CD, security and middleware that developers need to use. Without this kind of boot-strapping, developers are left to start from scratch—insert all the yaml complaints here.
We don’t have to start from scratch to solve this problem, thankfully. The PaaSes we’ve developed over the years, such as Cloud Foundry, have done a lot of this bootstrapping for developers. And, we can use those patterns and best practices to build a developer platform on top of Kubernetes.
I’m also seeing other components pop up in these platforms. For example, support for debugging applications in Kubernetes is incredibly important. There’s a large focus on developer portals. As boring as this name sounds (please email me if you come up with something better), developer portals centralize everything developers need to know about their applications: How it’s running in production, how it’s complying with security and governance needs and reusing other applications and services in their organization.
I’m excited to see how these application-aware platforms evolve this year. I’m hoping that they get application developers focused back on their software by removing the need for developers to spend so much time working with Kubernetes directly. To reuse an old phrase, “Good job typing all that yaml this year,” said no CIO ever in your annual review.
The Future of Kubernetes
Kubernetes is here to stay. As the ecosystem continues to expand and more organizations adopt the technology, organizations will discover the need for an application-aware platform. This will make all the difference in the developer experience by allowing for quicker code deployment and also building an automated, effective DevSecOps workflow.
Combined with this platform, Kubernetes will really shine. And this was the point of Kubernetes all along: To be a platform for building your application developer platform, or, “developer experience,” if you’re into the whole poetic phrasing thing.