Recently Zeti was privileged to get access to a new product from GitHub, Codespaces. Lets start with the headline. This is my iPad Air from 2013 running the full https://www.bincoin.wtf React + Azure Functions website, with full hot reload, testing and syntax highlighting:

If I bought a keyboard for it, this would actually work to develop on, although I must admit it is still a little slower to render than I’d like. I think that can be forgiven of almost decade-old silicon that was only ever designed to run Angry Birds though!

How does it work?

You may have guessed that some sort of remote machine is involved here - even the engineers at a company like GitHub can’t eke a decades worth of chip advancements out of a machine. GitHub Codespaces basically hosts a container for you that holds your code and everything you need to develop on it. You can then connect to the container from anywhere in the world with a sufficiently advanced browser (this I think is going to be a game to play - how old a device can I find that runs Codespaces?).

So from this explanation, some will be throwing their hands in the air and saying ‘this is just a development VM, the latency is usually shocking and you need to be connected to the internet the whole time’. Neither of those things are entirely true. Firstly latency is amazing - I don’t know how they do it, but it really feels like I’m running this locally. Particularly as on machines with Operating Systems that support VS Code, you can elect to connect from your local app instead.

Also, the key thing here is that the specs for the container needed to develop the code is stored in the repo with the code itself. So to onboard a new developer you tell them to go to the repo and click ‘Open with Codespaces’. That’s it. No ‘oh no you need Node 14.x not 13.x, but this other app we develop needs 12.x and we’re running windows so good luck with that’. No dotnet sdk selection (I must have 20 by now on my Mac). No security setup either really, so no having to spend torturous hours setting up virtual networks and firewalls, and then getting complaints when the latest trendiest framework is blocked - everything is authed through your GitHub account.

The other thing? That container spec can simply be run locally on your machine using Docker. So even if you were disconnected from the internet, you could continue to work.

So what?

Well firstly, it’s so good it has made me write my first ever Dockerfile. An event I never expected to happen. And secondly I think this has a profound impact on both how we onboard developers, and what kit we purchase for them.

If I can run a passable environment on an iPad Air, do I need to have some leviathan of a coding laptop for every developer? Or would I rather have lightweight, fast laptops with stunning battery life - perhaps M1 Macbook Airs? Currently I confess I wouldn’t have enough confidence in the product to not get a machine with a bit more oomph as a backup - but it won’t be long I suspect before that position becomes impossible to defend. Perhaps once the program is GA and includes a wider range of cpu/memory options for the remote containers.

Also this is the early days of this technology. Currently you can choose from a pretty decent suite of preconfigured devcontainer’s that have most development tools on them, or use the default that comes with most languages. If you are using something odd, like Puppeteer, then you wind up having to dig into dockerfile’s. I would not be surprised at all if a future feature (and not that far in the future) would be to autocreate your devcontainer from the code contained in your repo - after all all it would have to do is read a csproj or package.json and know that ‘puppeteer’ means it needs chromium installing.

Serverless Mindset

Despite the inclusion of a dockerfile in this technology, which you might think would be a red flag for a serverless obsessive like me, this is actually such a progression along the serverless curve. The ‘faff’ and setup for any new development machine has just dropped to virtually zero, lowering onboarding friction and costs. Whilst of course I’d love to see usage based pricing on the Codespaces themselves, they are quite aggressive at pausing themselves - so if you join a meeting for half an hour your Codespace will have stopped billing you during that time. That’s pretty decent in terms of an early start at usage-based pricing.

Most importantly, this service lets you focus on what you do best - developing code for your chosen company - and reduces the undifferentiated heavy lifting that does not help you towards that goal. That is the Serverless Mindset in a nutshell.