Cloud Development Environments (CDEs) are a young product category. Little standardisation exists in the CDE market so far, with each CDE vendor offering a unique set of features, with large differences in technologies, features, and core concepts between CDE products. In this post, we want to explain how DevStack is different from other CDE products – and which software products DevStack is most suitable for.
#1 DevStack adapts to the developer
Most CDE products support one development process with a specific set of tools. If the developer sticks to that process, they will have a smooth experience using the CDE. If, however, the developer needs something different or simply doesn’t want to change their well-working habits, they will not be able to use many CDE products.
Specifically, most CDE products restrict developers to:
- One specific IDE or a choice of a handful of compatible IDEs, which are often used in the browser,
- One specific working model which typically places the source code away from the developer, on the CDE, where the dev has access only through the IDE,
- Limited access to the CDE file system.
This means that, with many CDE products, developers have to fundamentally change their way of working when they start using a CDE, often switching to a purely browser-based development model. Even when developers can continue to use their favourite IDE, if it is supported by the CDE, they often have only limited access to the CDE file system, meaning that they can only interact with the CDE through the IDE. In addition, developers cannot work without internet, and are also fully blocked when the CDE platform itself is down.
Read more: How CDEs work – no bs
DevStack on the other hand wants to make the switch to using a CDE as simple and smooth as possible for developers. Whatever preferences and existing development processes exist, DevStack aims to adapt by supporting:
- Free choice of source code location with the standard configuration mirroring the source code on the developer’s laptop as well as the CDE. This enables:
- Free choice of IDE or editor. With local access to the source code, the developer can choose any IDE and work with their source code locally. The source code is mirrored on the CDE, and any changes are propagated on save (not via a commit to the source control). Resource-intensive tasks like debugging still run on the CDE.
- Working offline. With the source code and IDE on the developer’s laptop, they are able to work on the code when they don’t have an internet connection. CDE-specific functionality such as running builds or tests or debugging the code are not available offline, but the developer can still be productive without internet.
- Mirroring of other artefacts, for example logs or reports or files generated by the software that the developer works on, to the developer’s laptop. This allows the developer to work with logs and files comfortably, with any tool they choose, on their laptop.
- Side note: If the developer works on a software that produces large files such as, e.g., video files, mirroring them locally will require high internet bandwidth, which makes it more practical to access such large files on the CDE directly, which is possible. On the other hand, if large amounts of data are required for the software that the developer works on, e.g. as example or test data, then this data can be transferred from remote locations within the company’s infrastructure to the CDE with lightning speed due to the high bandwidth available on the CDE, which will typically be orders of magnitude higher than the bandwidth available on developer’s laptops.
- Full access to the CDE. In the standard configuration, DevStack CDEs are virtual machines that the developer can access via ssh. The developer has full access to the file system and all processes running on the CDE. Through the DevStack CLI, opening a terminal session on the CDE is very easy and allows the developer to work on the CDE much in the same way as they would on a local terminal.
DevStack aims to disrupt developers workflows as little as possible by leaving everything that works well in local development on the developers laptop – IDE and source code – while moving only the parts that are often painful in local development to the CDE – build and deployment of the software, testing, debugging and other resource intensive tasks.
Read more: What the standard CDE architecture looks like (and how DevStack is different)
#2 DevStack adapts to the software
Most CDE products provide CDEs as single containers. This means that the software that the developer works on must be deployed within that single container, or it cannot be part of their development environment. For small, single-component applications such as simple websites or webapps, this is unproblematic. For any type of multi-component software, server software with large components such as database backends and other heavy-duty software (which encompasses the majority of business software), this is not feasible.
A second group of CDE products allow for the deployment of containerised multi-component software. In such cases, a single development container (the CDE) is deployed alongside other components which contain the software that the developer works on. This typically deploys the entire stack (development container and application) into a Kubernetes (or OpenShift) cluster. While this allows working on containerised multi-component software, it separates the developer from the application in significant ways. Accessing other containers within a K8s deployment is complex. This is the reason why local deployments of containerised multi-component software typically rely on docker-compose to deploy containers directly on the laptop, without the added layer of complexity that Kubernetes introduces. Docker-compose workflows are not supported by the majority of CDE products.
Read more: Problems with the local development environment: Is containerisation the solution?
DevStack, on the other hand, aims to reproduce the local development environment as faithfully as possible. The standard configuration of DevStack deploys a full VM as the development environment, to which any type of (containerised or not containerised) software can be deployed. Existing deployment scripts can be reused. Resources of the CDE can be configured freely, with the option to deploy very large CDEs, to add GPUs to the CDE, to deploy only part of the software to the CDE and connect to other components in a shared development cluster, or to deploy to several VMs.
While this flexibility means that some customisation is required to configure a CDE for a specific software project, we believe that this will provide the best experience for developers. Customisation of software deployment into the CDE typically takes an experienced DevStack consultant 1-5 days to set up and hand over, which is significantly less than the time required by many other CDE products to rework and rebuild existing deployment models to fit the CDE’s deployment model.
#3 Flexible hosting options with transparent pricing
Most CDE products are available only as SaaS, where the customer accesses the CDE platform in the cloud.
This requires the customer to trust the CDE vendor with their most valuable asset: their source code, which is contained within every single CDE in the cloud infrastructure of the CDE vendor.
In addition, the most common CDE pricing model charges users for each hour that a CDE runs, with a significant surcharge on top of the actual infrastructure cost, which increases starkly for larger machine types. This makes SaaS offerings very expensive for software projects with medium to high resource requirements.
Open Source CDE products can (mostly) be self-hosted, but don’t offer any support for self-hosting. Considering the fact that CDE platforms are complex software products, this leaves users with considerable operational overhead.
Managed on-premise is the best-of-both-worlds option which allows customers to keep their source code within their infrastructure, while still outsourcing the maintenance of the CDE platform to the CDE vendor. This option is offered only by very few CDE vendors and typically comes with very high managed service fees.
By supporting different hosting options for the DevStack platform, we empower organisations to balance infrastructure cost and management effort. DevStack is available as:
- Fully self-hosted with support: The customer hosts and maintains the DevStack platform themselves. The customer chooses where they want to host the DevStack platform: in their own public or private cloud infrastructure, or on their own premises. We provide support for our customers to help them get set up and manage updates and other maintenance tasks for their DevStack installation. We charge a flat-rate support fee, and a fixed rate per CDE hour that is independent of the machine type or infrastructure used by the CDE.
- Managed on-premise: The customer chooses where the DevStack platform should be hosted: in their private or public cloud infrastructure or on their own premises. The customer provides us with access to the infrastructure. We install and manage the DevStack platform for our customers. We charge a flat-rate managed service and support fee, and a fixed rate per CDE hour that is independent of the machine type or infrastructure used by the CDE.
- SaaS: The customer accesses the DevStack platform in the cloud, where we host it within our own infrastructure. We charge a flat-rate managed service and support fee, and a fixed rate per CDE hour that is independent of the machine type or infrastructure used by the CDE, and invoice our customers separately for the infrastructure cost, with no surcharge. This enables customers to use high-powered CDEs in a SaaS offering without costs exploding, and with full transparency.
Find details on our pricing page.
Conclusion: When to choose DevStack
DevStack differentiates itself from other CDE products through:
- Simple transition to using DevStack CDEs, which requires little change in developer’s ways of working,
- Flexibility in deployment models of the software that is developed on the CDEs, with support for heavy-duty, non-containerised, and other non-standard software,
- Flexible hosting options with transparent pricing which make DevStack affordable for software projects with medium to high and/or special resource requirements.
As a consequence, DevStack is most suitable for existing software projects with
- medium to large development teams which benefit from smooth and effortless transition,
- complex or non-standard deployments which cannot easily be deployed into a single container, or as multiple containers into a Kubernetes cluster,
- medium to high resource requirements, which can become prohibitively expensive with the pricing models of SaaS CDEs.
