Where CDEs bring value (and where they don’t)

In some corners of the internet, Cloud Development Environments (CDEs) are all the rage lately. Gartner has noticed and included CDEs in their hype cycle of emerging technologies in 2023. What are CDEs? Alexander T. Williams wrote: “Cloud development environments, also known as CDEs, are rapidly gaining traction as the next frontier of programming productivity. These platforms cover most of the developer experience, from the earliest stages of writing code to deploying finalized applications.”

As is often the case with hypes, a lot has been written about the general benefits of using CDEs:

Increasing developer’s productivity by reducing the time and effort spent on setting up and maintaining their development environments as well as providing them with sufficient computing resources to enable them to run the software they work on as part of their development environment
Increasing source code security by removing source code from local workstations
Reducing onboarding time for both internal and external developers by providing standardized environments with the click of a button

So far so good. These are often-promoted benefits.

But when do CDEs actually bring value?

To be valuable, CDEs must reduce complexity

CDE vendors want users to be able to start using their product as quickly and easily as possible.

Telling a customer that it will take a few days or even weeks of writing automations and configurations before they can even start to use and evaluate a CDE product is a no-go: most companies would not go for it.

So CDE vendors have a strong incentive to focus on software that is relatively easy to build and deploy. For such software, using a CDE can be a quick win, which makes it a lot easier to sell.

For example, at Cloudomation we’ve been working on a CDE product since February 2023. When I was gathering data about other CDE products, I noticed that most assume that the build of the software that is being worked on in the CDE can be expressed in a single config file – or at most a combination of e.g. a Docker-compose file that references Dockerfiles. The problem: for a lot of software, this is not possible. There is an order to deployment, and dependencies between components that cannot be expressed in these config files.

You can read about all the findings of my research in the white paper “Full list of CDE vendors (+ feature comparison table)“.

So there are invariably custom scripts that are part of the build process. These scripts cannot easily be forced into a standard because they are by definition unique to a specific software. They are built to express precisely those bits of logic that are required for a build which cannot be expressed with the existing standards.

It is understandable that many CDE vendors simply say: well, our CDEs are simply not suitable for this kind of software. They instead focus on software that can be deployed using single config files, and which can be deployed into a single container.

However, if you have software with a simple build which can be expressed in a single config file, and which can run within a single container, the complexity of deploying and running this software locally on developer’s workstations is already low. The developers will have no issue running a build locally if it can be expressed in a single, standard config file.

Developers won’t have problems with compute resources on their local workstations if their software is sufficiently lightweight to run in a single container.

So, paradoxically, most CDE products focus on exactly the kind of developer who already has low complexity in their development environment and will therefore benefit the least from using a CDE product. The companies that benefit most from using a CDE product are those that have high complexity in their build and deployment.

For example, these are companies whose product consists of many microservices which developers struggle to deploy locally both because the complexity of interdependencies of individual components is high, and because running many components locally requires a lot of compute, which often is more than laptops can handle.

With CDEs, developers would get rid of both the mental load of learning how to deploy their software locally, and maintaining local builds, as well as from getting rid of the high compute requirements on their workstations that come with such local deployments.

There is effort involved to make CDEs effortless

However, automating complex builds so that they can be done with the click of a button is hard. Moving complex builds to a CDE might mean redoing some bits of existing build scripts, and automating parts that haven’t been automated so far. Often, there are good reasons why some steps of the build have not yet been automated: either it is difficult to do, or they keep changing so that automation doesn’t keep up. In both cases, it will be challenging to automate complex builds to work with CDEs.

But a large part of the effort and pain that would be involved in moving complex CDEs is already being felt every day by every single developer who has to manage this complex build locally. Investing the effort to automating the local build cleanly once and moving this complexity away from developers would bring huge benefits. (Costs, burdens at all levels of the company)

No pain no gain

In a nutshell, this means that the biggest benefit of using CDEs accrues to companies that will have the hardest time moving to CDEs.

where cdes bring value and where they don't — Where cdes bring value…and where they don’t

There is no magic

The real benefit of CDEs is that they make it possible to move the complexity of a software’s build and deployment away from individual developers.

The effort invested in moving to a CDE consists of automating the deployment of a development environment once, including the local build, and then making it available to developers to repeat effortlessly. The more complex and the less automated a local build currently is, the higher will be the effort to move to a CDE, and the higher will be the benefit of moving to a CDE.

Therefore, in my opinion, the main focus of a CDE product should be:

to be as flexible as possible to accommodate the automation of complex builds,
to accommodate the use of existing build scripts as much as possible – this includes providing different deployment modes (e.g. into a Kubernetes cluster, to a VM, serverless …) that are compatible with existing scripts, and
to be easy to use for individual developers who should not have to worry about the complexity of the build anymore.

While most CDE products nail the third point, the first and second point is one that only some CDE vendors are starting to slowly understand.

However, the reason for this is not the CDE vendors themselves, but the expectations of customers. Even though we all know that magic doesn’t exist, we still often expect it. As consumers, we are often lazy and do not want to invest much effort into understanding a product. If it cannot be explained to me in three sentences, the likelihood is high that I won’t buy it. Worse: if the vendor tells me that using it will be hard, at least in the beginning, it’s even less likely that I will go for it.

Hard problems are hard to solve

But the truth is that hard problems are hard to solve. The same is true for high pain in development processes: if it was easy to fix, you would already have fixed it.

What a CDE product has to provide is a way for you to fix it, even if it will be hard.

The magic they provide is: they make it possible to solve the hard problem of complex builds and deployments, and to do so sustainably, in a way that reduces complexity for developers long-term.