Cloudomation DevStack:
The Amazon CodeCatalyst Alternative

Deploy and manage remote development environments
– with Cloudomation DevStack. Test DevStack up to 1 year for free.

Cloudomation DevStack vs. Amazon CodeCatalyst

Feature	Cloudomation DevStack	Amazon CodeCatalyst
Hosting	Self-Managed, Managed On-Premise, Managed Cloud (SaaS)	SaaS The complex offerings of the major cloud providers require in-depth management expertise, although they are provided as SaaS. This distinguishes these offerings from “login and use” SaaS products.
USP	Code stays local, supports “weird” deployment models	Simple to use with other AWS tools
Pricing Model	Per hour CDE runtime	Per User
Pricing*	€ 80,60 / month Infrastructure: € 28,70; Licence: € 41,95; Support flat rate: € 9,95	€ 35,49 / month Infrastructure: € 16,80; Licence: € 18,69
Supported IDEs	All IDEs (e.g. VS Code, Jetbrains with and without SSH, Eclipse, Netbeans, Web IDEs, …)	AWS Cloud9 IDE, VS Code, JetBrains IDEs
CDEs are	VMs	a Container
CDE configuration	Devfile, devcontainer or custom	Devfile
Docker in the CDE	yes	No
Custom Blueprints User-defined CDE configuration, e.g. with custom deployment scripts	Yes	Only in the enterprise tier
Working offline possible	Yes Source code can be mirrored on developer laptop to enable offline work	No
Suitable for backend development	Yes Thanks to VM-based CDEs, even heavyweight backends with complex deployment logic can run on the CDE	No As CDEs are individual containers, only lightweight web apps or similar with simple deployment logic can run in the CDE
Easy transition for developers	Yes Local mirroring of source code enables developers to work “as always”. Using the CDE hardly requires any changes to the way of working	No Working purely online in the in-browser editor means a significant change in the way developers work

Source: https://codecatalyst.aws/explore/dev-environments, https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html

*Cost estimates were based on the following assumptions: Pricing estimates calculated for 8 core, 16GB ram machine type and 160 hours of CDE runtime / month

Amazon CodeCatalyst vs. Cloudomation DevStack

Amazon CodeCatalyst in a nutshell

Amazon calls its CodeCatalyst a “software development service” designed to provide automation and cloud resources for a range of different DevOps processes, including CDEs.

CodeCatalyst is part of the Amazon Web Services (AWS) cloud offering and is only available in the cloud.

Amazon Code Catalyst Dev Environment creation and configuration

In classic AWS style, developers are exposed to the full complexity of the AWS product range. To create a CDE, developers click through a diverse configuration menu. Whether and which configuration options are available depends on the selected license model. In the standard tier ($ 48 / year + variable infrastructure costs), only templates from public container repositories can be used. For user-defined templates, you need the Enterprise tier ($240 / year + variable infrastructure costs). However, since the CDEs are individual containers, it is not recommended to bring complex custom deployments into the CDE anyway.

A devfile.yaml can be used to configure the CDE container itself. In this yaml, for example, the container image to be used is selected.

In principle, the CodeCatalyst CDE model does not intend to running complex software within the CDE, but assumes that AWS-based software will be developed. This means that developers would deploy their software in AWS resources (containers, VMs, clusters, etc.) anyway and that these deployment processes are also used for working with CDEs. The crux of the matter is that developers are once again “separated” from their deployments and have no equivalent of a local deployment available. To access logs, for example, developers have to connect to these external resources. Setups of this type are not geared towards inner-loop needs. A frequent consequence of this is that developers try even harder to run their software locally.

Amazon CodeCatalyst Dev Environment pricing explained

When it comes to pricing, the devil is in the detail: As with all AWS products, a large number of individual items are charged separately. Quotas are included in each license package for each of the cost items. For example, “compute” is charged separately and additionally for the CDE runtime, which is used to perform compute-intensive tasks on the CDE (tests, build, etc.). How much compute is included in a license package depends on the required machine type. When using an 8 CPU / 16GB RAM machine, depending on the package, 6.25 – 12.5 hours / month of compute are included – not much. If a user exceeds the limits, the costs quickly become very high: for example, an additional hour of compute costs $1.20.

How high the costs per month and user actually are is just as difficult to estimate for CodeCatalyst as it is for other AWS products. We have made an effort and calculated a cost estimate based on an average usage model, as we see it with our own developers.

Briefly summarised:

8 vCPU / 16GB RAM machine for the dev environment and for compute
160 hours of use of the dev environment / month
25 hours (1500 minutes) of
compute for builds & tests / month
Total cost per developer: $97.70 / month or $1172.40 / year

Amazon CodeCatalyst is best for...

Amazon CodeCatalyst is aimed at companies that already operate their software primarily in the AWS Cloud. The idea is that CodeCatalyst can be used to reuse parts of existing automation – such as build or test containers. This should also bring developer work closer to the production environment and alleviate “works on my machine” problems.

The problem with this is that such a setup is not geared towards the needs of developers. With Amazon CodeCatalyst, developers have the opportunity to work on code purely online and independently of their local computer, and to push code changes directly into connected CI/CD pipelines. However, there is no direct equivalent of a local build. This means that developers have to wait longer for feedback, build less frequently and build larger code changes all at once. This in turn leads to slower learning and poorer quality in the developed software.

The biggest advantage of Amazon CodeCatalyst is that it is fundamentally flexible. With the enterprise subscription, it is possible to deviate from the CodeCatalyst model and map your own workflows. However, you cannot escape the basic concept of a single container as a development environment, which means that the co-location of code and built software in one environment (as with a local build) is not possible.

Cloudomation DevStack explained

Cloudomation DevStack is a platform for the automated deployment and management of Cloud Development Environments (CDEs). The DevStack platform includes Cloudomation Engine, a Python-based automation engine that is used to deploy CDEs.

Cloudomation DevStack can be operated on-premise or as a managed service in your own infrastructure (managed on-premise) or in the cloud (SaaS).

The standard deployment is based on VMs on which the development tools are executed. It is possible to deploy a single devcontainer in the CDE in order to run software directly on the VM. A complete Kubernetes cluster can also be deployed – depending on requirements.

The source code is synchronised with the developers’ local machine and allows them to choose any IDE. SSH-enabled IDEs such as VS Code or JetBrains IDEs can also be used, with the IDE backend running on the CDE. If you want to run complex software, Cloudomation’s VM approach is very flexible.

Cloudomation DevStack Dev environment creation and configuration

The configuration of CDEs in DevStack takes place on two levels. In Cloudomation Engine, the basic configuration is defined in “CDE types”. The CDE types can contain any configuration that is relevant for the deployment of the respective CDE and the software running on it. You can choose from ready-made templates for CDE types – e.g. for node.js projects, or if standards such as devfile or devcontainer.json are to be used, etc. The templates can be extended as desired, or completely custom CDE types can be created. The standard templates provide for full VMs to be deployed as CDEs. This can also be adapted if required and, for example, only containers can be deployed as CDEs.

Based on the CDE type configuration, associated automations are defined which create CDEs in the respective configuration. These automations are defined in Python. Here too, you can choose from existing templates, which can be adapted, or create your own automation scripts in Python.

The second level of configuration is freely definable and determines which additional configuration options are available to developers when creating a CDE. These configuration options are available to developers in a self-service portal. There, they select a CDE type in a small form as well as optional additional configurations that are specific to the respective software to be deployed in the CDE (e.g. whether and which test data should be loaded into the CDE, etc.).

Developers create CDEs themselves via the self-service portal in a simple, clean interface. Developers can mirror the source code locally via a CLI and, if desired, work locally with their preferred tools (e.g. IDE). Ports can be forwarded locally and logs from the CDE can be output in the local terminal. Developers can connect interactively to the CDE via the CLI and work with the software deployed there “as if it were local”. If developers are offline, they can continue to work on the code.

This means that developers’ existing working methods remain unchanged and the switch to a CDE requires hardly any adaptation. Only problematic parts of the local development environment are moved to the CDE: local deployment and resource-intensive tasks such as tests.

Cloudomation DevStack Dev Environment pricing explained

The pricing of Cloudomation DevStack is based on the runtime of CDEs. License packages can be purchased, which include CDE runtime minutes that are shared between all users.

Depending on the selected deployment model, infrastructure costs for the operation of CDEs are passed on in the SaaS model at no extra charge. This gives customers full flexibility over the resources they require, as there are no restrictions in terms of machine type etc.

Cloudomation DevStack is best for...

Cloudomation DevStack differs from other CDE products primarily through the flexibility and transparency of the underlying automation. The use of a powerful automation platform guarantees the traceability and robustness of automated CDE creation. This makes DevStack particularly suitable for:

Software with special deployment requirements, such as very many components with complex or time-critical dependencies on each other, or non-containerized deployments, or other special requirements,
Backend components that cannot be deployed in individual containers,
Software that produces artifacts that developers need direct access to (reports, data, images, etc.),
Different CDE variants that should remain clear and easy to maintain,
Companies looking for independence from cloud providers,
Easy switch to CDEs that require little change in the way developers work,
Developers who also work offline from time to time or only have a slow/interrupted internet connection.

Features

Cloudomation DevStack features at a glance.

Managed Cloud and On-Premise

Decide on your preferred hosting: Self-hosted on premise, managed on-premise or managed cloud (SaaS).

CDEs based on VMs

VM-based development environments in which the software to be developed and all the necessary tools are available.

DevEx first

Built to integrate seamlessly with existing workflows and tool stacks of developers.