Driving platform adoption through development environments

My biggest surprise at Platform Con 2024 in London was how many conversations I had about standardization and developer efficiency, yet only a few platform teams were aware of the capabilities of a cloud development environment, and how CDEs support platform engineering & AI teams.

Many of the teams I spoke to were running into ‘day 2’ issues when supporting large and complex tools; and almost all were wrestling with developer adoption issues. And for many teams, developer experience came as an afterthought, often only forming a developer experience team to solve adoption challenges for a very infrastructure-heavy and operations-heavy initial platform team. In contrast, a lot of the talks we heard spoke about the importance of doing ‘platform as a product’ and putting users and developers first.

For platform teams, having access to the development environment is something we’re not used to, as they’ve never really had influence on the development aspect of the software development life cycle. Platform teams will typically publish tools in a portal, and leave it up to developers to configure and integrate everything themselves. If they need developers to make an update, they have to chase with reminders and deadlines.

The result is slow adoption and uneven standards — exactly the kind of fragmentation that stalls development velocity and AI-native initiatives, where velocity depends on consistent, functional development environments.

With a cloud development environment, platform teams can balance control with freedom for their developers. This is because they gain direct access to support developers through development environments, not something they have typically had in the past, which has left many platform teams biased to support the ‘outer loop’ of development as opposed to the ‘inner loop’. With a CDE, platform teams have a way to centralize standardization through controlling and automating the following:

• Dependencies: automate the installation of all libraries, packages and dependencies. Configure a centralized Docker image that includes all your platform tooling such as your platform CLI. When you need a dependency bumped in all your environments, simply update the configurations to get it rolled out.
• Access management: automate developer access to networks, VPN and VPC configurations and access to external resources such as databases or clusters.
• Extensions: manage the installation of extensions including any authentication or configuration. If you’re rolling out an AI assistant program for developers, you can automate the installation of the extension, configuration and even authentication. You don’t have to ask developers to do anything, it just comes configured for them.
• Resources: configure the required resources for a given task. If developers need access to run a large build or test suite which requires more RAM or CPU, they can do that. You don’t need to set up complex self-serve interfaces to provision preview environments in your outer loop, instead developers can do that in their inner loop.

By centralizing dependencies, access, extensions, and resources, a CDE minimizes duplicated tooling, setup, and networking work across teams, freeing platform, AI, and application engineers to focus on larger improvements instead of wrestling with configuration and fixing broken setups.

A CDE ensures that a platform team’s efforts can be fully realized and delivered with minimal disruption to developers. With Ona, a developer would log in, use their preferred editor and tools, and maintain their usual access controls, all while the platform team manages standardization and ensures updates are done seamlessly. This ensures that 100% of the effort a platform team puts into platform initiatives is met with 100% ROI.

To read more about the impact of CDEs on the ROI of platform teams, read our CDE guide for platform teams.