Introducing DevZero. It’s time to upgrade localhost.

‍

We, developers, want to write code to solve problems for our users. We are artists and we all have our favorite paint brushes - we like our aliases and our color-coded terminal windows or those special IDE extensions on the third monitor that make it “just right”. We hate spending time waiting for builds to finish, or for code to compile. We’re also easily distracted - if yarn build is taking too long, it’s time to either browse the #pets channel on Slack or peek around on HackerNews. We want our code reviewers to “just” understand what we are intending the PR to achieve. We want to ensure that our (bug-free :)) code works just as expected when it goes to production or in some cloud-native tool.

But today, while our terminals look all snazzy, our laptops groan to a halt as the IDE tries to index a repo or pull down a large docker image while battling Chrome and all our other tools since there are never enough resources. And then there’s the dreaded, CPU-hungry “Share Screen” on zoom.

Additionally, writing code on a laptop that is different from production means we’re handicapped more. When we do a code review of the proposed changes, we have no way to verify if this thing will actually work. We depend on CI to get that extra bit of confidence, but even CI operates a tad bit differently from production.

Adding salt to the wound, many of these test environments are shared tenancy – we run some tests but they seem to be producing a weird error when I didn’t even touch that part of the code! Oh wait - Sally is testing out a new database schema while Harry is testing changes in another handler of my micro-service. Enough is enough!

Today’s tooling and workflows are holding us back. At DevZero we believe that a combination of local tools paired with remote compute will give the biggest bang for your buck when it comes to accelerating developer productivity.

At DevZero, we believe that we don’t need to spend more time convincing people about the various value props of the cloud. We spend our time talking about development environments that are production-like and ephemeral and enable rapid iteration loops for everyday developers. They just happen to be hosted in the cloud. Turns out that calling them cloud development environments is good for SEO, so this post will use that phrasing some, with the ultimate goal of helping developers find us.

What are these remote development environments? #

A remote (or cloud) development environment could mean a few different things:

An environment (one or many cloud resources, containers, VMs, etc) hosted in the cloud that is the runtime for the dev environment. This would contain source code, secrets, artifacts, build tools, and be connected to all the relevant resources that the developer needs.An environment where built artifacts can be published and executed, to verify how they behave end-to-end, as part of a larger subsystem.An IDE inside a browser that contains source code, build tools, and an execution environment that usually runs on some cloud VM or container.They all offer various levels of flexibility - we won’t go into the justifications of one approach over another just yet.

Why are remote development environments important? #

For someone to buy and adopt this modern way of development, the pain of the status quo needs to be greater than the pain of change.

There are quite a few large areas that benefit engineers.

Removing all blockers or points of friction that can appear during a developer’s flow state, thus affecting the inner loop of the SDLCHaving sandboxed, forked copies of relevant databases to code againstFlexible resources so you always have enough compute powerBeing able to run multiple microservices so it's easy to debug call chains spanning multiple services - giving a lot of the confidence that is usually saved for later staged environmentsHaving your own environment that is contextually symmetric to production, and hermeticDepending on the stack or subset of services that a developer needs to work on, those can be made availableIf something gets borked, the ability to get a fresh copy of the whole environment in secondsNot having to collide with Sally’s and Harry’s changesThere are quite a few that benefit companies.

Companies need to focus on revenue-generating activitiesBuilding internal development environments isn’t revenue-generating for most companies, and doesn’t really impact their customers directly.When developers spend less time managing their environments or dealing with issues related to environment config drift, that time can be spent on building products for their users.Platform maintenance costsYes, someone will have to maintain the environment templates, but large teams won’t need to spend as much time on internal developer experienceQuite often, cloud costs balloon since the internal teams focus heavily on platform features and not platform efficiency. As a result, cloud costs related to these environments go up. If engineers aren’t building 24 hours a day, it’s futile to foot cloud bills for all 24 hours.Understanding which components of the inner loop are slowing down development (and prioritizing them)Improved security and compliance postureSource code, secrets, etc stay out of the local laptopsOnboarding/offboarding engineers becomes a breeze(comes with the caveat that if this is a new way to develop at the company, it will require some security reviews up front, which can affect the speed of initial adoption)

Why isn’t cloud-based software development the status quo? #

Timing #As with all things, timing is critical. There has been a lot of movement in the cloud-based development area over the last 5 years, with increasing emphasis from the venture capital community. This is fundamentally driven by the needs across various companies (not necessarily pain-point number 1, but usually its number 2 or 3).

Cloud availability #

Cloud providers have been adding regions across the globe (AWS has 30, GCP has 24, and Azure has 60+). Developers don’t care about where compute/filesystems are sitting, they care about the user experience being super snappy. Having availability in so many regions around the world fundamentally reduces round-trip latencies. This also helps with the availability story as no developer would tolerate not being able to code when they want to (they had that experience on their laptops already).

Advent of edge compute #

Edge compute will fundamentally help with operational efficiency. I’m still not sure about how dev workloads can be optimized using those workers, but my sentiment is that things like Bazel caches, npm/artifact registries, etc will be benefited greatly. It wouldn't be surprising to see GitHub also taking similar approaches to reduce the time to download repositories (Netflix took a similar approach to move content closer to the end users). The game is simple: heavily complex things can’t be run directly on device and can benefit from centralization. Now we need to get that centralization as close to the user as possible to get the best of both worlds.

Cloud costs #

Costs for compute in the cloud are lower than ever today, and it’s invariably cheaper to get very powerful cloud compute* than to get a powerful laptop every year or two.

*Small caveat: Cloud does give you resources to help you manage costs, but the incentive structures for a cloud provider are simply not aligned with that of the cloud consumer. An experience from Uber (circa 2016-2017) was that cloud spending got quite high for the internal dev environments (called Lifeguard then) - we realized that as an engineer, it was very easy to get a new machine, but no one would ever turn them off or suspend or kill them. And we didn’t have the tooling to enable that either. If tooling is present, the cost of getting a dev environment in the cloud can be a fraction of getting a beefy laptop.

General internet availability #

What if I don’t have internet? Internet reliability has been improving across the world, and will ultimately be as reliable as running water, although this isn’t the case everywhere in the world today. Planes have wi-fi, and our phones have incredibly fast internet. Depending on how you connect to a remote development environment, the bandwidth requirements are usually incredibly low.

CRDT (Conflict-free replicated data type) #

Collaboration is a big problem for developer environments- the only time we collaborate is during the coding round of the software engineering interview process. In our day-to-day jobs, usually, one person shares their screen on Zoom with code in an IDE, and the other person views and dictates. Google docs solved this problem for documents, but cross-platform IDE-level collaboration is not something that has caught on yet. I expect CRDTs to solve this problem.

Execution and Implementation #

In our experience, when we talk about remote dev environments, people immediately think about the following:

Virtual Desktop Infrastructure (VDI) browser-based developmentYes, those don’t have a good user experience or an effective encapsulation of complexity for the type of engineering we do at most companies nowadays. Sure, the browser IDE might be fine for a small task here and there, but for everyday workflows, migrating developer habits from IDEs to a browser just doesn’t work. VDIs have too much latency to make for a smooth development experience.

Strong divergence from how development processes are already structured #

Engineers love their local setups and IDEs. If there’s something remote happening, it needs to work with their preferred tooling and persist all their preferences. Tools that require a large migration to adopt just don’t work. Teams have a lot of other priorities and investing a lot of time in getting dev tools to work right doesn’t quite cut it.

Lack of strong customer support #

“I don’t want to wait. I want it right now,” - that’s the usual developer mentality. As a result, this sort of tooling is often built in-house. A lot of tools targeting bottom-up adoption don’t invest heavily in this area. Once a developer gets stuck and can’t find the right path forward, they have essentially moved on from the tool for a bit.

Remote work and access to strong compute #In the past, developers would have powerful workstations to run heavy workloads. There was really no need to invest in dev environments. Today, a lot of the workforce is remote. Getting everyone a powerful computer is not an option. Shipping a computer in the first place is a pretty challenging endeavor. This is a tailwind that should help push companies to explore remote environments.

Focusing on the wrong personas #

We engineers join companies to do our best work to help the businesses we work at. We obviously don’t want to waste time on things that don’t help us achieve those goals - we hate being unproductive. But introducing a new way of developing in a company is probably not something an individual engineer can push for, or gain traction towards.

If it’s easy enough to use and it helps the day-to-day, most definitely! But introducing something this drastic in a company, perhaps requires buy-in top-down since ultimately the responsibility for developer productivity lies there.

Past work #

Some companies have built this in-house. As it happens, I used and helped build these environments at Uber. My co-founder, Rob Fletcher, was a user of these environments at Meta (Facebook). Shopify, Slack, Rippling, Google, Netflix are a small subset of companies that have dedicated internal teams to build out tooling like these for their engineers.

But building software internally is expensive. I suspect this was done for the following reasons:

Nothing comparable available in the marketInternal requirements became dire enoughDev environments need to be flexible af. And when, not if, when things break, chatting to someone inside the company usually has the quickest turnaround timeBoth of these were reasons we decided to build in-house at Uber in 2020 till late 2021, after evaluating the direction of various tools in the market during that period.

Why should you check DevZero out? #

Now, more than ever, we need to be efficient in our software development processes and operations. This is how we best serve our customers and users. We need to iterate on software as fast as possible and remove bottlenecks from our dev processes. These value props span across Software Engineers/Tech leads, Engineering leaders, DevOps/Platform engineers, and Security engineers. Regardless of your role, moving to remote development environments will impact your day-to-day in various positive ways. Let us get past all the frustrations and finally upgrade development from the local laptops.

Will everything be smooth on the first day with a non-existent ramp time? No. Will DevZero ensure that you never have bugs in production again and that your code always does exactly what you intended it to do when you were writing it? No.

You will always need observability - outages will happen. You will fix them. But yes, we will make the development part a hell of a lot faster because even though you’ll be coding in your IDE of choice, you’ll be coding in an environment that matches production. When something doesn’t feel quite right in your environment, we’ll be around to guide you regardless of the time of day. We’ll always be cheering you on from the sidelines as you keep crushing it and building amazing products for your customers.

DevZero isn’t built for the engineer who codes “occasionally” - it’s for those that are curious and like to tinker, for those that love to ship products and bring joy to their users.

‍