That is, Github engineers now write code fully in the browser, as opposed to their local machines.
The blog post got immediately very popular and sparked a heated debate online.
Whenever we read unexpected / controversial engineering stories from big companies we usually react in one of two ways:
"Wow, they can do it because they are so big"
"Wow, they can do it despite being so big"
I argue this case belongs to the latter.
Cloud development solutions have been around for years, but most companies have not looked into them because they seemed to apply only to a handful of cases — e.g. simple frontend projects.
Github, though, is 14 years old and its codebase has 1M+ commits. For those of us who were not paying attention (here I am 🙋♂️) or dismissed this trend in the past, this is our wake up call.
This week I researched how people can write software on the cloud today, and why they should or should not.
Let's dive in! 👇
⚔️ Cloud Development vs Remote Development
Writing code that doesn't live and run on your own machine is a behaviour that has existed forever. People set up remote environments and accessed them via SSH.
Remote development, though, is different from Cloud development.
Cloud development provides tools to do remote development at scale, in a way that is seamless for developers and abstract from the underlying infrastructure.
It applies the benefits of cloud computing to dev environments.
But why should companies go for it?
🐄 Cattle vs Pets
In a presentation around 2011, Randy Bias famously said: treat your servers like cattle, not pets.
Here is a longer excerpt from Randy himself:
In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.
The simile is clear. Pets are expensive, fragile, and require bespoke work. Cattle is homogeneous, their maintenance is standard and each individual can be replaced (sorry, cows!).
This is now canon in infrastructure. Yet, our local machines resemble more pets than cattle. Each one is special and different. They have specific issues, they are fragile and hard to maintain.
What if we we treated our dev environments as cattle?
👍 Benefits of Cloud Development
Before getting into how we can setup a cloud environment today, let's assume we are able to pull this off.
Let's say we have this magic setup where developers open their browsers and start writing code just like they would do in their local IDE.
What benefits do we get from it? Actually, more than a few:
New hires can be ready to work in seconds, instead of hours or days.
This doesn't only save hours — it creates the lasting impression of a top notch developer experience. People will be amazed and feel that you care.
A centralised environment gives you leverage to maintain and improve it for everyone in the team at the same time.
In my experience, such work rarely gets done with local environments because it is:
High friction — developers need to opt-in and update things on their machine.
Risky — things might break for some folks with specific configurations, which leads to worst kind of bug fixing.
Cloud environments solve both issues. If you improve something, it is automatically improved for everybody.
Having your work always online makes it easily accessible to others, which enables better collaboration:
Reviews / QA — share the work you are doing by instantly sharing the address of your space, without the need to deploy on Staging or whatsoever.
Work on more projects — switch and jump in multiple projects with ease.
Pair programming — work with more people on the same code, as you would on a Google Doc.
Cloud environments means being able to work from any device.
In the past few months I have worked on the same project in Codespaces from at least two different laptops, and from my iPad when I was away.
I didn't have to configure any of them, and didn't have any issue.
The more your dev environment resembles production, the better. Writing code on the cloud can make this gap very small by using instances that mimic your production setup.
If code runs on a remote server, it can be considerably faster than on a laptop. Reducing build times brings tangible productivity gains.
👎 Downsides of Cloud Development
It's not all sunshine and rainbows, of course. Here are a few downsides of coding in your browser.
📦 Prep work
There is some work you need to do to replicate your full dev environment on the cloud. You may need to create a docker image for your stack and configure everything to work within a container.
However, this is healthy work and you will probably benefit from doing it anyway.
It goes without saying that this setup makes it impossible to work without an internet connection. It is a minor downside if you ask me, but worth mentioning anyway.
This is the only real deal-breaker for many people.
Work on native mobile apps is mostly unsupported by the current tools. Android simulator doesn't run inside containers, and iOS doesn't run on Linux.
🤹 The Cloud Development Landscape
Let's talk now of how you can create such setup today and what tools you have at disposal.
If we define a cloud development environment as an online space where you can write code, test it and release it, there are many tools now that fit this definition.
We can group them in at least three classes:
🟣 Full environments
🔴 Low-code / assisted
🟣 Full Environments
Tools where you can do pretty much anything you would do on a real, local machine. You can run anything from simple projects to multi-container applications.
You can use popular IDEs, the terminal, run the application and access it from a sharable URL.
The most popular are:
Github Codespaces — if you are on Github this is the most straightforward, ready-to-use solution.
Gitpod — pretty much equivalent to Codespaces, but supports any Git hosting.
Tools that support only specific languages and runtime environments. You may have a persistent filesystem, but cannot run arbitrary docker images (e.g. you cannot host databases).
They usually provide strong sharing and collaboration features, from templates to real-time multiplayer editing — a-la Google Docs.
The most popular are:
Replit — it supports 50+ programming languages and has all kinds of sharing and collaboration features.
Codepen — more popular than Codesandbox, but frontend-only.
🔴 Low-code / assisted
Tools where you write code in a totally custom environment, specific for some purpose. I am familiar with at least two:
Autocode — it lets you create serverless functions and websites and easily combine external APIs.
Pipedream — similar to Autocode, you create entire workflows combining several APIs.
A simple demo of Autocode about building a Webhook that writes on Slack ☝️
This list can go on and on because, when you think about it, even no-code tools are actually cloud dev environments. However, for the sake of this article I focused on those where you write actual code, to have a fairer comparison with local machines.
As long as your stack is supported, cloud development today is a mature option that brings more upsides than downsides.
The tech is solid, fast, not expensive, so there are really few reasons not to use it regularly beside — or in the place of — local development.
📑 GitHub’s Engineering Team has moved to Codespaces — GitHub explains how it was able to create cloud environments that boot in 10 seconds for all their developers.
📑 Building in the Cloud with Remote Development — how Linkedin built a custom cloud environment in the same fashion as Github. This was published just last week!
⭐ Weekly Featured Jobs
Here are the remote engineering jobs I recommend this week.
I personally review all of them and have a chat with each company to get more context and better understand the opportunity.
🆕 Launch House — Founding Engineers
They are looking for founding engineers — it's a great ground-floor opportunity.
🚨 REMINDER 🚨
Starting next week, only paid subscribers will receive this newsletter weekly.
For everyone else, you’ll still get the same great newsletter, but only about once a month (if that works for you, all good!).
🎁 Subscribe in the next 48 hours and lock in 20% off forever ($120 for the year, or $12/month) 🎁