Developer Control Planes: A (Google) Developer's Point of View

Startup companies in the cloud-native space continue experimenting at varying levels of maturity with the "you build it, you own it" idea. For developers coming from larger-scale environments in which they don't need to think about platform and operations considerations, there are lessons to be learned from the upsides and downsides of full code-ship-run developer ownership.

Notable themes emerged during the conversation:

• The pure developer - upsides and downsides: While many developers just want to code and not worry about the challenges of infrastructure -- and companies like Google make the developer experience seamless and easy -- there is a twofold tradeoff. First, the developer never needs to learn how it works under the hood, which isn't helpful if a developer goes to work in a company that insists on developer ownership and autonomy. Secondly, the Google-like experience, while convenient, shields the developer from understanding of the complexity of shipping and running their code.  This can be positive, keeping the developer focused. At the same time, it removes the responsibility for considerations like provisioning resources, which would be valuable knowledge for full-ownership developers.
• ‍"Infrastructure is really, really hard": Infrastructure can be unreliable; it fails; it is unpredictable. "Compared to software that runs pretty much the same way every time, infrastructure is really, really hard.” Containers and the cloud-native paradigm have simplified this to some extent, but there are still challenges exposed to developers.
• ‍Infrastructure and standardization is unpredictable and ever-changing: Even five years ago, there was no consensus that a universal infrastructure would emerge in the cloud-native space. Now Kubernetes has become a "standard-ish" infrastructure layer. The fast-moving nature of software development, and the cloud-native space more generally, makes it impossible to predict what technologies will dominate, and how the de facto standard of today may be different in just a couple of years.
• ‍Providing a centralized source of truth creates a good developer experience: Tools like Backstage or other developer control planes lessen the learning curve and provide a clarity of experience for developers without limiting their ability to seek out and learn platform tools beyond that portal. That is, developers can get access to a dashboard and 95% of what they need is centralized and actionable from the UI. Modular control planes enable enough developer autonomy to do what they need to do and "break the glass" to escape and move beyond that environment if needed, learning platform tools, working from the command line, or requesting specific functionality from the platform teams, when and if needed.
• ‍No unified developer experience, but self-service is an attribute developer experience should share: There's no one-size-fits-all developer experience, as shown by the variance between developers at established banks and startups. However, a growing consensus across different businesses is that providing application developers with more self-service management improves the process. This suggests that platform and SRE teams should focus on creating the right abstraction layers to empower developers, irrespective of their level of ownership in the process. Check out the full conversation between Daniel and Cheryl below.