--- title: "The Real Reason Cloud IDE Adoption Is Lagging" id: "13117" type: "post" slug: "the-real-reason-cloud-ide-adoption-is-lagging" published_at: "2022-10-26T14:30:00+00:00" modified_at: "2022-10-26T00:37:57+00:00" url: "https://www.lastweekinaws.com/blog/the-real-reason-cloud-ide-adoption-is-lagging/" markdown_url: "https://www.lastweekinaws.com/blog/the-real-reason-cloud-ide-adoption-is-lagging.md" excerpt: "Cloud integrated development environments (IDE) aren't being adopted by programmers at the same rate as other cloud technology. What gives?" taxonomy_category: - "Uncategorized" --- Recently, the founder of we’re-going-to-reinvent-the-terminal startup Warp [wrote a blog post](https://www.warp.dev/blog/why-is-it-taking-so-long-for-cloud-dev-environments-to-catch-on) about why it’s taking so long for cloud integrated development environments to catch on. I don’t disagree with Zach Lloyd’s assessment: Development remains one of the few digital spaces tied to physical machines, and there are serious benefits to writing and running code in the cloud. Lloyd points out that version control — a major factor in cloud adoption for many knowledge workers — isn’t a motivator for developers to code in the cloud. Although that’s true, I think there’s a deeper reason why developers aren’t moving to remote development. ## My evolution to a cloud IDE I’ve been a grumpy UNIX admin for a very long time. Early in my career, developers were using editors like BBEdit, Sublime Text, or, later on, Atom. In the meantime, I didn’t really know what environment I’d be working within from day to day. I’d be on my laptop today, sure — but tomorrow I’d be connecting over SSH to a recalcitrant Solaris box, and I knew remarkably little about Solaris. But I did know that it’s UNIX and that it’d have some form of vi installed. So I started using vi as my default text editor, having given up on using GNU nano (which is a fine editor, but in those days it would get you made fun of, and I used to have thinner skin). At that point, it started feeling pretty weird to have a fairly expensive laptop and more or less run it as a terminal. That said, an awful lot of laptops are glorified Facebook and Twitter machines, so I had nothing to worry about comparatively. Those early days also predated Docker. Getting an application to work on Mac OS X was usually doable — it was, after all, a certified UNIX — but it was not fun. Even today, the behavior of `sed` on a Mac versus a Linux box is markedly different until and unless you install GNU sed on your Mac. On one particularly irritable afternoon of work, I threw my hands in the air, thought “screw this, I’m over it,” spun up a virtual machine on a server in the data center, and used that as my development box. Suddenly, my dev environment looked a heck of a lot more like production. It had a super fast connection to the internet. As an added bonus, my accident-prone self knocking a drink onto my laptop didn’t destroy data that I cared about anymore. I was hooked. ## How I code today Fast forward to 2022, and I still largely follow this pattern. I’m writing this post while taking a break from working on code for a project, somewhere midair above Denver, from my iPad. It’s the only computer I usually bring with me on trips these days, just because the remote workflow is so ingrained in how I think about things. Anything code-centric or requiring heavy lifting that’s not a good fit for an iPad-based workflow lives on a Graviton EC2 instance in us-west-2, while the iPad provides me what’s basically a thin client: little more than a keyboard with a screen attached. But getting other people on board with my cloud-based development approach goes over about as well as if I suggested they smack a baby platypus in its bill or something. These days, I bias toward using Visual Studio Code (please do not email me about how wonderful it is, as I already know). But despite numerous attempts, I can’t find a way to make VS Code work comfortably for me in any other scenario than on my desktop at home. [GitHub’s CodeSpaces](https://github.com/features/codespaces) goes a long way; [Blink Code](https://docs.blink.sh/advanced/code) integrates VS Code into itself for a more native experience. But there’s just something about the ergonomics that doesn’t work at all for my use case, so I’m forced to reexamine exactly why so many of us push back against cloud-based development. ## Current options for cloud IDE Microsoft and Amazon have certainly tried to drive toward cloud-based development. Google hasn’t really, given that it’s mostly satisfied with Google Docs as an IDE. (“Wait, what? Who writes **code** in Google Docs?!” you might reasonably exclaim. The depressing and sad answer is “engineers being interviewed for roles at Google.” It’s a part of the interview process that I can only assume is rooted in some archaic form of hazing.) It should be noted that at the 11th hour Google dropped their new Cloud Workstations offering in preview. It offers a bunch of supported IDE options (including, somehow, vim)–but I haven’t tested it yet. I was very interested in exploring [Cloud9](https://aws.amazon.com/cloud9/) shortly after AWS acquired it. The product had some iPad teething issues that did get solved. For me, the hurdle was always gating access to my development environment behind a high-friction process: First, log into the AWS console and navigate to the right service and subsection. Combine that with what felt like a high degree of being opinionated in ways I disagreed with (for instance, the concept of not having a persistent working environment by default), and I was turned off. I haven’t heard much about AWS Cloud9 in recent years. I know there’s a service team dedicated to improving it, but I’m not seeing it in the wild at all. On the other hand, CodeSpaces is getting a lot of attention, and I’ve been sporadically using it for some projects, myself. It’s nailed most aspects of the user experience, the pricing is eminently reasonable, and the sign-in process is very low-friction. And yet … I find myself reverting to my tried-and-true process more often than I’d like: “SSH to an EC2 instance and use vi to edit files.” It’s based on nothing else I can point a finger to beyond “habit.” ## Cloud IDEs will take off … when the experience is worth it I think that’s really what our development choices come down to across the board: habit. By the time someone is working professionally as a software engineer, they’ve been writing code long enough for habits to form. Their ways of working are more or less ingrained. For something else to supersede that habit, it needs to be enforced by policy (which doesn’t tend to go over well), be a technical requirement, or be such a significantly better experience that switching is a no-brainer. Unfortunately, the experience of cloud development, while periodically better on a variety of axes, hasn’t been a transformative breakthrough from the developer experience perspective so far. Until that changes, I suspect driving the adoption of cloud-based development environments is going to be an uphill battle. At least, for now, everyone will have top-of-the-line laptops. by Corey Quinn Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure. ## More Posts from Corey [Back to the Blog](https://www.lastweekinaws.com/blog/) [https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) ### [Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […] [Read More about Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) [https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) ### [Reading Observability Tools? That’s a Robot’s Job](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […] [Read More about Reading Observability Tools? That’s a Robot’s Job](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) [https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) ### [S3 Is Not a Filesystem (But Now There’s One In Front of It)](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […] [Read More about S3 Is Not a Filesystem (But Now There’s One In Front of It)](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) ## Get the newsletter! Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark. "*" indicates required fields