Developer productivity vs. developer experience: Does cloud native make a difference?

In the first article in this series, I discussed the three paradoxes of cloud native platform engineering: how measuring developer productivity can inadvertently lower it; how platform engineering efforts can backfire by being overly normative; and how cloud native developers must focus on individual microservices as well as the behavior of pods and clusters simultaneously.

In the second article, my colleague Eric Newcomer explored in depth the challenges platform engineers face when building internal developer platforms (IDPs) for cloud native developers. 

He concludes that success requires the right organizational structure and governance, a good measure of discipline and the right combination of platform tools in the IDP – in particular, observability tooling that tailors data specifically for the small autonomous teams that develop, deploy, and support microservices. 

There are two threads that weave their ways through these arguments. The first is developer productivity – how much individual developers and teams can accomplish in a given amount of time. 

The second thread is every bit as important: developer experience, or DX. DX is a measure of how effectively developers can do their jobs with the tooling and platforms available, combined with morale and overall job satisfaction.

The more challenges thrown at developers, the more difficult it becomes to produce quality work consistently. Simultaneously, pressure to increase productivity in such situations can have a deleterious impact on DX, a situation that will surely backfire.

Cloud native is one area that presents such challenges. Building microservices in the context of a cloud native deployment at scale is difficult and complex. How, then, should organizations balance developer productivity and DX for cloud native initiatives? And ideally, how to improve both at once?

Cloud native development begins with microservices. And while there are many definitions of microservices (many not “micro” at all), one popular definition is a “parsimonious, cohesive unit of execution.”

“Parsimonious” means as small as possible, but no smaller – the “micro” part of the story. “Cohesion” is a well-known characteristic of good software that means that each microservice does one thing and one thing well.

“Unit of execution” refers to the fact that microservices running in containers include the runtime components necessary to execute – an intentional contrast to the earlier generation of web services that were XML-based endpoints to software that required enterprise service buses (or other technology like servlet engines) to provide the execution context.

Within the broader cloud native architectural context, furthermore, microservices require additional considerations. They automatically scale up and down within pods, and thus developers must design them to be stateless. As a result, managing state with microservices requires special care to gain the benefits of dynamic scaling.

To maintain productivity, cloud native developers must work with the DevOps team to keep track of all these microservice properties for every microservice all the time, keeping in mind the functionality of each microservice within the broader cloud native architectural context.

In other words, cloud native development is difficult and complicated – challenges that can easily affect both developer productivity and DX.

The good news: Developers love a challenge. Most of them chose their career because of the inherent satisfaction in solving difficult puzzles. There’s no better feeling than when a particularly difficult piece of code finally runs the way it’s supposed to.

There is a fine line, however, between challenges that are fun and fulfilling vs. problems so difficult that working on them is like pounding your head against a wall. For many developers, cloud native development is more of the wall-pounding kind.

Both developer productivity and DX depend upon shifting this equation toward the sorts of challenges that developers love. IDPs can help, as they provide developers with a recommended set of tools, but having the right tools is critical.

Of all the tools you might find in an IDP that contribute most to both productivity and DX are observability tools. Difficult problems are fine as long as developers have the information they need to solve them – and observability tooling like Chronosphere provides that information.

Not only does Chronosphere provide observability specifically for developers, it also specializes in observing cloud native environments. 

Chronosphere has designed their platform to meet the observability needs of the cloud native developer. In particular, Chronosphere Lens goes beyond raw telemetry by dynamically generating service-centric views that support developers in both proactive exploration and reactive troubleshooting of system behavior.

When management focuses too much on developer productivity, developer experience can suffer, and thus hurt morale and paradoxically, productivity as well. It’s important for management to have a light touch to avoid this problem, especially with cloud native. 

Cloud native environments can become so dynamic and noisy that both productivity and developer experience can decline. Management must take special care to support its developers with the right platforms, tools, processes and productivity metrics to facilitate the best outcomes, leveraging platform engineering to create and manage IDPs that facilitate cloud native development despite its inherent complexity.

After all, the complexity of cloud native development alone isn’t the problem. Complexity presents challenges to be sure, but developers are always up for a challenge. Complexity coupled with a lack of visibility brings frustration, lowering productivity and DX.

With the right observability, for example, with Chronosphere and Google Cloud, developers have a good shot at untangling cloud native’s inherent complexity, delivering quality software on time and on budget, while maintaining both productivity and DX.

Copyright © Intellyx BV. Chronosphere is an Intellyx customer. None of the other organizations mentioned in this article is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used to write this article.