Transform you dev teams workflow: Why CDEs make backend development a breeze

I recently talked to a senior developer at a large software company about Cloud Development Environments (CDEs). His company is one that invests a lot in developer experience: There are dedicated teams that ensure that developers have good tools at their disposal and can focus on writing code, instead of fixing build pipelines or troubleshooting their local deployments.

My counterpart was a backend developer. The software he works on consists of several dozen individual components. There are a lot of different teams working on each of those components. Many of those teams are frontend teams who work on different webapps that expose different functionality to the user.

After talking for half an hour, he suddenly realised that he had heard of CDEs before: there was an initiative at his company to roll out CDEs! He said that a dedicated team had been established to manage the rollout and then to take care of the CDEs.

The reason he had not thought of that earlier: It was not for him, or his colleagues working on the backend. The CDEs were being rolled out exclusively for the frontend teams.

He told me about the current setup of the frontend teams: they deploy their single webapp locally, and use prepared configs to connect to backend services in shared dev clusters. Even though this already sounded like a very comfortable setup to my ears, he said that some frontend developers struggled with this and didn’t like having to take care of which backend cluster to connect to and how this works. So they would roll out CDEs for the frontend teams who would then only have to click a button to deploy their CDE.

But why was it not for them (Backend devs)?

Because backend services couldn’t run in those CDEs. They were only for “lightweight stuff”, he said. They would probably break if he tried to deploy his stack in there.

I’m not sure if they would break or just provide a really bad experience. In any case, it made me curious. The conversation left me with two questions:

What is the value add of CDEs for frontend devs?
What would a CDE for backend development look like?

In this post, I’d like to answer those questions.

What is the value add of CDEs for frontend devs?

Frontend developers working on a multi-component complex software are cursed with having a lot of dependencies. Every frontend needs data from a backend to function. This means that every frontend developer needs to be able to access backend components in order to validate their work.

This means that frontend developers are burdened with having to know how to deploy and access backend services. Depending on how automated this is, it can be a significant time sink and require significant knowledge to be able to deploy multiple backend components and configuring a frontend component to communicate with those backend components correctly.

With a CDE, this should come out of the box: the developer should be able to specify which frontend component(s) they want to work on, and the CDE should be configured to automatically deploy the required backend components in the right versions, or connect to existing backend components in shared development clusters.

Therefore, the value add of using CDEs for frontend developers can be significant: it can completely remove the need to know anything about how backend services are deployed and how they run. Considering that this knowledge is of little relevance to the frontend developers – it doesn’t make them better at building good frontends to know how to deploy software to Kubernetes pods, for example – this is a big value add. This, however, requires CDEs that are able to run the backend.

And the biggest benefit of using such a CDE for the frontend dev would be that it deploys backend services for them automatically.

Whether or not the frontend component(s) are still deployed locally on the frontend developer’s laptop would actually not make that much of a difference. The reason for this is twofold:

A single frontend component is typically not very resource intensive and can easily run with the CPU and RAM available on a developer’s laptop,
Deployment of (web-)frontend components is typically a lot less complex than deployment of backend components, because it is typically only one single component with one single tech stack which is typically well automated. Frontend developers are often lucky enough to be able to deploy their component with a simple “npm (or yarn) run build” command.

As a consequence, the pain of local deployment for individual frontend components is typically low.

Therefore, what frontend developers need most is not a CDE in which they can run their frontend component, but something that takes away the hassle of deploying the backend. Having a CDE that runs the frontend component is a nice-to-have.

One option to achieve this is a development setup as the one my developer colleague mentioned: Having development clusters that run backend services to which frontend developers can connect remotely. In this three-part blog post series, I take a closer look at this setup.

With a setup like this, the value-add of a CDE for frontend developers would be reduced. It would still remove the need for frontend developers to deploy their frontend component locally and, more importantly, to connect their frontend components to remote backend services correctly. But the main hassle – local deployment of backend services – would already be removed by using remote backend services.

Getting to such a setup can, however, involve significant effort. It also has some requirements on the software that is being developed (backend services have to be shareable), which is not always the case. An alternative are CDEs that can deploy both the backend and the frontend. This would be a CDE that could also be used by backend developers.

What would a CDE for backend development look like?

Backend developers face the same challenges as frontend developers when it comes to running backend components locally:

Backend components often have high interdependencies with each other, so that individual components cannot be deployed separately. There is often a minimum set of components that have to run at the same time for any one of the components to work properly.
Backend components often have higher resource requirements than frontend components. Especially when running several backend components locally, this can quickly overwhelm a developer’s laptop.
Backend deployment is typically a lot more complex than frontend deployment because the backend often
- Consists of several components,
- Requires one or several databases,
- Consists of different technologies (languagues, frameworks, compilers …) within the same backend,
- Use a much broader range of technologies than frontends (which always result in html / css / js), leading to a multitude of deployment tools of varying maturity
Related to this, it is very common that backend components have custom deployment requirements that are unique to a specific application.

But, for better or worse, backend developers need their hands on the backend, and for that, they need to be able to deploy it somewhere close, where they have full access to the backend components, their logs and their APIs. This means that a remote development cluster doesn’t solve the problem of local deployment for backend developers. They would still need to deploy at least the component(s) they work on locally. Log and API access are not the only reasons: They are making changes to their component, which they could not feasibly do in a shared development cluster without interfering with every other developer’s work.

To be useful for backend development, a CDE would therefore have to:

Allow deployment of several components to the CDE,
Provide sufficient compute, ideally highly customizable compute, to support the running of heavy-duty backend components or large sets of backend components,
Allow highly customizable deployment automation to accommodate complex custom backend deployments,
Allow developers full access to the CDE and the backend components running there.

Just looking at the normal way backend developers work, this would be the minimum set of requirements that a CDE would have to fulfil to be useful to backend developers.

A CDE that fulfils those requirements would create large benefits for backend developers: They would be provided with sufficient compute resources and full access to the backend components without the hassle of managing complex local deployment.

In addition, a CDE like that could be used by both backend and frontend developers. Such a CDE could easily accommodate frontend component(s) as well, and alleviate the biggest pain point for both frontend and backend developers: the deployment of complex backends.

Summary

Developers working on complex, multi-component or otherwise heavy-duty software often have a hard time managing local deployment of complex backends.
But both frontend and backend developers need (at least parts of) the backend in order to do their work.
If the software they work on supports this, frontend developers can get rid of local deployment of the backend by connecting their locally deployed frontend to a remote backend (see related blog post)
But backend developers need “hands-on” access to the backend that they work on and also typically cannot share the component they work on since they are making active changes to that component.
A CDE that allows deployment of complex backends in the CDE and gives developers full access to the CDE and the components running on it would provide large benefits to backend developers, as it would remove the need for backend developers to deploy backend components locally.
Such a CDE could also be used by frontend developers, who also suffer most from having to deploy complex backends, and could deploy the frontend components to such a CDE as well.

And you guessed it: Our CDE platform Cloudomation DevStack does just that. It gives full access to the CDE to all developers by default, it allows deployment of several (or few heavy-duty) components to the CDE, and is highly customizable both in terms of deployment logic as well as compute resources available on the CDE.

In addition, we built our CDE platform with the goal to feel as similar to local development as possible. The switch to a CDE should be frictionless, and your existing workflows should have to change as little as possible.

We talk a lot to developers as we build our product, and we listen. If you are a developer and are open to a half-hour interview, please let us know – we’d love to get your input.