 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Exceptional time and effort has been spent discussing how cloud technologies changed the traditional software development experience. In the past 20 years, we’ve moved incrementally through a number of different technologies and ways of shipping software. With cloud native development, though, we’re witnessing a sea change, which has fundamentally altered the developer experience. The resulting waves also rocked the worlds of site reliability engineers (SREs), platform architects and teams, and even tech leaders.
Previous articles have looked at these transformations, converging on a few themes: A “shift left” is afoot, Kubernetes has become the default orchestration system and the cloud native ecosystem is robust and healthy. The challenge now is wading through the overwhelming number of tools to reach a platform-as-a-service (PaaS) approach that supports the new cloud native normal. The Cloud Native Computing Foundation (CNCF) has emerged to lead the charge in building sustainable ecosystems for cloud native software, and is the natural springboard for platforms that include the critical components of the global technology infrastructure.
In the early days of modern software development (mid-2000s), developers had a lot to learn, but ultimately worked with a single monolithic codebase with a well-established development process. They wrote code and handed it off without really knowing, or needing to know, what happened from there. Later, this evolved into a straightforward PaaS phase where dashboards became common, and technologies like modern source control (git) and application performance monitoring (New Relic) were dominant. Jump to 2015 or so, and we’re in the microservices era, and developers are beginning to be involved in the full life cycle. With the addition of tools like Docker, Jenkins, Terraform, Chef and various plugins, the cognitive load became increasingly heavy. Fast forward to today, the cognitive load has increased even further.
In these 20 years of my development career, several key takeaways emerged, which I explored in a recent DevX Days presentation at KubeCon North America: “From Kubernetes to PaaS to Developer Control Planes.” I’ll summarize these here:
The monolith offered a lighter cognitive load and the supporting PaaS solutions that spring up, such as Heroku for Ruby on Rails apps, enabled developer productivity. We are on the precipice of a similar shift, where developer productivity and experience could be augmented by introducing a platform as product, that is, centralizing the user experience/user interface (UX/UI) and standardizing opinionated ways of doing things in a decentralized way, to paraphrase Dave Sudia, CTO of Upchieve.
What could this look like? In large part, this depends on the organization. A potentially telling question to ask instead is: How, and what kind of platform should be offered? Investment in platforms provides structure for being able to work fast, in small cycles, releasing in iterations and so on, but what does that mean in terms of a developer’s daily work?
Building a platform requires understanding how users undertake their daily tasks (using *your* tooling), meaning that user research into how developers work, and how they will work specifically with the platform, is essential.
Taken from the perspective of “mechanical sympathy,” a term attributed to Martin Thompson, that is, the better a developer understands how things run, the better they will be at coding. If taken from the “empathetic engineering” perspective, however, you use your own product to understand what it is like for an end user. If they can’t accomplish their goal, then the software needs to change or your platform needs to build in awareness of the developer experience.
Understanding how to offer platforms is another key. What kind of platform, and how “centralized” should it be? What is the maturity level of the organization and its developers? For example, some organizations like Netflix are at the vanguard, empowering full life cycle developers. Not many organizations are at that stage, but a platform for reducing friction and enabling productivity will move you further along the path to maturity. Offering a self-service platform that developers can easily access to get solutions for themselves — SDKs, APIs, a UI to get their work done — all without having to raise a ticket or ask questions in Slack, will pave a smooth path toward greater developer autonomy and responsibility.
“It’s not just Kubernetes now — that’s just the common framework. It’s all the other stuff that’s the hard part now: linking everything together and making it work.” — Kasper Nissen, lead platform architect, Lunar Bank
The move toward a Kubernetes-based, developer-friendly PaaS, and standardizing the experience, does not mean removing freedom to choose and use tools developers or the wider team prefer. Instead, it delivers an opinionated or “paved” path, helping developers get up to speed and code faster, reducing the cognitive load. In production environments, platform adoption provides a set of useful abstractions and creates conditions for two important signs of maturation:
As workflows and interoperable tooling converge around standards, and as the developer experience has evolved to include awareness of the full software life cycle, the idea of a developer control plane (DCP) becomes almost tacit. Regardless of whether the developer is required to shepherd the code through ship and run phases, the DCP provides the common platform to manage code, the dev environment, source control, CI/CD, manifest and container management, API management, Kubernetes runtime and observability.
A DCP can be the “single pane of glass” into the platform without fully needing to centralize it, giving the developer the freedom to customize their view and deploy from there, using the DCP as a jumping-off point. Ambassador Labs’ SVP of Engineering Bjorn Freeman-Benson explains, “A developer control plane enhances your existing technology stack and enables collaboration among your development teams without requiring devs to worry about managing configuration.”
We have reached a point of consensus that we need a common platform for coding, shipping and running software in the cloud native space. The developer control plane delivers on this idea, providing a centralized place to rally around shared standards and identify common workflows, and also encouraging tech integration/interoperability, which ultimately can drive the next phase of cloud native maturity.
