Decisionmaker's Guide to Cloud Workstations

Companies are successfully increasing developer productivity and saving on costs by shifting to remote development environments and workspaces. This guide will examine three common workspace solutions, their trade-offs, and points of concerns that decisionmakers should keep in mind.

Before we begin, we want to clarify the differences between a Cloud Development Environment and a Cloud Development Workspace:

• Cloud Development Environments are usually spun up once a developer is ready to test their changes and share their work. These environments aim to be production-like, are typically tied to Pull Requests, and are created as part of the continuous integration (CI) process.

• Cloud Development Workspaces enable developers to work in a remote environment. These are useful for setting up managed, consistent environments, which saves developers time from debugging their local environment. Additionally, large or complicated applications can benefit from having predictable resources, and companies can save money when pre-committing to purchasing extra powerful developer workstations. Finally, in cases where the source code is considered sensitive, these workstations allow developers to work without having a full copy of their source code present locally.

Cloud Development Environments

Cloud Development Environments are a mature part of the continuous integration and continuous deployment (CI/CD) process. These are often spun up by deploying a copy of the app, service, or environment in the CI/CD pipeline to Kubernetes for testing a developer’s application in a production-like environment, and destroyed when no longer needed.

This comes with two noteworthy challenges:

• Providing a fully functional environment for applications with many dependencies: We often solve this with ingresses or a proxy. This allows services to be consistently named which helps simplify generated configuration, and enables backend services can be chosen more easily.

• Securing the application in its environment: Just because it’s a testing environment doesn’t make securing it any less important. However, this is often still the testing phase of an application’s lifecycle; it might not have had access control built into it yet! Instead, many organizations resort to making these environments completely internal, which hinders developers who may now need to be on a VPN or in an office to work effectively. Something like Pomerium can help with both of these issues by providing programmatically generated routes (for access) and robust access control in a reverse proxy.

Cloud Development Workspaces

Cloud Development Workspaces are a much newer construct gaining traction as applications are getting more complicated and remote work is becoming an industry norm. There are many platforms, vendors and tools in this space, but they can be broken down into roughly three categories:

• Managed Workstations

• Environment-as-Code platforms

• Remote Editor Servers

Managed Workstations

Common examples include Amazon Web Services and Google Cloud Platform.

Managed workstations are just what they sound like; compute instances managed by a cloud provider with extra abstraction and integrations. These are fully functional machines deployed with a consistent image. It can make it easy to preconfigure a machine, but involves administering an entire fleet of machines.

Pros:

• Automatic reaping of unused environments and reclaiming the resources

• Tightly integrated authentication with cloud provider

• Native support for private networking and cloud provider services

Cons:

• Each instance is a fully functional computer, limiting user actions if not deeply integrated into the cloud provider

• Perimeter-based security will often allow these instances to have unnecessary access internal services

Decisionmakers should note: Most organizations might be misled to consider these to be cheaper than purchasing an expensive laptop or workstation. While the upfront cost is cheaper, the ongoing costs will often equal a mid-spec Macbook after 3 years, and then the long-term costs of having purchased a laptop will probably be better in the long-run.

Environment-as-Code Platforms

A common example is coder.com.

Environment-as-Code Platforms are a relatively new way of providing remote developer workspaces. These platforms allow you to define what an environment looks like in code, and then deploy that in a consistent manner. These platforms run the environments in your infrastructure, with some offering a fully hosted solution (with caveats).

Pros:

• Administrators have full visibility into what environments exist and what resources they’re using, allowing for reaping of unused environments to reclaim their resources

• Less effort than managed compute workstations

• Easily spin up on-demand workspaces with multiple options

Cons:

• Requires upfront work to define the environment and maintain it, being a mostly “do it yourself” solution in order to tailor it to specific needs

Decisionmakers should note: The companies hosting these platforms will become part of the critical path for development, and their uptime may affect your developers’ ability to create new environments. Similarly, they’ll have privileged access to your environment or your codebase, which may provide an additional vector of attack and expose you to third-party breaches.

Remote Editor Servers

Common examples include Jetbrains IDE and Visual Studio Code.

Remote Editor Servers are a headless instance of a developer’s local editor. These editors offer great integration with their local counterparts including linters, debuggers and other plugins.

Pros:

• Combined with a consistent repeatable environment and managed auxiliary resources, the developer gets a familiar and performant development environment without taxing their laptop.

Cons:

• The initial setup is harder than managed workstations

• Maintenance required for the environments

• You may largely require your developers to be using the same Editor

Decisionmakers should note: This is the most “Do It Yourself” option, so time and labor costs might be higher when compared to the other options. The increased flexibility might mean you need more expertise to customize it into a useful environment.

Example Workspace Including Pomerium for Access Control

Here we’ll discuss how we’d setup a developer workspace for a Pomerium Developer. Organizations should never neglect to secure their workspaces because:

• Costs: Workspaces often utilize metered computing power, and no one likes unexpected computing bills because of bad actors

• Security: Aside from securing potentially sensitive IP, workspaces often have access and provide vectors of attack into other systems within the organization (due to application dependencies). Just because it’s a development environment does not mean it shouldn’t have production-grade security.

Below is a block diagram of the pieces.

The developers workflow would look like:

• Start the pomerium-cli pointed at the route to our development cluster

• Trigger instantiation of a dev workspace and note the subdomain it’s being started on

• Launch Visual Studio Code and attach to the running container

• Develop features and access their live environment with their normal credentials.

In this scenario Pomerium is facilitating a number of things. It authenticates that the user is a developer, and authorizes the creation of resources. Afterwards, Pomerium automatically configures routes and paths to create a consistent production-like interface regardless of the backing service.

This architecture enables downstream services to work with a developer’s workspace with minimal configuration changes. It also allows the developers workspace to be securely accessed both by the developer and any collaborators without worrying about exposing sensitive services to the internet.

Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds zero trust clientless connections to internal web apps and services without the need for a corporate VPN. The result is that Pomerium is:

• Easier to deploy, configure and maintain than a VPN because of its clientless access.

• Faster since it is tunnel-free and deployed where your apps and services are.

• Safer because every single action is verified before allowed to execute.

• Tailored to your organization’s needs by integrating all data for context-aware access.

Want to try? Follow our code-server guide and see how it works!

Final Tips for Decisionmakers Evaluating Cloud Workspaces

• Don’t lose track of developer and business needs. Cloud workstations are not a one-size-fits-all solution when enabling developers while enhancing security. It doesn’t have to be either-or.

• Keep an eye on costs. It is still best practice to structure out budgets and cost monitoring just as you would for any other service. Pay-as-you-go sounds enticing only because you haven’t seen everything that can be included, whereas flat fees offer better predictability. There should be a coined rule: flexible cost structures result in unexpected costs.

• Change is always a process of adaptation with growing pains. It’s very common for developers to be opinionated about their preferred dev environments, and may often have their own customized bespoke versions. Working with them to shift to a new system will have friction, so focus the teams on the net positives of working together in a cloud environment

• Supporting your developers will look different. DevOps support staff will likely need to learn different technologies to support a shift to cloud workstations, but will have much fewer one-off issues as you standardize environments. As an example, laptops are notoriously individualized, but with cloud workspaces they won’t have nearly an impact on developer productivity.

• Take a long view of your environment. It can be tempting to be excited by new tech or solve an immediate problem quickly. Any big change to your developers’ workspaces and workflows sustainable and desirable (beyond the immediate “if it works why change it?”). Be cautious of making frequent large changes, as adjustment fatigue can be a blocker for future changes.