The role of software developers building applications in a cloud-native ecosystem has extended well beyond simply writing code and now includes shipping and running the code. Importantly, the developer must make sure that the corresponding applications continue to run correctly when released into production.

We sat down with Bjorn Freeman-Benson, CTO at Ambassador Labs and discussed how developers can best manage this expanded responsibility, better manage and configure your technology stack, and support collaboration among the broader development teams to transform the developer experience.

Q: As an architect or tech lead, how do you make sure your development teams have the tools they need to manage all of the tasks required to code, ship and run apps in today’s cloud-native ecosystem?

It’s all about having the ability to scale, and having tools in place that integrate and allow teams to develop and roll out applications fast but have the ability to roll back at a given time without impacting team productivity, and more importantly, user experience.

Developers should take a self-service approach to operating their own services. They are taking ownership of these services, as they should, because they know these services best. It’s important to have an underlying infrastructure in place that makes it easy for these teams to manage all the different technologies in the stack, allow these technologies to communicate with one another, and ultimately supports their full lifecycle development process. The developer who knows the service is best positioned to identify what’s happening quickly when things start malfunctioning, which supports the goal of cloud-native development: to develop and roll out quickly.

Importantly, automating the underlying infrastructure and processes frees up dev teams to both develop and operate the software. They don’t have to know all the details of Kubernetes or all the different running environments and the components enabling them to develop and operate the software. The platform team builds that infrastructure so that developers can roll out from their own point of view.

Q: Who should be responsible for choosing and rolling out all of those tools? Developers, SREs, or Platform teams?

While my experiences have defaulted to providing a self-service experience for developers, it’s not a single role, team or individual that takes responsibility for this tooling. We all are responsible as each has a shared focus on delivering an excellent customer experience. Developers, SRE and platform managers play critical and interconnected roles in achieving business goals, and as a team can deliver by performing each team’s responsibility. As I mentioned earlier, the platform team develops infrastructure to empower the developer; the developer learns the tools needed to do their job; the SRE becomes more than just a firefighter when things go wrong and instead becomes someone who supports automating processes and helping to standardize or bring order to non-standard aspects of the full app-development process.

Q: As more developers take a self-service approach to full cloud-native application management, what is the most important element they should be thinking about?

They need to remember that they are not just developing but also operating software.  Also, the notion of code, ship and run – each is equally important in cloud-native application management.

However, of the three phases of cloud-native development, run is arguably most important as it’s the most challenging aspect of the dev lifecycle. We’ve got industry tools to support writing tests, and the last decade brought several good tools to support deployment. Yet, actually running the software is least mature as we lack the breadth of tooling to support the full cloud-native journey

Q: The CNCF landscape brings with it a myriad of tools to manage and support the development lifecycle. Should dev teams start thinking about ways to better consolidate and manage these tools? If so, where should they start?

Yes, absolutely. I’ve seen the industry go through waves of expansion and consolidation. And from my years of experience running many teams, microservices and the emergence of cloud technologies, one thing is clear in that there is a growing list of complex technologies that are hard to manage and impede collaboration across dev teams.

Operations teams have leveraged control planes for a long time and reaped the benefits. Now developers should leverage control planes to more easily and effectively manage full lifecycle development while reducing, or completely eliminating, technology complexities. Having a centralized way to integrate the code, ship and run processes is critical to bring about this consolidation and ultimately shift the developer experience.

Q: Should platform teams be more opinionated in the tooling that is available within an organization? And what about interoperability — are there advantages or disadvantages in how some of these tools work together?

I find that most platform teams don’t change the tools they use that often. People change jobs more often than change the tools they use.

I don’t think the company needs to spend too much time thinking about this. When selecting a new tool, they often want it to integrate this with an existing tool.  I find the most effective tools are the ones that integrate with lots and lots of other tools. In fact, the ones that are most effective are the ones that integrate with the tools you already use. So, if you use Jira and CircleCI, and you use GitLab, you want all these tools to integrate. You don’t really care if the tools integrate with other tools that you don’t use. Integrating a developer control plane really gives you the keys to the kingdom.

Q: If you were going to give some general advice to architects about where to get started in looking at this concept of a developer control plane, what would you recommend?

I have two pieces of advice. First, if you work at an organization that ships multiple services, they work on it from a top-down perspective. They’ve seen the problem and know how to build a system in-house that solves the problem for most people.

If you’re at an organization that is trying to build a general solution to a problem they are not fully aware of, you should take a bottom-up approach. Look around, identify the biggest problem your team is facing, and then build the tooling that integrates with the other tools you use to solve X problem. Then build your way up to the platform that actually solves the problems you are facing. It simply depends on where in the meta life cycle of the life cycle of services you are.

To hear more about cloud native topics, join the Cloud Native Computing Foundation and cloud native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021