The Cattle, Not Pets analogy has been espousing the disposability of servers notion since the early days of the cloud revolution. Treat your infrastructure as cattle: design for failure, automate deployment, and when things go wrong with a server, take it out in the back, shoot it, and replace it with another one on the line. Contrastingly, servers treated like pets seek painstaking care: they are manually built, irreplaceable and often christened with cute names.


The cattle approach, that Google in fact pioneered, has been bearing fruits of scalability and manageability of application infrastructure for teams across the board. Engineers today are armed with an arsenal of tools that allow them to weave together compute, network and storage infrastructure in an abstract (albeit opinionated) fashion. As a corollary, teams don’t concern themselves with the gory details of where their code is running, but can indeed turn their focus to what they do best - write application code!

Developer infrastructure, however, hasn’t fundamentally changed since we shifted from developing on giant room-sized mainframes to developing on compact personal machines. Sure, our laptops pack a considerably meaner punch than they did decades ago, but the innovation has largely been incremental. Embarrassingly, we continue to struggle with the same age old problems such as the abhorrent “but it works on my machine” phenomenon that pervades even the best of teams. On-boarding new members still comes with the unnecessary friction of manually setting up environments. Version conflicts are not infrequent.

That’s not to say the future looks grim; a fundamental shift in the way we do things is indeed underway. The explosion of Docker and orchestration tools like Kubernetes has opened up new doors and container technology has been progressively making deep in-roads into every facet of the development life-cycle.

State of the Art

Today, engineers are equipped with environments that are identical to the ones that run on production servers. On their local machine, a developer typically spawns an instance of a custom-built image downloaded from a remote repository. This image (which is the environment) is configured with just the right amount - and the right versions - of dependencies required to compile and run the application code. When the CI eventually takes the code to production, a similar image retaining only the runtime dependencies is spawned to execute it. Since everyone works on a unified environment, most of the conventional problems are mitigated.

This is great - but why stop at that?

The Modern Approach

If teams have embraced this unified approach to developer environments, why not go one step further and provision them on shared infrastructure to benefit from economies of scale? The power of the cloud at the developer’s fingertips! Environments can be spawned at will, utilized, and discarded when the developer logs off. (Of course, persisting state somehow).

Treat the modern developer infrastructure as cattle, not pets.

Notably, our existing developer tooling would have to be minimally disrupted for this transition. We spend most of our time on our beloved editors - every extension, theme and font tuned to perfection. Departing from our sanctum sanctorum would be desecration. Our cattle would at least need to provide the illusion of being a pet.

Microsoft demonstrated a somewhat bare-bones version of this capability with Remote Development on VS Code (Remote - Containers). Essentially, a component of VSCode runs inside a docker container as a server, and the UI component connects to it from the host machine. The terminal processes, extensions and debuggers run inside the container - which could be hosted anywhere on the network - while the UI is rendered on the developer’s machine.

Such a technology could form the bedrock of more complex systems that realize the notion of disposable environments. Picture a fully managed developer infrastructure platform that provides teams with the capability of curating and deploying environments in the cloud!


In fact, GitHub announced CodeSpaces: a feature so magical and game changing, it’s hard to underscore its true potential. At the click of a button, a developer can spin-up instant dev environments with all the dependencies the repository needs and work entirely on the cloud. Not only does it provide a VSCode like experience in the browser, but one can connect to it from a full installation of VSCode as well!

While GitHub has the advantage of being the destination for source code, making it an easy choice for a number of teams, other solutions may offer more advanced features. For instance, Koding takes a less opinionated approach and allows configuration of powerful dev-environments on any cloud provider. This could be suitable for teams seeking finer-grained customization.

Indeed, these advances paint a promising future. Fiscally speaking, the economies of scale realized as we move towards environments on shared infrastructure will bring down costs. For startups and smaller enterprises with “Bring Your Own Device” policies, unified virtual environments would break down most compatibility related barriers. Further, global availability of these environments would also benefit teams distributed across continents.

In an ironic way, this is a modern revival of the mainframe way of doing things.