I Buy a New Work Machine Every Day

Nope, you didn’t read that wrong. This blog post was written, the git commit was made, and then it was all pushed up to our private GitLab on a machine that no longer exists. I threw it out, and tomorrow I’ll spin up a fresh new one and have it ready to go before your coffee has even cooled to a drinkable temperature. I’m talking about using AWS Cloud9, an in browser IDE experience backed by an EC2 instance.

So clearly I lied to you, and I am not buying $1,500 dollar machine every morning and throwing it out. But let’s talk about what I actually am doing, and why you might care.

A journey of a thousand laptops

Over the passed years, I have had a few obsessions that have become closely intertwined, spurring on others.

Obsession 1, the hardware I use on a daily basis. My first machine I ever used for any kind of serious development work was a dell running Windows ME in my parents basement (yes, I’m young, and even more yes, Win ME was an abyss of sadness and despair.) I graduated through various machines and finally landed on macs. They were great, but it remains in my nature to chase the new shiny. If there is any possibility that what I am using could be inferior to some other product, I will have a nagging feeling that I need to try it for at least a week. In the passed year I have been though 5 different machines. MacOS, Windows, Linux, iOS… HP, Dell, Microsoft, Apple. You name it.

Obsession 2, remaining productive regardless of any other changes. This started simply. Syncing and maintaining dotfiles, settings, etc. Eventually I realized that whenever I would switch hardware, it would take me a day to get back to a truly productive state. Even if I was staying within the same OS and hardware ecosystem. I bashed my problem to death. I wrote a big huge bash script that installed everything I needed. Turns out Windows hates bash and OS X and Linux scripts ended up diverging so far I just maintained two versions.

Obsession 3, never lose any work. At first I only cared about not losing work if I lost a machine during travel or theft. Then I cared about losing work because of corrupt disks or just forgetfulness during frequent nuke and paves of the OS. Then I cared if I lost work if I dropped or spilled stuff and wrecked my computer. Solving this went through more and more iterations of backup and sync utilities operating in near realtime (buh bye battery life), scanning the system for un-pushed git commits and un-staged changes, etc. This takes too much work, don’t do it.

Over the passed few weeks, I have taken a new approach, and I am loving it…

So, about this machine I am writing on

AWS Cloud9 provides a fantastically easy way of spinning up new development environments. AWS manages the connections to your EC2 instance and provides an in browser editor and terminal. And it works. Unbelievably well.

I really can't believe how well AWS Cloud9 is actually working. I bundled up a couple of my envs with https://t.co/q0nUG4yBnf. Now I can bounce between contextual environments that behave like native apps. Blog post will be written.

— Jared Short (@ShortJared) June 2, 2018

AWS Cloud9 combined with a maintained Ansible playbook gives me the dream of ephemeral, repeatable, consistent and performant development environments across any operating system or hardware I happen to be using.

Ansible was the solution to the bash scripts of doom. It just makes it easier to maintain and collaborate with other folks on making sure our environments always have necessary tools and utilities we want to be using.

My routine in the morning

• Startup a Cloud9 Environment
• git clone the Ansible playbook
• run ./init.sh which asks for my encrypted secrets blob and runs the playbook
• grab an espresso and come back to a fresh fully configured environment.

I timed the setup of a fresh environment just to write this post. From the moment I kicked off an environment creation in Cloud9 to having cloned the blog git repo and writing the post title was 4 minutes and 33 seconds. Not even a having a workstation to working in 273 seconds.

The vim keyboard bindings are decent, typing to paint performance is about as good as you could ask for in a JS browser driven editor, realtime developer collaboration works well enough to make for some good pair coding sessions. I’ve even done a bit of work on the iPad Pro in Cloud9. I believe if I had a week where I was at a conference and not planning on doing a lot of heavy dev work where a keyboard would matter in terms of raw typing speed, I would have no problem taking only the iPad.

I have solved my productivity requirements as I can bounce from new hardware, operating systems, etc and always have the exact same editing experience and know I will have all the tools I expect. I can upgrade “hardware” independent from anything. The biggest thing for me was that my terminal software doesn’t even change if I change OS, which is unlike the experience I would have if I tried to do a typical ssh + vim over whatever term I had on the OS.

My normal day of work involves a lot of reading over AWS documentation (in browser), reviewing code from the previous days commits, writing some code or new utilities, writing docs, using the git cli, AWS cli, etc. Cloud9 supports my work habits extremely well. If you are working a lot with other GUI based applications you may face difficulties and my suggestion would be to still need to run those locally.

The biggest downsides

• You literally cannot work without an internet connections. I have come to peace with this one. It is truly uncommon that I am not on a connection stable enough to support the editor (even airplane wifi is decent these days). In the event I would still be working and not have a good enough connection, the second I need to install some dependency or look up docs I would be blocked anyways.
• You are at the mercy of the features of the editor, the plugin ecosystem is non-existent. I miss plugins the most, coming from VS Code where the ecosystem is a thing of beauty it does feel like taking a firm jab in the ribs. No JSX for you react folks out there.
• The built in lambda stuff is kinda meh and encourages bad practices. Use SAM, Serverless.com or any other code defined methodology.

A quick note on costs

You can pick nearly an instance type that you want to run your Cloud9 environment on. Usually I pick an m4.large which runs me $0.08 an hour, or about 64 cents over the course of a day. If you are going to be doing less memory intense work or really heavy computing tasks across a slew of Docker containers, feel free to adjust your needs to that days task. You may just need to pay a couple bucks extra for a day or two of a needing a really beefy machine instead of outright buying a high performance desktop.

To put this in perspective, I can get about 5-7 years of normal working hour Cloud9 usage for the cost of a midrange ~$1000 laptop.

How this helps you

Most likely you aren’t going to just throw everything out every evening (and you probably shouldn’t), but there are a lot of benefits to something like Cloud9 and a readily repeatable setup process.

• Onboarding new employees and contractors takes literal minutes. I can’t tell you how often I have wasted HOURS trying to help new clients and employees even do silly things like setup their AWS cli and cross account role assumptions, or configure a VPN client.
• Need a new experimental utility or lib, or want to work with something risky? Spin up a new short-lived environment to test things out before you blow up your daily driver.
• Do you have garbage home internet and it takes forever to install that docker image? Try 500+ Mbps on for size, no more coffee breaks after npm install.
• It does actually work pretty well on an iPad pro. I don’t feel like I HAVE to take my laptop out with me to the coffee shop in case urgent things pop up.
• Sharing Cloud9 environments for quick collaboration and pair coding also works really well!
• Great for training classes, setup a bunch of IAM users and guaranteed working environments ahead of time, and throw them all away at the end of the day. The AWS CLI makes automating this a cinch.

I’m sure there are other benefits, and I would love to hear from you. As always, you can find me on twitter @shortjared as well as the fine folks that sign my paycheck @Trek10Inc.

Signing off, sudo rm -rf /