GitHub Codespaces, Coder, and Enterprise Customers
When GitHub announced that Codespaces is free for individuals, it felt like Christmas. I had applied 3+ times to the beta program using my Gmail account and was never accepted.
Here are my initial thoughts:
- I was in a web VS Code in seconds, pretty fun
- Pretty obvious a Git provider wrote this solution - it's all about the repository i.e., 1 codespace, 1 repo - there's probably nothing stopping you from cloning more repos, but again, it's all about the repo
- Surprisingly lots of clicks, a proprietary extension, and pop-ups to get to a local VS Code connected to Codespaces
- Creating a branch took like 20+ seconds to complete
- Limited compute options
However, I didn't write this blog post to talk about the user experience of GitHub Codespaces. Rather I want to share what I see in Coder's enterprise customers and their requirements for remote development.
Coder has enterprise customers using GitHub, usually GitHub Enterprise "GHE", their self-hosted product, GitHub Enterprise Cloud "GEC," a single-tenant cloud offering, or GitHub Pro and Team. Codespaces works today with GEC, Pro, and Team but is not currently an option for GHE customers.
If enterprise customers use self-hosted GitHub, and need a remote development platform, Coder continues to be the first call to explore and investigate remote development since Codespaces is not an option.
Multiple Git Providers and Migrations
While GitHub is the provider of choice for individuals, we see a different story in the enterprise. We often see GitLab in many enterprise accounts, particularly in industries like financial services, insurance, and the public sector. Bitbucket is common in our large enterprise customers too. We see many enterprises in the process of migrating between git providers. With a remote development platform tied to a specific git provider, you lose the flexibility of offering the same remote development experience across providers. Let's also not forget Azure DevOps and Coder has many customers who use ADO for source control.
The takeaway is Coder's enterprise customers use many Git providers, sometimes multiple providers in the same enterprise. Since Coder integrates with all of them, we are a popular selection.
Without exception, all of our enterprise customers are in the process of migrating workloads to one or more public cloud providers. This means some developers are on the new public clouds, while others are restricted to on-premises networks. We often notice this where Coder's Kubernetes-based control plane is on AWS, Azure, or Google Cloud for some developers, and deployed again within IBM Red Hat OpenShift, SUSE Rancher, or Broadcom VMware Tanzu for other developers.
Again, the takeaway is that Coder can be deployed on (and across) any public cloud or on-premises, so one remote development platform for all developers in an enterprise.
Although Coder does not build an IDE, many enterprises choose Coder due to the extensive IDE support. Yes, Coder maintains a web-based fork of VS Code called code-server with over 57k GitHub stars. However, we find teams use a mix of IDEs, some are still native thick clients and others web-based. Coder can support all of these IDEs, often both local with SSH and web, or even VNC and RDP. GitHub Codespaces is owned by Microsoft so there is an obvious synergy to promote Microsoft VS Code in Codespaces. Recently, GitHub announced support for JetBrains, which is nice to see, but at the end of the day, GitHub and Microsoft are VS Code-centric organizations.
Coder is also selected because of our JetBrains local and web IDE support. The big news in 2022 is JetBrains announced that they are sunsetting their web IDE (aka Projector) and encouraging usage of Gateway either with the Gateway client or through specific locally-installed JetBrains IDEs.
The final takeaway is that Coder is IDE-agnostic. For our enterprise customers, supporting the widest mix of IDEs means meeting all of their developer requirements.