Coder v2 - Lessons learned from v1, and OSS to Enterprise Editions
Coder's going through a growing up phase. An analogy is like high school or secondary school, where freshman and sophomores often are green or overly confident without experience. Coder is like a junior or senior, with 3 years of enterprise experience with the cognitive awareness of what works, doesn't work, and more importantly what the market needs, but without arrogance. That's experience.
What we learned
In late 2019, Coder released a remote development environment platform where development environments were Kubernetes pods based on images that team leads built with the frameworks and IDEs that developers needed. While there was some installation friction if an enterprise did not have Kubernetes experience, Coder v1 basically worked perfectly once installed. You point it at a container registry and a development environment magically built and developers and data scientists could be in a local or web IDE in minutes and coding. Productivity, environment consistency, and source code and data safety achieved. Information security teams were happy since Coder made development environment isolation a core principle, and enforced isolation with network policies which contrasted with some competitors who encouraged features like sharing environments with a link which is a big no-no in large enterprises.
However, with simplicity Coder made opinions and design decisions that impacted flexibility and configuration. Everything was a Kubernetes pod. What if a VM was preferred? Thank you, drive through. We couldn't help you.
What if a container team wanted to mount shared volumes, or apply annotations or let admission controllers and mutating webhooks do some enterprise magic, Coder got in the way. It was doable but required configuration.
Junior year, introducing Coder v2
I lead the sales and customer success organization at Coder and we noticed these patterns. Feedback to our co-founders led to a conscious and monumental design decision, that Coder needed a v2 with an innovative approach to address the limitations that only Coder could see since we have success with enterprises that chose Coder for their remote development environment strategy.
Freshmen, Sophomores, 5th Year Seniors and Remote Development
It is interesting to me to watch new offerings like Google's Cloud Workstations, Microsoft's Dev Box and GitHub's Codespaces - a.ka. freshmen and sophomores, which are innovations in their own right, but are basically purpose-built for some underlying pre-existing technology that fuels large revenue contributions. GitLab, in its transparency mode, maintains a strategy for remote development and their Web IDE.
Some examples are Codespaces drives GitHub git service usage and Microsoft Azure consumption, Cloud Workstations drive Google Cloud consumption, or Dev Box drives Microsoft Azure consumption.
I guess we can round out this analogy with Red Hat OpenShift Dev Spaces (formerly known as Red Hat CodeReady Workspaces) is the 5th year senior who has been around the longest, which does not mean the market leader, and is bundled in their OpenShift Kubernetes platform.
The solutions may have some early adopters but probably do not have real deployment experience where developer infrastructure leadership are standardizing on them, since each has technological compromises that prevent them from enterprise rollout. e.g., Does an entire enterprise use only GitHub SaaS, or only Azure or Google Cloud compute, or only use the VS Code IDE? Probably not.
Back to Coder v2 and junior year
So Coder designed v2 with a few guiding principles that are both differentiating and value-add to enterprises:
v2 Innovation #1: Abstracting Dev Environment Compute
By abstracting compute from development environments, enterprises can make these environments either a Kubernetes pod, a container on a Docker host, or a traditional and powerful VM. Development environment OS choice and lighter-weight compute platforms became a possibility.
v2 Innovation #2: 100% Control over the Kubernetes pod spec
In v2, enterprise container teams now have complete control over the Kubernetes pod spec. Mounting multiple volumes, 1 to N containers, annotation and admission control flexibility are possible with minimal configuration.
v2 Innovation #3: Dev Environments as Code - via Terraform
The first two innovations are possible because v2 ships with Terraform OSS. Dev environments are specified in Terraform code and provisioned with Terraform runners. v2 enterprise paid features allow enterprises to deploy these runners in isolated networks and scale out to support large developer populations.
I equate these three v2 innovations to Coder crossing the chasm, historically between DevOps/Platform Engineering infrastructure teams and developers. Infrastructure can now more easily support developers, and developers get a reliable, scalable platform to do their daily coding workflow.
v2 OSS and the Business Value of v2 Enterprise
When we set out to build v2, we had a vision that v2 can be organically discovered and used across individual users, students, small, medium to large enterprises. This is how our code-server OSS project (VS Code in a browser) started and continues to grow today with over 57k GitHub stars.
So what do you open-source? Well, our guiding principle was and is quite simple: any remote development functionality that is required for a developer, data engineer, or data scientist's flow, should be in v2 OSS.
Define a template (the configuration-as-code in Terraform that maps out a development environment), build a development environment (we call them workspaces), perform git operations like clone a repo and push a branch, open any IDE, either locally with SSH or in a browser, port forward to a local machine or in a browser to view your application - these are sample actions that developers need and are in v2 OSS.
Then what do you close-source and require a fee-based license? Well, our counter-weight guiding principle is simple as well: Functionality that enables enterprises' developer infrastructure, platform engineering, DevOps, compliance, and information security departments, are available in v2 Enterprise, Coder's fee-based licensed product offering.
These enterprise departments manage developers at scale which drives the expected benefits of remote development environments like contributing code on day 1, securing intellectual property like source code and sensitive data, auditing developer and Coder administrator activity, making developers more productive and staying in flow, and enforcing governance and standards with consistent, reproducible development environments.
Here are explanations of some of the major v2 Enterprise features:
High Availability
v2 OSS is great for small teams, but Coder can only scale up to the compute available on the VM it's running on. With HA, user, build, workspace, and API load can be shared across multiple coderd binaries/pods. Large enterprises require this feature to deliver a highly available and scalable remote development platform to their developers.
Workspace Quotas
When workspaces move to an enterprise's on-premises or cloud infrastructure, hardware and cloud costs can dramatically increase as compute is moved off laptops. Administrators define costs at the template-level, and user allowances at the group-level. At the time of a workspace build, Coder checks if the workspace compute request exceeds the user's total allowances and prevents the build.
Groups
Consistent development environments and security controls - requires groups. Users are assigned to groups, and templates are permissioned to specific groups, thus enforcing strict controls over what workspace types people can build. This also protects compute costs by preventing users from creating workspaces that they are not authorized to build.
Browser-Only Mode
Regulated industries like financial services and the public sector often do not allow SSH for various security reasons. This enterprise feature lets administrators disable SSH thus preventing users from connecting locally installed IDEs and local terminal sessions to Coder, which may have a higher exfiltration risk. Web IDEs like code-server, Jupyter, RDP, and VNC are still available.
Audit Logging
Large enterprises need to demonstrate controls over platforms like Coder. Audit logging captures all actions within Coder for both developers and administrators.
SCIM
SCIM is an open standard for automatically provisioning and de-provisioning user identities. This enterprise feature lets organizations make better utilization of their Coder license spend by suspending users no longer in the enterprise's SSO.
Isolated Runners
Enterprises have isolated networks for certain developers. Instead of installing multiple deployments of Coder in each enclave, isolated runners aka external provisioner daemons, can start, securely building workspaces, while still communicating with the primary Coder control plane outside the enclaves.
Support
OSS users are only entitled to docs and best-effort GitHub issues, Discord, and Slack community support. Enterprises in a potential revenue-event sales cycle with Coder, receive support on OSS and enterprise features. This would continue if an enterprise enters into a commercial arrangement with Coder.
In summary, Coder v2 OSS gives individuals and enterprises the ability to install, deploy, and benefit from remote development environments with no road block or interaction with Coder's sales and support organization. This unlocks velocity and time-to-value.
As teams and enterprises want to support more developers with centralized security and governance controls, they can try out and upgrade to v2 Enterprise.
Both v2 OSS and Enterprise are supported in our Discord and Slack channels or GitHub Issues.
Feel free to try out Coder v2's OSS or contact sales for a demo or a v2 Enterprise trial license.
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!
