Can Great DX Enable Full-Cycle Development?
Lately, there’s been a shift toward developers owning the entire software life cycle. This is enabled by DevOps tools that help implement things like GitOps, metrics, networking and security features, and much more. Empowering developers with more life cycle ownership could bring greater agility. But, how much delegation is too much?
Software developers are now flooded with a sea of tools to manage. These utilities grant unparalleled power, but maintaining a growing amalgamation of tools could quickly become tricky without quality developer experience (DX). DX is similar to user experience, but instead, considers ways to improve the developer’s workflow and maintain their sanity. Just like SaaS products seek to enhance their DX, internal DevOps setups could use a developer experience upgrade, as well.
I recently met with Richard Li, founder and CEO, Ambassador Labs, to investigate the issues surrounding changing development expectations. To Li, empowering full life cycle developers boils down to improving overall DX through education, dedicated DX teams and a unified developer control plane. According to Li, with rising Kubernetes adoption, now could be an opportune moment to use Kubernetes to help control tools in the surrounding cloud-native ecosystem.
Multi-Tool Fatigue
“Over the past few years we’ve noticed a greater and greater shift toward developers owning the entire life cycle,” says Li. In this mode of operations, the “developer is responsible for writing code and shipping software, as well.”
Netflix calls this ‘Full Cycle Developers‘. The Netflix Technology Blog defines full cycle developers as:
“…a model where a development team, equipped with amazing developer productivity tools, is responsible for the full software life cycle: design, development, test, deploy, operate, and support.”
Equipped with powerful tools, full-cycle developers would oversee a single component or application from design to deployment. This could bring increased agility and accountability to software teams. However, managing this pipeline and keeping it up-to-date with new infrastructure could get tiresome.
Mo’ Tools, Mo’ Problems
Some of Li’s favorite Cloud-Native Computing Foundation (CNCF) tools include Telepresence for local microservices development, Buildpacks to bootstrap your service in a language and Prometheus for observability. There’s also Argo and Flux for release and implementing GitOps. Li describes integrating Argo or Flux with an existing CI/CD system as the “future of continuous delivery.”
He also foresees further evolution in the service mesh space, noting there’s “a lot of opportunity for Celium.” He’s closely following a new cohort of technologies providing service mesh-esque abilities at the Linux kernel level.
As you can see, there is a lot of exciting cloud-native tooling momentum. Yet, managing this swelling portfolio can become a burden. As further evidence, Li points to the CNCF landscape chart; it outlines 930 cards at the time of writing and continues to expand.
Making Full-Cycle Ownership Successful
So, how can developers effectively navigate this onslaught of tools? How can organizations make a full-service ownership model work? Surely, there is a tipping point — either organizations must invest in additional personnel or build self-service capabilities.
“I’ve definitely seen some organizations trying to shift to the full-cycle model, fail and shift back,” says Li. At organizations where the model is successful, Li notices leaders are “not just giving developers tools, they give them control planes or management layers for all these tools.”
Li shares three ways to make a full-cycle developer model successful:
1. Invest In Education
Li first suggests training developers. Every organization has its own standard operating procedures for releasing software. But if this process is not readily documented and accessible, the DevOps experience suffers.
“Realize this is an ongoing thing,” Li explains. Teams will require ongoing training around how you actually ship or update successfully into production. This could encompass continuous integration, using Argo, for example, or defining concepts like canary deploys, he describes. Training on company best practices is crucial to support achieving goals and avoiding breaking clients with new versions.
2. Have a Dedicated DX Team
Next, to enable this training, Li recommends assembling an internal team dedicated to developer experience. This group would act as expert consultants for other teams, providing deployment advice and disseminating company best practices.
A DX team would be in charge of evaluating technologies and helping others adopt tools. For example, they could offer expert context on the surrounding infrastructure to a team building microservices on Kubernetes. In Li’s world, this group would also be responsible for supporting a developer control plane, which brings us to the next point.
3. Use a Developer Control Plane
Lastly, Li suggests teams adopt a developer control plane. This control plane would act as an abstraction layer above tools to unify DevOps control from a central source. “A developer control plane should help developers with actual development, deployment and release and running production,” says Li.
Such a management layer would consist of tooling integration and a user interface. In terms of tools, Li sides with established CNCF projects, as these communities tend to be bigger and have a multiplicative effect. “CNCF tools are great because it’s all about community and governance,” says Li. “You know it’s neutral governance — if there’s an issue, you can actually change it.”
Treat Developer Experience as a Product
“We’ve got to invest in developer experience,” stresses Li. All three strategies above underly the importance of developer experience in navigating full life cycle development. “That’s why it makes sense to allocate a team of engineers to build a control plane,” Li explains. “If you can do those three things well, you’re well on your way.”
Full-cycle development is an intriguing concept. Whereas full-stack development requires mastering multiple programming languages and frameworks, full-cycle stresses mastering many DevOps technologies. But, while many feel DevOps is a culture all IT should embrace, some still believe DevOps is a role delegated to specific Ops folks. This could be a possible roadblock to full-cycle development. As developers take on more control over the entire life cycle, the burden they assume must not increase.
“It’s really important to treat developer experience as a product,” says Li.
Just as a product requires excellent documentation and support, so do DevOps processes like continuous integration, container registry, traffic management, observability and others. If wired together within a single interface, engineers could potentially realize the full-cycle concept. “Bringing that product mindset to DevEx is what is needed to make the organization successful,” says Li.