 |
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.
This is part two of a three-part series. Here is part one.
Cloud native software development, we’ve argued, has forever changed the developer experience.
As the first in this three-part series explored, there is no one single developer experience, especially in the cloud native landscape. Cloud native tools are many, and even as platforms converge around Kubernetes as a kind of standard on which to build, platform differences are inevitable because business goals often drive the way developer platforms are designed. In many cases, as cloud native platforms centralize, so too does the developer experience.
This article is the second in a three-part series that features insights from discussions with cloud native thought leaders. It takes a closer look at the unique paths forward for cloud native technologies across different organizations and examines how each found the right balance for their own developers and organizations. It also discusses how centralizing the developer experience with opinionated but flexible developer platforms supported business goals within the cloud native ecosystem.
Using Kubernetes in the real world has helped a number of organizations “tame” the sprawling cloud native ecosystem to address their business goals and meet their developers’ needs. Widely seen as a general-purpose framework or default orchestration system, Kubernetes, as echoed in a number of our interviews, provides generic tools to build standards and relevant abstractions. Bo Daley, a DevOps platform engineer at Zipcar, explained, “Most of us are not doing general purpose work, so we can use Kubernetes as the framework, and build our abstractions, relevant to our own business problems on top.” Kubernetes offers a stable but flexible foundation on which to build.
At the same time, “paving the path” should not equal handcuffing developers to tight constraints or no choice in their preferred tools. Building on Kubernetes and selecting a recommended “middle ground” or set of best practices translates to developer efficiency but does not lock anyone into specific tools. The interviewees we spoke to echoed this approach, most notably Cheryl Hung, formerly of the CNCF: Use Kubernetes to build and promote a standard platform that is modular enough to enable developer autonomy.
For as much fanfare as Kubernetes garners, it is still, as Kelsey Hightower has pointed out, “a last-mile technology.” Kubernetes alone isn’t going to solve the challenges developers face. Kubernetes provides much-needed infrastructure and better APIs. After all, as Apple’s Cheryl Hung shared in an Ambassador Labs podcast, “infrastructure is hard.” But a developer needs a control plane that lets them trust each step of the process. That is, the developer codes, packages the code and checks that they have the right dependencies to run the code… but how does it get deployed?
There’s a lot of discussion on how much the developer needs to know or do on the deployment side, but most of the experts we spoke to emphasized that in real-world implementation, developers just need to be able to trust that if they supply the code and configuration, the platform will run the application as specified. Essentially, the centralized developer platform should give developers an easy way to express their desire for what they want for the infrastructure, and, as Hightower explained, trust it to “hold state, converge it and keep it true over time. Kubernetes just happens to be what we consider a universal control.”
In practice, Kubernetes has proven to be a solid foundation for real-world deployments. Zipcar’s Daley stated it well, “We are focused on the developer experience and on building developer understanding of how their work interacts with the other components in the system. We want to pave a seamless path to production.” This is where the centralized developer control plane jumps from concept to reality.
In commercial environments, developer platforms and the overall developer experience are driven by what will best support business outcomes. As Katie Gamanji, former CNCF ecosystem advocate, explained in retelling her experience implementing a centralized developer platform at Condé Nast in 2018, “With a very clear business goal and timeline in mind, centralizing a platform and its development drives the need to adopt tools that have already proven to be somewhat standard within the industry, such as Kubernetes. For a business-critical, production implementation of a fairly straightforward media platform, well-accepted standards were needed.”
Introducing a developer control plane can go a long way toward supporting and achieving business goals. As Nicki Watt, CTO/CEO of consultancy OpenCredo, explained, “The expectation is that a certain value will come from the platform an organization is investing in. And the way it is built should be driven by what the ultimate goal is. If it’s about constraining freedom and achieving cost savings, the platform will be built one way, but if the goal is innovation, it will be structured and approached in an entirely different way.”
Ideally, platform design and construction consider the needs of the organization as well as the developer experience. If an organization can foster better developer experiences, it will reap the efficiency benefits. At the same time, with a carefully crafted control plane, standards and sensible workflows, organizations support and respect their developers by providing a solid foundation as a springboard.
As Alan Barr, internal developer and security platform product owner at Veterans United Home Loans, shared, “With the right abstractions, developer cognitive load and ‘toil’ should naturally lighten. The developer experience is, hopefully, usable and useful. Part of this is being careful about the tools and platform itself, and never taking shortcuts on internal tools.” Another part is remembering that developers are humans creating applications for humans, which requires mechanical sympathy and a “hospitality-oriented” focus, ensuring that developers feel that the road ahead of them has no roadblocks and that the developer control plane is something they feel inspired to adopt and use, both to achieve business and individual goals.
