Kyle Carberry

Co-founder and CTO

There are good reasons why IntelliJ IDEA is the go-to IDE for large Java and Kotlin teams. It was built from the ground up for Java development. Nobody else matches the intuitiveness and smoothness of IntelliJ IDEA’s contextual symbol searching and refactoring.

Until recently, that’s all developers expected. Today, cloud-based development is changing the playing field for enterprise development tools. That opens an opportunity to fill the needs of large Java teams who want more of the advantages of cloud-based development. 

Microsoft, the other big player, is showing signs of recognizing this opportunity for VS Code. They’re on the other side of the field with an IDE that’s built from the ground up to work in the cloud and a roster of promising Java partnerships on their team.

<h1>Why do Java developers want remote development?</h1>

A cloud-based development solution gives Java teams more capabilities. At Coder, we’ve seen large dev teams benefit the most from:

<ul>
<li>Shared indexing: Large Java projects use massive resources. A developer waits several minutes while their IDE generates an index for a project and its dozens, or even hundreds, of sub-projects. A <a href="https://www.jetbrains.com/help/idea/shared-indexes.html">shared index</a> leverages cloud storage to mitigate this issue.</li>
<li>Developer productivity: Developers can not only onboard faster, they can choose the tools they prefer while still using the same set up that their teammates are using.</li>
<li>Reduced resource usage: Our users have seen incredible drops in their cloud compute spending. Unlike on-prem hardware, you can spin cloud services on demand and shut them down when they’re idle.</li>
<li>Geography is not an obstacle: A remote dev team isn’t limited by their location. Cloud service providers cover the globe with their high-performance, low-latency infrastructure.</li>
<li>Reproducible setups: Set up complex configuration, dependencies, and test cases once so that the whole team can share.</li>
<li>Industry-standard security: Cloud providers have solved the challenges of providing their services securely. There’s no need to risk breaches by reinventing the security wheel.</li>
</ul>

Java developers who choose the familiarity and productivity of JetBrains’ tools are waiting for better integration of cloud development features. While JetBrains has been steadily improving its cloud-based offerings, their tools aren’t quite there yet. Some features are limited, like IntelliJ IDEA’s inability to open more than one remote window. Other features show promise, but are bulky or difficult to set up, like <a href="https://www.jetbrains.com/help/idea/shared-indexes.html">shared indexes</a> or running in secure enterprise networks.

There’s also <a href="https://www.jetbrains.com/fleet/">Fleet</a>. Still in public review, Fleet is a “next-generation” IDE that JetBrains is positioning to compete with VS Code. From Coder’s perspective, none of our customers have asked about it, so we still have no idea where it will eventually stand in the market.

On the other side, VS Code has a big head start in cloud-based development but less sophisticated Java support. Instead of focusing on a single programming language, Microsoft’s VS Code relies on a vibrant ecosystem of extensions and related infrastructure. Microsoft is starting to leverage this for Java. Look at VS Code extensions like <a href="https://marketplace.visualstudio.com/items?itemName=redhat.java">Red Hat&#39;s Language Support for Java</a>. What’s more interesting is Microsoft’s partnership with Oracle for the <a href="https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java">Oracle Java Platform Extension</a>.

<h1>Python and Android developers are already migrating</h1>

This might be history repeating. We’ve already seen the Python and Android developer communities make moves to the cloud. Microsoft appears to be under the same incentives to attract Java developers. It’s our understanding that Java is the largest slice of the cloud development pie.

<a href="https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-pylance">Pylance</a> is the Microsoft extension for VS Code that finally convinced many Python developers to move to VS Code. Pylance gives them both solid Python support and full-featured cloud-based development. 

The most popular IDE for Android development is Android Studio, based on IntelliJ IDEA. But Android Studio doesn’t support remote ssh connections. Consequently, many Android teams have switched to IntelliJ IDEA for better cloud development support. It’ll be interesting to see if Microsoft can attract them too.

JetBrains and Microsoft are warming up for a head-to-head competition, and we’re happy to say that the eventual winners are big Java teams. JetBrains exquisitely supports Java development and is strengthening its cloud development features. Microsoft and its ecosystem partners are making moves from the opposite direction. We can be sure, though, that one or the other isn’t enough anymore for large Java dev teams.

<h3>Start a 30-day trial of Coder Enterprise</h3>

If you would like to try our premium version of Coder, which includes all of the collaboration, security, governance, and management features, please visit <a href="https://coder.com/trial">https://coder.com/trial</a> to sign up.

Two big players are making moves to attract more Java developers with the cloud


Java Development is Changing

Jonathan Yu

Senior Software Engineer

WebRTC (Web Real-Time Communication) enables delivery of audio and video conferencing applications using native web technologies, but a lesser-known feature is that it can tunnel arbitrary data. This is the story of how and why we migrated our networking from a traditional reverse proxy architecture over to WebRTC, and what we learned in the process.

<h2>Where we started</h2>

Coder orchestrates development environments on your existing Kubernetes infrastructure, whether self-hosted or in the cloud. As with many cloud-native applications, Coder relied on a reverse proxy, which we called the “envproxy.” The envproxy routed traffic from outside the cluster into running workspaces. Coder is made up of a control plane—the service we call “coderd” which provides a dashboard for users to start and stop their workspaces—and a data plane⸺the envproxy and workspace.

In this context, the data plane refers to components that are in the critical path of the developer’s workflow; any failure would cause a disruption to a user’s development process. The proxy architecture provided a central point to enforce access control and perform audit logging, but it had consequences that led to a poor user experience:

<ul>
<li>If the envproxy process crashes or restarts due to an upgrade, clients experience a brief interruption and programs need to re-establish any in-flight connections.</li>
<li>The proxy imposes additional round-trip latency, since it must read incoming stream data, decrypt it, and then re-encrypt it, so that we can forward it to the target workspace. As with audio or video calls on an unreliable connection, any visible latency when editing source code interactively results in <a href="https://input-delay.glitch.me/">similar frustration</a>.</li>
<li>The proxy operates at layer 7, constraining the protocols that developers can use to those that the proxy understands: for example, developers cannot access PostgreSQL databases in their workspace using its native binary protocol. The alternative is to use SSH port forwarding to tunnel these connections.</li>
<li>The proxy is an additional service to maintain, and since it is shared with multiple users of the system, any issues could impact multiple users simultaneously.</li>
<li>Services running inside the workspace containers need to listen for traffic from the proxy. While we use Network Policies to secure these, cluster administrators must ensure that the cluster networking enforces these policies. For example, Amazon’s Elastic Kubernetes Service (EKS) does not enforce these policies by default, and we want to take a defense-in-depth approach to enforce security boundaries.</li>
<li>Multiple points of failure meant that things could fail without being clearly diagnosable, and sometimes the failures would not be apparent to users.</li>
</ul>

<h2>What we evaluated</h2>

Many of our engineers use SSH forwarding to tunnel PostgreSQL traffic or pass through an SSH agent socket from their local workstations to their Coder workspace. While this approach generally works well, the envproxy introduces a potential failure mode and inhibits upgrades; all in-flight connections must complete to gracefully shut down. A peer-to-peer architecture would resolve these challenges, while also providing a secure-by-default installation and reducing effort for system operators.

WireGuard solves the same fundamental challenge that we face with developer workspaces: securely providing end-to-end connectivity, across untrusted and unreliable networks, supporting a mesh operation mode and network roaming. Unfortunately, browsers do not include native support for WireGuard, and implementing it would be non-trivial, since browsers do not allow transmission of arbitrary UDP or even TCP traffic.

Our friends at <a href="https://blog.discord.com/how-discord-handles-two-and-half-million-concurrent-voice-users-using-webrtc-ce01c3187429">Discord use the WebRTC protocol to stream media in real time</a>, and we realized that Coder has similar requirements in terms of latency, security, browser and device support, and compatibility with diverse networking configurations. If we could tunnel arbitrary protocols over WebRTC, then we can leverage the existing ecosystem. Since browsers provide built-in WebRTC APIs, we would be able to modify our <a href="https://github.com/cdr/code-server">open source code-server project</a> to use it as an underlying transport, providing an even faster editing experience. Better still, we can provide end-to-end encryption and minimize latency on local networks, even behind gateways using Network Address Translation (NAT), through WebRTC-compatible technologies including STUN, TURN relays, and DTLS.

<h2>Why and how we use WebRTC</h2>

With our new networking model, Coder uses WebRTC to broker connections between the user and services running inside their workspace. In order to maximize compatibility and provide a clean migration path, our initial implementation uses the open source <a href="https://github.com/pion/turn/">Pion TURN relay server</a>. The relay provides a rendezvous point accessible to both the user and the workspace they are trying to access, and which may be located either inside or outside of the Kubernetes cluster, as long as it is able to receive inbound connections from both:

An agent running inside the workspace establishes an outbound connection to the relay service, and the user connects to the same relay with a token to authorize the connection to the endpoint. Both the user and the workspace must be able to connect to the relay, but it is not a requirement for the workspace container to connect directly to the user’s workstation or for the user’s workstation to connect directly to the workspace container. This approach means that:

<ul>
<li>The workspace agent process can establish an outbound connection, rather than creating a listening port to accept inbound connections.</li>
<li>The proxy operates at the transport layer (the encrypted TCP stream between the workspace and relay service) rather than the application layer (SSH, HTTP, HTTPS), so it is protocol-independent and capable of tunnelling arbitrary protocols between the user and their workspace.</li>
<li>Only the relay service and control plane need to be accessible by clients, so we minimize the points of entry that administrators need to secure.</li>
</ul>

<h2>Looking forward</h2>

While we believe that our new approach to networking will yield significant improvements to the experience of installing and operating a Coder deployment, we’re just getting started. In future releases, we want to explore:

<ul>
<li>Now in Coder 1.22 (Aug 2021): Full peer-to-peer communication using STUN to reduce bandwidth demands on the TURN relay server and eliminate it as a single point of failure</li>
<li><a href="https://github.com/cdr/code-server/issues/2605">WebRTC support for code-server</a>, so that connections go directly between the user’s browser and development workspace, using STUN and TURN for NAT traversal</li>
<li>An in-browser WebRTC proxy using a web worker to transparently tunnel arbitrary HTTP/HTTPS network traffic</li>
<li>Testing of high-availability configurations to ensure that the networking remains reliable despite a variety of adverse network conditions</li>
<li>Using <a href="https://www.twilio.com/stun-turn">Twilio’s Global Network Traversal Service</a>, which hosts a global network of STUN and TURN relays, instead of the built-in service</li>
</ul>

As a fallback when direct connectivity is not possible due to network conditions, traffic will flow through the TURN relay as depicted on the left. In future releases, users will be able to connect directly to their workspaces, relying on the STUN service to broker the connection and traverse NAT gateways. As a result, the relay will not be part of the data plane and interruptions to the STUN/TURN relay process will not affect connectivity to the workspace.

The story of how and why Coder migrated our networking from a traditional reverse proxy architecture over to WebRTC, and what we learned in the process.

Rearchitecting Coder’s networking with WebRTC

At Coder, we believe that the future of cloud development is editor neutral. 

But before we talk about the future, let’s spend a few moments thinking about the past and how we got to where we are.

<h2>A quick timeline of editors</h2>

Here is a quick and highly selective timeline of editors used by developers and when they were first released.

These editors have a few things in common. First, I’ve used them all at one time or another. That’s not particularly relevant to our topic today, but there it is. Second, with the exception of VS Code they are all twenty years old or older. And third, and most interesting, they all still have at <a href="https://insights.stackoverflow.com/survey/2019#technology-_-most-popular-development-environments">least a 10% market share to this day</a>.

From the above, we can easily jump to two conclusions:
1. Building a good, new editor is really difficult and doesn’t happen often
2. Developers generally don’t like to switch editors

From my own experience, both of those are true. 

<h2>A missing piece — the Coder IDE</h2>

I deliberately left one particular editor out of the timeline, and that is the Coder IDE. Now, this is not a product pitch, but indulge me for a moment.

We launched the Coder IDE in 2018. It was our first product as a new company. Users could visit coder.com and we would give them a cloud development environment that launched in under a second, had real-time collaboration, supported for VS Code extensions, and could burst to 96 cores.

Sounds great, right? So why did I not include it in the timeline? 

It no longer exists. It failed to gain the kind of traction that was needed to keep it going, so we shut it down. Lots of people tried it out and thought that it was cool and even tweeted about how awesome it was. But when it came time for them to get to work on a real project, they didn’t use it. They went back to what they were doing before. 

What we realized in hindsight was that while we thought it was a great product, it didn’t fit into the workflow that developers already used. Put another way, we tried to impose on developers our own ideas for the best workflow rather than trusting developers to make the choices about what worked best for them. 

We also realized that we were simply trying to do too many things at once. We were trying to host people&#39;s computers for them. We were trying to build our custom editor. And we were also just trying to get people to work on remote servers, which in itself has proven to be a challenge. 

In short, we were trying to boil the ocean. 

<h2>Pivoting — learning the importance of choice</h2>

We knew that being able to code remotely was a need for a lot of developers, including ourselves. We also knew that the Coder IDE had tried to meet that need but failed. So that left us with two options:

<ul>
<li>Wait for popular editors to support remote development</li>
<li>Figure out how to enable developers to use popular editors remotely</li>
</ul>

We didn’t want to wait; we wanted to lead. Now fully realizing the importance of trusting the choices developers make for themselves, we set out to figure out if we could make the editor most frequently chosen by developers accessible through a browser.

So we started working on <a href="https://github.com/cdr/code-server">code-server</a>, which lets you run VS Code on any machine and access it in the browser. This was before VS Code supported remote SSH or JetBrains Projector.

The first version of code-server was hacked together. I shimmed a lot of Electron into the web and shimmed in a ton of node modules that had no business being on the web at all. It wasn’t until version 1.36 that we felt comfortable launching it. 

Like earlier, we had a lot of people try code-server and think it was really cool. But unlike with Coder IDE, they kept using it. It took off mostly by word of mouth. Soon thousands of developers were using it as part of their daily workflow. For the first time, developers were really choosing something remote without us having to push it onto them.

What made code-server a success, I believe, is that it&#39;s really just a small iteration on the workflow that people already love. It’s just VS Code in the browser. They already use VS Code. They sometimes need (or want) to work remotely, and so code-server meets that need while respecting the choices they have already made about what editor works best for them. 

<h2>Developer choice &amp; the future of cloud development</h2>

So if choice is important to developers, what are they free to choose when working for a company?

There are some things that they typically can’t choose:

❌ Operating System

❌ Software Stack

They can&#39;t choose their operating system, at least not all the time. They also can&#39;t generally pick their software stack or easily adjust it. If you join a company and they’ve been using Java for ten years, it&#39;s gonna be a really difficult thing for them to come in and say, “let&#39;s switch everything to Go.”

What they can typically choose though are:

✅ Editor

✅ Keybinds

✅ Terminal

I think it is safe to say that any successful cloud development platform will have to continue to allow developers to make their own choices for all of these. They will not willingly give up these abilities. Developers will expect to be able to use their favorite editor in a remote environment. They should be able to use VS Code in a browser, or VS Code through remote SSH, or IntelliJ, or Eclipse, or whatever. The platform must be editor neutral. It must also allow developers to use their terminal of choice and to set their own keybindings. That’s a minimum.

The move to cloud development also presents opportunities to empower developers, to honor their choices about their workflows in areas where they currently have little or no choice. 

I use Linux and i3. I should be able to go from any OS to any OS. I want, for example, to be able to continue to work on Linux and develop an IOS app for Mac. Currently, that is not possible without some kind of crazy VNC stuff. But with cloud development platforms that becomes very possible. Now I can choose my own operating system. 

Workspaces are getting much easier to template. I don&#39;t think this is a solved world by any means. There&#39;s a lot of iteration that still has be done, such as how will people actually be developing these templated workspaces in the cloud. But I feel like we can definitely say that developers will be able to get faster changes to the software stack. If you want to move from Java 7 to Java 8 it could be as simple as opening a PR for that. 

So here’s what the future could look like for developer choice:

✅ Operating System

⚠️ Faster changes to the software stack

✅ Editor

✅ Keybinds

✅ Terminal

So I began with the assertion that the future of cloud development had to be editor neutral and explained why I believe that. But hopefully, it&#39;s much more empowering than just the editor itself. Hopefully, we&#39;re able to hit a lot more neutrality on the operating system and the software stack that organizations are able to iterate on. 

That’s the future of cloud development as I see it, and it’s something we are working towards at Coder.

This post is a version of a presentation given at <a href="https://ecdtools.eclipse.org/events/idesummit/2021/">Cloud IDE Day 2021</a>, hosted by the Eclipse Cloud DevTools Working Group, part of the Eclipse Foundation. You can watch the full presentation below.

Cloud IDE Day: The Future of Cloud Development is Editor Neutral

The co-founder of Coder discusses the future of development in the cloud and how moving their IDEs to the will empower developers.

The future of cloud development is editor neutral

The Coder team provided remote development support for JetBrains IDEs, including IntelliJ IDEA, PyCharm, GoLand, RubyMine, and WebStorm. Under the hood, we used Projector, the open source project by JetBrains.

We wanted to share why we’re excited about it, what it means for the Coder community, and our perspective on the future of developing in the cloud. 

When we discovered the project, we assembled a small team at Coder to focus on the implementation of Projector in our product. We’ve been implementing and optimizing the experience within Coder, submitting contributions, and working with the team to help harden the experience—all with the shared goal of bringing the benefits of developing in the cloud to more developers who want to use their preferred IDE.

<h2>What is JetBrains Projector?</h2>

Projector is an open source framework for running JetBrains IDEs and Swing apps remotely. Similar to how code-server allows you to run VS Code on any server for ease of access and additional compute power, Projector makes remote development with JetBrains IDEs a reality. 

When we discovered the project, we assembled a small team at Coder to focus on the implementation of Projector in our product. For the last 5 months, we’ve been implementing and optimizing the experience within Coder, submitting contributions, and working with the team to help harden the experience—all with the shared goal of bringing the benefits of developing in the cloud to more developers who want to use their preferred IDE.

<h2>Why we’re excited about JetBrains Projector</h2>

Just like code-server, Projector brings the benefits of remote development and the power of the cloud to your favorite IDEs. This opens up the possibility to offload workloads like slow builds, test suites, and other development operations to the cloud. We believe this is the future, and we’re thrilled to bring it to more development teams through Coder.

Its counterpart is <a href="https://coder.com/blog/remote-development-with-jetbrains-ides">JetBrains Gateway, which makes it possible to develop with JetBrains over SSH</a>.

<h2>Why Projector + Coder?</h2>

Projector is open source and any developer can use it by going to the <a href="https://github.com/JetBrains/projector-server">Projector GitHub repo</a> and deploying it on any machine. Coder takes care of the heavy lifting with Projector, making it simple to use for development teams who don’t want to build custom solutions for managing infrastructure, access control, and distribution. 

With Coder, Projector can simply be packaged within the Coder workspace.

Check out this video of launching a JetBrains IDE from Coder:

Launching JetBrains Environments from Coder

<h2>Next steps</h2>

Projector is available <a href="https://github.com/JetBrains/projector-server">on GitHub</a>. Want to try it out for your team? Our <a href="https://coder.com/trial">60-day free trial</a> is the easiest way to get started developing securely in the cloud using your favorite JetBrains IDE.

Introducing JetBrains Projector, an open source tool for running JetBrains IDEs remotely. Let’s look at the possibilities for remote development.

Remote development for JetBrains IDEs with Coder

Guide to JetBrains Projector with Coder

A portable and extendable development environment shouldn’t require taking hits to your productivity. Providing exact functionality that your local IDE does is crucial, we get that.

We’re taking IDEs you love and adding all the Coder benefits. Real-time collaboration (in the same filesystem), dynamically scaling resources, and dynamically expandable storage — to name a few. We’ve started this integration with VSCode.

Using VSCodeVim with Coder (in the browser)

Continue using extensions you are used to. We run some extensions in the browser, and some on the server to reduce the load on your device.

Changing version of Go on the fly

We attempt to abstract painful portions of a developers workflow. You can easily switch language versions with a few clicks.

Customizing color and icon themes (uses extensions)

Having no barrier to entry is a must for us. You can use Coder completely free, and optionally upgrade for additional storage, CPU, memory, and networking.

You can try it out now at <a href="https://coder.com/">https://coder.com</a>. 🎊

Big thanks and credit to the VSCode team, their tidy and modular codebase is a large contributor to the speed and functionality we provide.

We’re still in alpha, but would absolutely love to hear your feedback. If you have any questions you can tweet me <a href="https://twitter.com/kylecarbs">@kylecarbs</a> or <a href="https://twitter.com/coderhq">@coderhq</a>. Feel free to <a href="https://discord.gg/jvZN2kZ">join our discord</a> and share as well!

AI-native Development

Secure Environments for 2,500+ Developers

Kyle Carberry

Explore the latest from Kyle

Java Development is Changing

Rearchitecting Coder’s networking with WebRTC

The future of cloud development is editor neutral

Guide to JetBrains Projector with Coder

Coder v0.2 — Providing all of VS Code in the browser

Related content

Using Claude Code with Coder Workspaces

Introducing Coder Agents

Self-Hosted Doesn’t Always Mean What It Implies