A Platform Team’s pocket guide to Cloud Development Environments

Talia Moyal Head of Outbound Product at Gitpod

Mar 14, 2024

Imagine you have a magic box of Legos that follows you anywhere. Whenever you feel like building something, you reach into that box and everything you need is readily available for you. You can build the Millennium Falcon or a bright blue dragon – and you never have to think about which pieces to gather to make that possible.

That’s a cloud development environment (CDE). It’s your ever-ready box of Legos for creating software. When inspiration hits, a developer can just start building.

Over the past year, we’ve seen the term CDE show up more and more. First from us,  then from Kent Beck in his discussion on taming development environment complexity, then from Gartner as they introduced it as an official category in their 2023 Emerging Technologies HypeCycle, and then from one of our favorite writers, the Pragmatic Engineer (not sponsored), to name a few.

As CDEs rise in popularity, they inspire discussions about their use: When should you use them? What do they replace? How to evaluate a great solution? How can you integrate them effectively, especially if you’re part of a platform team? This post was written for platform teams that want to gain clarity on how CDEs can help them be more successful, and for anyone else who just wants to learn the basics of CDEs.

What’s a CDE?

CDEs are on-demand development environments pre-configured with the tools, libraries and dependencies needed to write, test and review code. They help shift a platform team’s sphere of influence to the left, enabling them to gain control over development environments.

Control can be a scary word for many developers we speak to. This is because it is often associated with a lack of flexibility or extensibility, and is generally linked to a poor developer experience. However, in the case of CDEs, this perception does not hold true. CDEs are designed to facilitate better collaboration between developers, as well as between developers and platform teams. Good platform teams understand that they need to influence the tools developers use to be successful; great platform teams collaborate with developers on those tools, making them the obvious choice for both.

We’ll use Gitpod as the example for a CDE in this post.

What makes up a CDE

CDEs are your development environments. In Gitpod’s case, we call these workspaces.

Workspaces give you the same capabilities as your Linux machine – which is why we like to say, anything you can do on Linux, you can do on Gitpod.

In Gitpod, a workspace is accessible through browser or, desktop editors, or command shell via SSH, using a PC, laptop, tablet, or phone. Workspaces are based on Linux and can be automated through configuration of a .gitpod.ymlor workspace image like Docker. In Gitpod, workspaces come pre-installed with Docker, Nix, Go, Java, Node.js, C/C++, Python, Ruby, Rust, Clojure, as well as tools like Homebrew, Tailscale, Nginx and many more. These images can be customized to fit the needs of your setup and can be globally applied to all of your developers workspaces.

Workspaces can be fully customizable on both an individual and organizational level. Do you have specific extensions you’d like to use for all your projects? Install it via OpenVSX marketplace and add it to the .gitpod.yml file or extend your workspaces further with dotfiles to truly make them your own.

Workspaces are ephemeral and fully-isolated. Most users will use a workspace per task, and have multiple workspaces running in parallel.

CDEs are not IDEs or cloud IDEs

A common misconception we encounter when discussing CDEs is their confusion with an IDE and cloud IDEs. An IDE, or integrated development environment, serves as the interface where you write code. A cloud IDE is a proprietary code editoring in the browser, serving functions like compiling, debugging and GUI building.

CDEs, on the other hand, go beyond including an integration with an IDE, along with all the tools your organization needs to write software more efficiently. Gitpod is integrated with all common IDE and editor providers including VS Code, IntelliJ, PyCharm and even your terminal.

What do CDEs solve for?

Containerization, microservices, globally distributed workforces, serverless computing, AI, are all part of a much longer list of trends that have contributed to the complexities engineering organizations have faced over the last five to ten years.

Containerization and microservice architecture provides teams with a way to encapsulate applications in self-contained environments. This packaging format ensures consistency across different environments, simplifies dependency management, and enhances scalability. However, it requires a new set of skills and expertise, especially with complex orchestration tools like Kubernetes. Containers also rarely run on their own and often require dependencies to function properly. While orchestrators like Kubernetes support production environments, our development environments are becoming increasingly complex.

Globally distributed workforces have expanded the scope of platform teams’ responsibilities by necessitating support of global, distributed systems and teams. This requires 24/7 operational capabilities, compliance with regional regulations, and facilitating collaboration across distributed teams. While globalization offers the opportunity to tap into diverse markets and talent pools, it also requires platform teams to implement more flexible, inclusive, and adaptive communication and project management practices.

This is where CDEs come in. Doing platform engineering well means focusing on developer experience. Without developers utilizing platform capabilities, it becomes impossible for platform teams to bring about the benefits they aim to achieve across an engineering organization, such as improved reliability, security, and standardization.

CDEs commonly address pain points for three key categories: standardization, extensibility and security:

• Standardization establishes guardrails to create consistency, reproducibility and stability in development environments.
• Extensibility involves using tools that work out-of-the-box but can be customized to your existing platform.
• Security focuses on helping developers make the best security decisions by default and protecting your organization’s most sensitive assets.

Benefits of CDEs for platform teams

CDEs significantly simplify the lives of platform teams. They address key challenges across three categories:

Standardization

• ‘Works on my machine’ problems: CDEs remove discrepancies between development environment setups, reducing troubleshooting time.
• Onboarding time: pre-configured environments simplify the onboarding process for new developers or contractors by eliminating lengthy or complex setup processes, decreasing the risk of configuration errors.
• Environment drift: over time, individual development environments may diverge from each other and production, leading to unexpected behaviors or bugs. CDEs mitigate this drift through consistent configurations and global application of changes to environments.
• Dependency management: CDEs ensure all developers use the same versions of tools and libraries, removing a need to manually update and check that environments are up-to-date.
• Context-switching: CDEs eliminate the need to reconfigure environments each time your developers switch context, prompting better inner sourcing and improved development velocity.

Extensibility

• Choice of IDE and editor - Developers get to choose their editor when working with CDEs, whether that’s IntelliJ, VS Code, or a terminal. Developers can also customize by using Dotfiles to install personalized tools for their development flow.
• Start environments without breaking flow - Launch a CDE from the context of what you’re currently working on, whether that’s straight on a pull request you’re reviewing, from an internal developer portal, or direct from your command line interface.
• Integrate with your platform: CDEs can be customized to fit the needs of your organization, through specific integrations and plug-ins to internal developer portals like Backstage, directly inside your IDEs, or launched from automation like CI/CD.
• Compute power to match the task: CDEs offer scalable resources on demand, such as CPU, memory, and storage, enabling teams to undertake a broad range of tasks like running large test suites, microservices, or data processing without local machine limitations.
• Facilitates collaborative development: teams can easily share in-progress work, facilitating real-time feedback.

Security

• Uniform security standards: CDEs enable consistent application of security protocols and configurations across all development environments, significantly reducing vulnerabilities and enhancing overall security posture.
• Protects sensitive data: by centralizing sensitive information such as API keys or credentials, the risk of data breaches due to compromised local machines is significantly minimized.
• Centralized security management: organizations can enforce and manage security policies more effectively across all development spaces, closing gaps in security practices..
• Timely security updates: CDEs facilitate automatic and immediate application of the latest security patches across development environments and their dependencies, ensuring tools and systems are protected against known vulnerabilities without manual intervention.
• Enhanced security for remote work: CDEs are designed to securely support distributed teams by providing temporary access tokens and integration with SSO for secure login to resources.

Two things to look out for when evaluating a CDE

Deployment model

CDEs are non-trivial applications to build from scratch, and when self-managed, they can be difficult to operate. Because of this, always consider the deployment model and the resources you’d like to allocate to operating CDEs when purchasing a tool. There are three common deployment models to choose from:

• Self-hosted and self-managed: self-hosted in your organization’s cloud infrastructure, operationally managed by your team.
• Self-hosted and vendor-managed: self-hosted in your organization’s cloud infrastructure, operationally managed by a vendor.
• Vendor-hosted, vendor-managed: hosted in a vendor’s cloud infrastructure, as well as operationally managed by the vendor.

Any organization with stringent security requirements will opt for a self-hosted solution. However, it’s important to note that self-hosting and self-managing will come with day two challenges such as building SCM and SSO integrations, performance optimizations and caching, cost management, etc. Ultimately, time spent managing new infrastructure projects is time that could be invested in other critical platform initiatives.

Developer Experience

Platform tools are only effective when they get used, and developers are very sensitive to changes in their workflow. Convincing developers to change their entire editor setups, or custom keybindings and themes, is like teaching a cat to swim. Developer satisfaction is crucial for adoption and easy to overlook, especially when evaluating CDE products. Make sure you look for support for your developer’s favorite editors, as well as other supporting integrations like CLIs, and APIs that integrate into existing platform capabilities like internal developer portals (Backstage, Cortex, Port, etc.).

CDEs and Artificial Intelligence

More recently, we’ve received questions regarding CDEs as a potential replacement for coding assistants, especially from platform teams with mandates around developer productivity. CDEs and coding assistants are fundamentally not the same. A coding assistant is a tool that supports developers by automating routine tasks, suggesting code completions, identifying errors and providing recommendations to improve code quality. These assistants leverage large language models (LLMs) to understand the context of what’s being written.

CDEs are your entire development environment. That said, CDEs can integrate with coding assistants through their editors. With Gitpod, you can use your IDE to leverage tools like GitHub Copilot, Codium, AWS CodeWhisperer, Cody, etc.

CDEs and Virtual Desktop Infrastructure

Virtual Desktop Infrastructure (VDI) is a form of virtualization that enables remote access to a full desktop environment. VDIs host the operating system, applications and data from a desktop environment on a virtual machine and stream them to end-users over a network.

VDIs were not built for development but have been pigeonholed into being used for development because of their popular adoption from companies in regulated verticals like telco, health care, financial services etc. VDIs were originally being adopted for their security benefits, but as we discussed the emerging trends over the last few years that have created complexity in development, VDIs have not been able to stay-up-to-date and enable any sort of a developer experience.

Our recommendation is always to replace your VDI setup as long as you’re not requiring your developers to only access their applications via a remote desktop setup. CDEs are able to check the box for most security requirements that VDIs fulfill. In the case that you are requiring developers to access applications via remote desktop access, we recommend using VDIs and CDEs together.

Try CDEs free, today

If these benefits resonate with the goals of your team the easiest next step is to try a CDE for free. Many products have free trials available, including Gitpod. Once ready to make a purchase, we’ve created an ROI calculator to simplify understanding the financial benefits of using a CDE. It’s a great tool for demonstrating CDE value to engineering leadership.