Why developer-optimized cloud development environments outperform operation-centric templates

Lou Bichard Product Manager at Gitpod

May 21, 2024

In 2022, we announced Gitpod Enterprise. Our managed, single-tenant, self-hosted offering of Gitpod. This approach gives our customers all the value of a cloud development environment with zero of the operational overhead that comes with self-hosting (and self-managing).

This change in our deployment approach frees up operators from having another cluster to water, feed and keep alive. You can think of Gitpod Enterprise as: ’Having Gitpod on-call to ensure system reliability, quality and security - instead of your team.’ Because, that’s exactly what it is.

However, the Gitpod Enterprise architecture also comes with significant benefits to developer experience that come alongside the lower operational burden. We call this approach a developer-optimized approach to cloud development environments. The two significant advantages are:

1. Governance and ownership - Developer-optimized cloud development environments carefully balance giving centralized ownership and control with developer empowerment and autonomy.
2. Performance and security - Pushing infrastructure concerns into the platform enables advanced performance optimization and security features like ephemerality and prebuilds.

The above optimizations are virtually impossible with the alternative, an operation-centric and template-based cloud development environment, whether that’s built or bought. This article explains the differences and what you need to know.

Comparing developer-optimized and operation-centric template configuration approaches

A cloud development environment (CDE) is a platform allowing for the running of development environments in the cloud.

A CDE relies on some form of environment specification to define what the development environment consists of.

Those configurations require decisions on the following:

1. Configurations are specified in some format
2. Configurations are stored in some location
3. Configurations are exposed to developers

How you choose to configure your CDE, and your approach can have a huge impact on the success of the project.

Let’s review the different approaches:

Operation-centric cloud development environments

First, let’s look at an operation-centric templating approach, using Terraform. This is a common approach used for quick early iterations of a CDE.

The following is an example of a simple EC2 based CDE defined in Terraform that takes input parameters to the template such as:

• The developers git credentials
• The workspace size
• The cloud region
• Networking concerns

A developer would provide these parameters into the template, and use the template to deploy, and manage their environment. This template could be behind a self-service interface, or provided to developers directly as source.

module "vscode-ec2-server" {
  source  = "github/vscode-ec2-server"
  domain_name          = "ide.mydomain.com"
  email_address        = "email@mydomain.com"
  github_username      = "kumquat"
  hostname             = "kumquat-dev-environment-one"
  instance_size        = "t3.small"
  vpc_id               = "vpc-01234567890abcdef"
  oauth2_client_id     = var.oauth2_client_id
  oauth2_client_secret = var.oauth2_client_secret
  oauth2_provider      = "google"
  region               = "us-east-1"
  route53_zone_id      = "Z23ABC4XYZL05B"
  storage_size         = 20
  username             = "kumquat"
}

Caption: An example template-based definition using Terraform

When provisioned, a developer could then SSH into the VM and configure their tools. Most operations-optimized approaches like this tend to focus more on the provisioning of the infrastructure than setting up the application. In the example you can see there is no information on how to start the application that is to be developed, where it lives, and the steps required to install packages to ensure the environment runs properly.

Because of the way the infrastructure is provisioned, there is no way to benefit from shared caching, and developers are likely to be incentivized to keep these environments running due to the investment in time to set them up. This type of environment is much more static, than ephemeral. Being static also has implications for cost, as the environment is “always on”.

Aside from the technical limitations, critically these templates are often stored in a separate repository, away from the application code that will run on the provisioned environment infrastructure. The template is typically owned by a central team, not the application developers themselves. A developer using this type of infrastructure template would also then be responsible for the lifecycle and cleanup of the development environment that they provision.

Developer-optimized cloud development environments

Let’s turn our attention to a developer-optimized cloud development environment configuration approach, this configuration format is the one used by Gitpod.

yml

image: .gitpod.Dockerfile
tasks:
    - name: frontend
      init: npm install
      command: npm start

Caption: An example git-based template using the .gitpod.yml

This configuration points to a Dockerfile including the necessary tools for the application, as well as instructions on how to start the application.

You’ll notice the example above is focused on application-level configuration, than low-level infrastructure concerns like networking and wiring together git credentials. That’s because much of the infrastructure concerns are now pushed down into the platform itself. Aspects of the cloud development environment like starting, and stopping the environment, authenticating with git, the region of deployment, etc are all handled by the platform itself.

With this approach, you don’t need a central team to manage template updates. Governance is handled at the platform level, decoupling governance concerns from the template itself. Developers are also shielded from complexity, and the ability to make accidental mistakes to development environment templates are reduced, without relying on ticketing and central teams.

Now that we’ve outlined these two approaches, we can look at the main challenges for each configuration approach, starting with governance.

Operation-centric and template-based cloud development environments create bottlenecks and hinder self-service

The major downfall of the operation-centric approach is the creation of bottlenecks. Modern platform teams seek to reduce the cases where developers are forced to reach out to a centralized team, or raise a ticket to create changes.

Caption: How bottlenecking occurs with an operation-centric approach

It’s not that developers don’t want to self-serve and unblock themselves with this approach, it’s that the approach makes it so that they can’t. Why? Because

1. Developers rarely have a deep enough understanding (or access) to a complex enterprise cloud estate.
2. Operation-centric configurations are commonly written using tools that developers are unfamiliar with, such as terraform.
3. Changes are hard to validate given how much infrastructure is defined in the template that developers are unfamiliar with.
4. Debugging is more challenging as it’s common to get infrastructure related errors that are challenging to debug.

When taking an developer-optimized approach, configurations are stored in the repository alongside the developers application code. Therefore, changes to the application itself, such as updating an application-level dependency are then simultaneously reflected in the development environment definition that is also inside the same pull request or changeset. In Gitpod, validating a configuration is as simple as running gp validate to build the development environment docker image, and run the related developer-optimized definition.

Developer-optimized environments enable advanced optimizations like prebuilds and ephemerality

It’s not only the structural, ownership and governance challenges that operation-centric cloud development environments bring, but there are features of the developer-optimized approach that are virtually impossible to support for operation-centric architectures. That includes providing features such as: supporting prebuilds, and ephemeral development environments.

Prebuilds are an optimization to ensure that no newly started environment needs to download any new packages. Rather than starting the environment in the “foreground” when a developer requests an environment, environments can be prebuilt in the background into an image that is cached across the platform nodes, and is hot as soon as a new environment request comes in.

Ephemerality is the feature of a cloud development environment that allows a developer to start a new environment for every task, as opposed to having a single environment that they mutate and update over time. The biggest advantage for ephemerality is the impact on security. Short lived ephemeral environments have a smaller blast radius, and more limited security scope.

Caption: With developer-optimized, developers manage their own configurations, and optimizations are made by the shared platform.

Building a feature like Prebuilds, or ephemerality into an operation-centric cloud development environment is almost impossible as all environments have separate configuration definitions and no common platform. The developer-optimized approach can achieve these features by keeping these concerns at the platform level, not at the template level.

For instance, Gitpod Prebuilds rely on image caching architecture that is applied on top of Gitpod’s orchestration. This caching would be very difficult to achieve using disparate templates, or using the EC2 VM based templates shared above.

Developer-optimized environments are the future

As the technology industry moves away from centralized operations teams that monopolize control over technology, and instead appropriately empower their developers, you can see the benefits of developer-optimized environments.

The developer-optimized pattern empowers developers to manage their own configurations, avoiding bottlenecks on central teams, and making powerful features like prebuilds and ephemerality possible.

To learn more, try Gitpod for 50 hours free per month to really experience a developer-optimized cloud development environment.