Naming Matters: 4 Tools that are NOT CDEs

  • Published

The CDE market is kind of like the wild west, still figuring itself out with a lot of new products popping up like mushrooms after a rainstorm in 2022 and 2023. Even vendors who have been on the market for a long time are rebuilding their products and/or have only released stable versions recently.

Now, this leaves us with a bit of a riddle. The CDE category is like that one friend who insists on being mysterious and undefined…and causing more confusion than a crossword puzzle in a foreign language. Because some companies are throwing the term CDE around like confetti at a parade. For example, even Cloud IDEs are often referred to as CDEs. Talk about a terminology party foul!

But also Dev Containers, Devfile, Nix and Devbox by Jetpack are getting the CDE name dropped on them left and right. They are like the cool kids in a class of development tools, often making it into the classic “top CDE tools” lists and blog posts.

But in our humble opinion, that’s not entirely accurate. They are not CDEs. (But don’t get us wrong: they may be good solutions for some development teams who might not need a “full” CDE).

Why? We believe that CDEs are the real deal…ok, that’s a little bit too much. But listen, we surely believe in this definition: CDEs allow developers to do their work in a cloud workspace that provides all the tools they need.

So buckle up. In this post and with this definition in mind, we outline why Dev Containers, Devfile, Nix and Devbox by Jetpack are NOT CDEs.

#1 Dev Containers

Dev Containers is a partially open source standard for describing containerised development environments. It differs from other products by not being a platform that allows to deploy and manage several CDEs, but rather a small tool consisting of a command line interface (CLI) that allows developers to locally deploy a container. Configuration of the container is done via a devcontainer.json config file.

Since the Dev Container project doesn’t include tooling to run dev containers in the cloud or to connect to Dev Containers remotely, it is not a CDE in itself. That is also not the goal of the Dev Containers project: it primarily seeks to define a standard for defining containerised development environments.

More info: https://containers.dev/

#2 Devfiles

Devfile is an open source standard for defining containerised development environments. Similar to the devcontainers standard, it is not itself a CDE solution but a standard that many CDE products use for configuration of CDEs.

More info: https://devfile.io/
Docs: https://devfile.io/docs/

#3 Nix package manager

Like the name suggests, Nix is a package manager and not a CDE tool. A package manager allows defining bundles of libraries into a package that contains all dependencies for an application to run. As it happens, it is possible to define development environments as such a package. Nix showcases this here: https://nixos.org/#asciinema-demo-example_3. There are other resources out there describing how Nix can be used to define and distribute development environments as Nix packages.

The USP of Nix is that it creates isolated packages. This means each package contains everything it needs, and defining a package requires explicitly stating every dependency in its required version. This makes it possible for different packages to use different versions of the same library, removing dependency conflicts.

Since dependency conflicts are often a big problem when working on different versions of the software you develop (which might require different versions of dependencies), this can be solved by creating Nix packages for your different versions.

However, being a package manager, Nix doesn’t provide a platform to manage CDEs, or infrastructure where they can be run. Therefore, Nix is also not a CDE.

More info: https://nixos.org/
Docs: https://nix.dev/

#1 Dev Containers

Dev Containers is a partially open source standard for describing containerised development environments. It differs from other products by not being a platform that allows to deploy and manage several CDEs, but rather a small tool consisting of a command line interface (CLI) that allows developers to locally deploy a container. Configuration of the container is done via a devcontainer.json config file.

Since the Dev Container project doesn’t include tooling to run dev containers in the cloud or to connect to Dev Containers remotely, it is not a CDE in itself. That is also not the goal of the Dev Containers project: it primarily seeks to define a standard for defining containerised development environments.

More info: https://containers.dev/

#4 Devbox by Jetpack

Devbox is based on the Nix package manager and provides isolated Nix packages for development environments.

By creating CDEs as packages, the level of isolation is different from a container or a VM: an isolated package contains all dependencies the package needs to run, but shares the operating system with the rest of the environment. By isolating the packages, Nix makes it possible to remove dependency conflicts that arise from different software in the same environment needing different versions of some other software.

Configuration of the Devbox environments is done by customizing existing Devbox templates through a CLI. Configuration is stored in a devbox.json which is intended to be committed to the source repo, where other developers can then deploy the same Devbox with the same config. Adding custom scripts e.g. to deploy your own software is also possible.
CDEs as packages are an interesting idea: it makes it very simple to distribute the packages. Developers simply install a package (based on a config file they get from their source repo) with a package manager like they do for many other things as well.

However, Devbox addresses only the issue of dependency conflicts – which the Nix package manager really does for them. What Jetpack does is to provide templates for dev environments that can be used with the Nix package manager. It doesn’t provide tooling for remote development, and therefore doesn’t qualify as a CDE.

It’s not a cloud or remote development environment. Developers install CDE packages locally. They could be installed anywhere, but then the issue of managing and connecting to these remote CDEs is the problem of the user. This also means that developers are stuck with the performance they get locally.

More info: https://www.jetpack.io/devbox
Docs: https://www.jetpack.io/devbox/docs/

Summary

The current state of the Cloud Development Environment (CDE) market resembles the wild west, with numerous new products emerging and established vendors revamping their offerings. The term “CDE” is thrown around loosely, creating confusion akin to solving a crossword in a foreign language. Notably, Dev Containers, Devfiles, Nix, and Devbox by Jetpack are often mislabeled as CDEs. While these alternative tools may have their niche, we hope that this post clarified why they don’t fit in the CDE category. What is your opinion on this? Share this post on social media and tag us to join the discussion.

Whitepaper: Full list of CDE vendors (+ feature comparison table)

Get an in-depth look at how Cloud Development Environments work and compare all the vendors.

Get the whitepaper

Subscribe to the Cloudomation newsletter

Become a Cloudomation Insider. Always receive new news on “Remote Development Environments” and “DevOps” at the end of the month. 




    Johannes Ebner

    Marketing Manager