Developer Control Planes: A CTO's Point of View

Adapting to and adopting new technologies can be a stumbling block, particularly in the crowded cloud-native development space, where technologies and solutions have not completely converged to create a clear pathway for adoption. For companies going in this direction, it often makes sense to turn to software development consultants for help in integrating the right emerging technologies for their needs. After all, most companies focus their expertise on solving their business problems and may benefit from the expertise of hands-on consulting.

Key themes and insights:

• Platforms are evolving: While Kubernetes has emerged as a kind of standard, providing more granular control and enhancing the ability to curate different platform experiences for different types of teams, it isn't entirely accurate to say that the platform question is settled. Kubernetes may be the platform around which focus has converged because of its fluidity and flexibility, letting you do just about anything. But more broadly, platforms continue to evolve, in large part because there are so many different ways to accomplish the many tasks that make up cloud-native development. On one hand, more mature companies may be happy with the Kubernetes setup. Many others, though, want a more curated, structured and opinionated path, with tools sitting on top of Kubernetes.
• ‍Ship: The direction centralization is going: Some centralization around specific platforms and tools is happening, much of which maps to the oft-cited code-ship-run paradigm. Many tools already exist around the "code" and "run" activities in this equation. Coding is what developers have always done, and the "run" aspect, though challenging, has benefited from a healthy range of available Kubernetes-as-a-service/PaaS type offerings and an industry-wide focus on both simplifying and building for running and observing software. But being able to ship, and getting continuous deployment going properly in these platforms, testing in production, and doing things that actually provide value at that stage is the direction and locus of innovation.
• ‍"Mechanical sympathy" as part of the developer experience: The idea that developers should magically be able to code, ship, and run everything themselves, while laudable, isn't necessarily realistic for every organization. Yet in any kind of organization, regardless of the developer's expected level of ownership, developers who have multiple skills and who, like their SRE and platform colleagues, do not stick exclusively with a complete separation of duties, provide a lot of value and insight to a team. Crucially, it is important that developers are able to understand what they are working on, having a level of “mechanical sympathy”, as coined by Martin Thompson. That is, if a developer understands what is going on under the hood, they are armed to build better applications from the outset. They may not have to run everything themselves, but knowing how distributed applications work and the challenges that come with that give devs the sympathy needed to code with the full life cycle, and its challenges, in mind.
• ‍Don't forget that it's a goal-oriented human endeavor: As the developer experience changes, it's critical to remember that it's not just about developers. There are other supporting team members, a wider community, and leadership, solidifying the idea that everyone is working together to achieve the same goals. Everyone's experience is changing. In a talk "Platform Engineering as a (Community) Service", Nicki talked about how easy it is to lose sight of the human innovators behind the development, and to lose sight of the contributors beyond the developer. But it's also about whole teams and stakeholders, everyone from data scientists to upper management, and how they pull together to achieve specific goals.
• ‍Data: A whole new world on the near horizon: Data, for as much hype as surrounds it, is an area that is not fully worked out in this space. Being able to build a specific data platform is challenging in any circumstances, but trying to build when it is not clear what is needed is much more difficult. Concepts like the data mesh are emerging, drawing on principles applied in the service-mesh world. But it is not just about the technology. It is also about structure, teams, who owns things, and this is still nebulous while the space evolves. With the rise of ML and AI, an entirely new set of challenges arise, adding complexity and requirements around integrating ML and AI into an automated platform. The bottom line is that the data question remains unanswered; the only certainty is that it will change things significantly in the near term.