Cloudomation DevStack:
The GCP Workstations Alternative

Google Workstations

Google Workstations are pretty standard container-based CDEs. Workstations run in a Google Cloud compute cluster. Each workstations is a seperate VM in which a single Workstation container is deployed.

Workstations are built from a container image. If and where this container image is build is up to the user, though there is documentations to support users on how to set this up. Nevertheless, building the container from a configuration file is not part of the Google Workstations CDE offering.

Additional customization, such as the machine type to be used, is done via the Google Cloud console web interface or via the Google Cloud API or CLI. The configuration is stored in a proprietary, but fairly standard and simple configuration format called WorkstationsConfig.json.

Curiously, users will quickly encounter a “nested virtualization” option, which allows users to deploy VMs within their workstation container. Google mentions in its documentation that this comes with severe performance penalties of 10% or more. No wonder: You would have a VM that runs a Docker container which emulates running of another VM inside the container. That’s a few layers too many to provide sensible performance or experience.

As customary for Google products, the documentation is very good and there are a large number of examples and templates available.

Like all CDE products from cloud infrastructrue providers, Google Workstations are only available in Google Cloud.

Google Workstations are best for:

• Organisations that already use Google Cloud to run their application in production
• Organisations that already use other Google Cloud products in their development processes, such as Google Cloud Build and the Google container registry
• Organisations that have people with experience and knowledge of Google Cloud, who provide workstation configurations as a service to developers

Cloudomation DevStack

With Cloudomation, the standard deployment is based on fully-fledged VMs. Developers can therefore deploy almost anything on the CDE. They can run multiple containers – one of which can optionally be a development container – or deploy software directly on the VM. If required, a complete Kubernetes cluster or Kubernetes development tools such as minikube or kind can also run on the CDE.

The source code can be synchronised with the developers’ local computer so it’s possibble to work locally with any IDE. Optionally, ssh-enabled IDEs such as VS Code or JetBrains IDEs can also be used, with the IDE backend running on the CDE. Developers have full SSH access to the CDE.

This setup is very similar to local development environments. When working with such a CDE, the developers’ workflows hardly need to be adapted.

Cloudomation is suitable for:

• Development teams that work on complex software and need to deploy it to validate code changes.
• Development teams that want a high degree of flexibility (working with individually favored developer tools, full access to VM by default, access to the Cloudomation Engine automation platform)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. 
  By allowing developers to keep their local tools and workflows, and enabling interaction with the CDE through the terminal (in addition to a web interface), developers can continue to work very similarly to how they would work if their software was deployed locally. Switching to using a CDE requires no change to developer’s workflows and tools.
   

  Cloudomation 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