Making Sense of the Chaos: Considerations for a Cloud-Native Future

Nicki Watt, doing double executive duty at OpenCredo as both CEO and CTO, spoke with Ambassador Labs's Daniel Bryant in a recent interview. Ground covered included centralizing but customizing the developer experience based on organizational culture, maturity, and business needs; the importance of understanding that it's not all about the developer, and considerations for a data-driven, cloud-native future.

Finding the Sweet Spot: Between Full Developer Ownership and an Opinionated Path

An overwhelming number of ways and tools exist to do things in a cloud-native environment, and the platforms and tools continue to evolve. While many organizations have converged around Kubernetes as the baseline, and the oft-repeated refrain about cloud native is that developers must assume complete ownership of the software lifecycle, the reality is a mix of very different levels of freedom and responsibility for developers. For a consultant entering and evaluating an organization from the outside, it becomes clear that organizational culture, business needs and expectations, the cloud maturity of the organization, and how much the organization wants to do for themselves all influence how their solution is built.

"Some organizations are set up to empower developers to take on as much as they want; others are siloed and prefer to "contain" developers, ensuring that there are no deviations, no going off-piste," Nicki explained.

The Balance between "Mechanical Sympathy" and Developer Empowerment

As much as has been said about developers leading the charge and being empowered to own their software throughout the code, ship, and run phases of development and release, it's not always as simple as that. From her experience across companies and industries, Nicki observed that the level of empowerment developers were given was dependent, once again, on organizational structure and culture. Some organizations are happy to turn developers loose while others set guardrails and others still completely pave the path and allow for no divergence.

Perhaps more important than actually being empowered to, and tasked with, running software end to end, according to Nicki, is understanding. That is, developers should possess multiple skills and understand exactly what they're working on, even if they are not responsible for running it. This boils down to "mechanical sympathy", a term attributed to Martin Thompson: the better a developer understands the hardware, the infrastructure, and how things run, the better they will be at coding and avoiding and identifying problems down the line.

In many organizations, empowering developers with in-depth knowledge about how distributed applications work and the common challenges inherent in distributed systems, this provides more value to both the organization and the entire team (the developer, the SRE, the ops teams, etc.).

Organizational Culture, Business Needs, Changing Roles: It's Not All about the Developer

Fundamentally, the expectation is that a certain value will come from the platform an organization is investing in. And the way it is built should be driven by what the ultimate goal is. If it's about constraining freedom and achieving cost savings, the platform will be built one way, but if the goal is innovation, it will be structured and approached in an entirely different way. And teams, their roles, and organizational and cultural decisions should follow.

Nicki explained, "I did a talk focusing on platform engineering as a community service … part of that is to recognize that when you build a platform, it is not just the developers. It is more a community effort. It is also the data scientists and management because they are expecting certain value to come from the platform. Part of this is to show the upside of providing developers with enough freedom to innovate. If you are so constrained that you are unable to innovate, it slows people down…. Put another way, it is about focusing on the business needs and goals and what organizational and cultural changes need to be made to achieve them rather than strictly outlining a set of technical specifications."

When building software from the ground up purely as an engineering initiative, it tends to fail. Not because it is technically difficult but it also requires organizational change.

A goal-specific organizational-level evolution has to be a part of the adaptation. The idea has to be sold into C-level executives, and the organization as a whole, to allow for real innovation at the technical level. And that could require some data to justify.

Data and the Developer

Data is one area that developers, and indeed organizations, are still trying to figure out. Being able to build a specific data platform for something is challenging enough but without knowing exactly what the requirements (and risks) are, it becomes considerably more difficult. Once more, it is not only a question of technology, such as a data mesh approach similar to service meshes, but also about culture, structure, teams, who owns and is responsible for things. On top of this, the lack of concrete certainty means that the data area is also constantly evolving. Different considerations and skills are required depending on what is being built.

Specifically for the developer experience, while it is still impossible to predict, building ML and AI will likely shift the developer experience depending on emphasis. That is, data engineering and data science are two different things. There will be different kinds of developers acting in this space, so for example, data engineers will focus on engineering and automation while data scientists will focus on experimentation and exploration of data.

Another immediate and major consideration is data privacy and security. Any time data enters the fray, of course, risk becomes endemic, and this too will influence the developer experience as well as overall organizational approaches to building data-oriented tools and platforms. Risk assessment, and considering compliance, data privacy, and similar mandates and requirements, will need to be built into the initial planning phases.

"It's never been in the developer's purview to worry too much about data, but with GDPR and other data governance mandates, and a boom in the use of PII and client data, it's inevitable that developers have to at least consider and build with this in mind," Nicki says, "While cloud and database as-a-service type solutions can help because they surface some of the requirements and questions you need to answer in handling data, it's not a fix-all. Managing compliance is complex, and you do have to take these things into account at an architectural level, and not all services are equal in doing this.

There are a lot of interesting questions in this sphere. For example, if your data is stored, and you need to access it for testing, and build around it, what happens then? Are you still compliant or have you incorrectly accessed data, or potentially put the data somewhere it shouldn't be? Developers have not had to think about some of these things. They should, at least, again to the level they assume the mechanical sympathy I mentioned, and have a fundamental understanding of risk and what is at stake."

Highlighting Risk from the Start

In general, risk assessment should be done from early planning phases. This becomes even more critical with data-related projects. If data governance and access management is built into a platform from the outset, risk is significantly reduced.

But, as Nicki points out, "We are not keen as humans to dwell on the bad, so thinking through the consequences isn't always a strong point. I like to highlight risk up front and frame it as both a protective measure and pose it as a question. It isn't effective just to list off all the ways an organization needs to comply. Instead, whether it is with data or other issues, I phrase the challenge differently, along the lines of, 'Imagine this scenario. Your data has been breached, and you are getting a lot of negative publicity. How expensive is this going to be? How much of this scrutiny can your brand stand?' These what-if scenarios hit home much harder than any finger-wagging anyone can do."

Conclusion: Empowered Developers — Guardrails over Cages

Whether developers have full freedom to own the full software lifecycle or are more constrained by organizational or platform restrictions, getting to a point where developers are empowered to take on increasing levels of responsibility can, according to Nicki, contribute to better teams.

A number of leaders (Lunar's Kasper Nissen, CartaX's Mario Loria, and Apple's Cheryl Hung) in the cloud-native community have echoed similar sentiments, sharing the idea that providing guardrails, or an opinionated path or developer control plane, can help promote both developer freedom and responsibility, and possibly an island of stability, in a constantly changing maelstrom.