In a cloud native world, software developers are no longer only responsible for writing code. Today’s developers must write and package code, deploy these services into production, and make sure that the corresponding applications continue to run correctly when released into production.
In a cloud-native world, software developers are no longer only responsible for writing code. Today’s developers must write and package code, deploy these services into production, and make sure that the corresponding applications continue to run correctly when released into production.
As part of an ongoing interview series about cloud-native development and easing the developer journey, we've spoken to a number of people about cloud-native challenges. These include different perspectives, including the SRE and platform architect.
In this interview, Ambassador's own Daniel Bryant, Director of DevRel, spoke with our own Bjorn Freeman-Benson, SVP of Engineering, to get both the engineering leadership and architect's point of view. They explored the challenges inherent in the question: "How do you make sure your development teams have the tools they need to manage all of these tasks?". Ultimately the conclusion drawn is that a developer control plane enables developers to control and configure the entire cloud development loop in order to ship software faster.
Dr. Freeman-Benson brings decades of experience leading world-class engineering teams and bringing the best-in-class products to market. As the Senior Vice President at New Relic, he built the team from 3 to more than 300 people within a five-year period, and also helped lead the company through an IPO and beyond. He was then appointed as the CTO at inVisionApp where he helped transform the company's offerings from a prototyping tool to a full stack product design platform. At Ambassador Labs he grew the engineering organization by 10x and built a product-led growth company. Earlier in his career, Freeman-Benson held a number of technology leadership and engineering roles at companies like Amazon, the Eclipse Foundation, and other innovative startups. Freeman-Benson holds a Bachelor of Computer Science, a Master's of Computer Science and a Ph.D. of Computer Science from the University of Washington.
Developer ownership of the software development life cycle (SDLC) isn't new: Although the "shift left" concept is pitched as being new as part of the move to cloud-native development, it isn't. Many organizations have tasked developers with more operational responsibilities all along, arguing that developers know best what they created. As a result, they can more quickly and clearly see problems in their own code and identify patterns they've seen before. This evolution has been somewhat inconsistent, but it's been a long time since, as Bjorn put it, "we wrote software that shipped on floppies--our job was done once we made the golden master floppy. I mean, that, literally, was the end of our job as engineers."
Platform teams provide support for developer self-service: In the developer-owned life cycle, platform teams build the underlying infrastructure with the goal of automating the things that developers don't need to know in order to be able to ship and run their services. "The goal was to build a platform that then allowed the development teams to just do the rollout from their point of view without having to worry about all the details of the insides of it."
Adopt a developer control plane: A developer control plane enhances your existing technology stack and enables collaboration among your development teams without requiring devs to worry about managing configuration.
Uptime as product: Although features are a part of what development teams ship, a big part of what end-users and customers pay for is uptime. The applications that dev teams have coded, and are now running, must continue running optimally, and that's ultimately the product: that is, availability, reliability, and uptime.
Scale means accountability 100% of the time: An extension to the product-as-uptime point is that developers have had to learn (and are still learning) that the scale of what they are creating (and running) is often so massive that the stakes, and accountability when things go wrong, increase exponentially. An outage can affect millions of users, and building resilience becomes more critical than rolling out new features all the time. The Google SRE team have talked about the similar concept of “error budgets” in their classic Site Reliability Engineering book. The trick, of course, is finding a balance. It's about creating and writing software just as much as it is operations. Much of the work of a developer control plane focuses on helping developers to achieve this balance between the two.