Everything As Code: Workspaces vs Templates
Workspaces and templates follow the “everything as code” paradigm. A template is the code that declares a development environment, and workspaces are the instantiation of development environments.
In a previous CDE 101 post, we learned what a cloud development environment is. Now we can cover how a platform engineering team defines a development environment for developers to work from.
In a conventional setup, developers have full reign over their development environment. That’s certainly flexible, but in large enterprise organizations this results in costly, frustrating inconsistencies that slow down development and tie up the IT team needlessly with one-off support problems.
A CDE uses workspaces and templates to avoid these problems while still giving developers a productive, useful environment. A template declares what’s in a development environment and how its parts interact. Developers consume the template to create their own workspace. A workspace gives developers access to a development environment that’s ready to use. Developers don’t need to provision resources, install build tools, hunt for missing dependencies, or even pull code from repos. The template declares how to do all this for them ahead of time.
Iterative collaboration
One of the advantages of dividing development environments into workspaces and templates is the separation of concerns:
- The platform engineering team defines development environments with templates.
- Developers consume these templates to create their own workspaces.
In the early phases of adopting a CDE, the platform team is typically the only gatekeeper for templates. On the surface this looks like a rigid delineation of responsibilities. In fact it allows both flexibility and maintainability as the organization’s CDE adoption matures. Developers can customize their workspaces, but within guardrails defined by the platform team to avoid the problems of conventional setups.
The workspace-template lifecycle ends up being a collaborative, iterative one. Developers suggest improvements to the platform engineering team and the platform team applies true engineering processes to implement these improvements. Developers get what they need while the platform engineering team ensures consistency, stability, security, and whatever other requirements the enterprise needs.
For even greater flexibility, the platform team might choose to expose the template repository to developers. Developers could edit templates themselves, or develop entirely new templates, then make pull requests. The platform team decides which changes to test, accept, and publish on the CDE.
Templates are code
To manage templates and workspaces, a CDE follows the “everything as code” approach. It’s a powerful paradigm that, not surprisingly, suits development environments well. The template declares all the details of a complete environment so that the developer doesn’t have to. The CDE then uses the template to create workspaces that are ready to use.
This brings benefits that are difficult, if not impossible, to achieve with a conventional setup:
Consistency and repeatability: The CDE precisely follows the template to stand up and tear down identical workspaces for developers, every time.
Auditability: Templates are human-readable, making them reviewable, editable, and versionable.
Reliability, performance, and security: The platform team can apply its own processes to test a template before making it available to developers. If a problem is discovered with a freshly-revised template, they can always revert to the older version.
Flexibility: A template gives the platform engineering team the flexibility to consolidate or spread out developer infrastructure to suit the situation.
Workspaces are consistent but still flexible
Each developer accesses their environment through a workspace. In the CDE, the developer chooses a template to create their own workspace. The CDE ensures that each of the parts declared in the template are provisioned, running, and securely interconnected. Each developer gets their own workspace and all workspaces are identical for the whole team. That’s a big advantage over conventional development environments.
But developers need to adapt their environments to the project or their own preferences, which is crucial for developer experience and productivity. To support this, a CDE offers a few choices. After all, CDEs promise the power and flexibility of the cloud.
Template parameters, declared by the platform team, let the developer customize a workspace when starting it. This is useful for projects or tasks where a developer needs to adjust something specific about the environment, like choosing the number of CPU cores or specific repos. Because parameters are defined in the template, the platform team can ensure that these customizations don’t impair the environment’s stability, performance, or security.
Or the platform team can use the CDE access control features to make some templates available to specific developers or teams. For example, developers in a machine learning team might have access to templates that provision extra GPU capacity.
Flexibility in the cloud
A template declares workspaces. The platform team codes and maintains the templates, while developers use them to create their own workspaces. No matter how many developers use the template, all the workspaces start in the same state. This repeatability doesn’t limit developer experience, though. The “everything-as-code” approach, as well as the capabilities of the template itself, give the platform team and developers choices for taking advantage of the cloud.
Subscribe to our Newsletter
Want to stay up to date on all things Coder? Subscribe to our monthly newsletter and be the first to know when we release new things!