Cloudomation DevStack:
The DevZero Alternative

DevZero

DevZero is a Kubernetes-based CDE platform. It allows developers to deploy a development container alongside other application containers into a Kubernetes cluster.

The core of the DevZero product is a “CDE management plane”, which is a component that allows to store CDE templates and use them to create and manage CDEs. The management plane is connected to one or more Kubernetes clusters, in which the CDEs run. Templating of CDEs is done in a custom yaml configuration format called “recipe” (not to be confused with Ansible recipes). The CDE itself is a single container. 

The management plane is always provided as SaaS. Customers can choose to deploy CDEs in their own infrastructure, but then they have to provide root access to their infrastructure (e.g. a cloud account) to the management plane in order to allow it to create resources within their infrastructure. There is currently no option to also host the management plane on-premise.

DevZero also has a few known issues which they will probably solve at some point, but mean some inconvenience for current users:

• CDEs cannot be stopped / hibernated manually, and it is not possible to customise hibernation logic. Once a workspace is “inactive” (no inbound connections) for more than 30 minutes, it will automatically be hibernated. Workspaces will automatically restart when there is an incoming connection. But: Only one hard-coded directory (/home/devzero) is persisted for hibernated workspaces. Any content outside of that directory is deleted on hibernation!
• Templating of CDEs is done via a custom yaml configuration format they call “recipes” (not to be confused with Ansible recipes). These recipes can only be defined in a web UI, where they are also stored and versioned. This means that recipes are not kept in your source code repository together with your source code, but are contained within the DevZero web UI and can only be accessed there. As a custom configuration format, it also requires some learning to figure out how such recipes are defined – though they now promote an AI assistant that supports the creation of recipes (haven’t tried it).
• CDE containers are hard coded to use an Ubuntu:22.04 base image. The documentation states that custom base images are available only to enterprise customers, suggesting that base images are somehow managed manually by the DevZero team.

DevZero is best for:

• Companies that develop Kubernetes-based products. However, for Kubernetes-based sofware, Okteto looks like a more mature commercial offering (though DevZero might be cheaper), and Eclipse Che is already the go-to choice for open-source tinkerers working with Kubernetes.
• Possibly for companies that are looking for a small vendor that may provide personalized support and services, though that is hard to judge from their website.

Cloudomation DevStack

Cloudomation DevStack is a highly customisable CDE product. It’s standard deployment model provides full VMs as CDEs to developers. However, the “unit” of a CDE can be customised to whatever the user needs: CDEs can be containers deployed into a Kubernetes cluster, several VMs, or serverless components – or anything else. Customisation of CDE deployment is done using Cloudomation Engine, a Python-based automation engine with broad infrastructure and deployment automation capabilities. Because of this flexibility, DevStack makes it possible to provide suitable CDEs for frontend, backend, data science, and other teams with different infrastructure needs and deployment models, and is particularly suitable for the development of complex, non-standard and/or heavy duty software. 

By asking senior developers how they would like to use a CDE, DevStack focused on features that allow seamless transition to using a CDE, without changing developer’s workflows and allowing them to use their existing tool sets. These features include:

• Synchronisation of the source code between the CDE and the developer’s laptop. Developers have “their hands on the code”, can continue to use any IDE they already have and love, and can work on the code even when offline, reconnecting with their CDE seamlessly when online again. (Note: Synchronisation of source code can be disabled.)
• A powerful command-line interface (CLI) that allows developers to open a terminal directly on the CDE, forward ports, stream logs from the CDE / containers running on the CDE VM, synchronise files between their laptop and the CDE (two-way), to create, start, stop, and delete CDEs directly from the terminal, and store their CDE configuration locally so that CDEs can be spun up with one terminal command. 

Cloudomation DevStack is best for:

• Complex, non-standard and/or heavy duty software development
• Companies that look for one CDE platform that can provide different kinds of CDEs to different development teams (e.g. working on different products with different deployment models, or backend and frontend teams etc.)
• Developers with well-working tool sets and development processes that want a CDE that adapts to their workflow and allows seamless transition to working with the CDE