The Rise of Developer Infrastructure
May 18, 2022
We have a theory about what’s going on with developer infrastructure:
- The most successful engineering organizations in the industry have invested heavily in internal developer infrastructure, which has given them a differentiated advantage when it comes to constant innovation and speed of shipping products.
- The next 10 years will see the majority of developers shifting from using cloud infrastructure to using developer infrastructure
- Composable, Extensible and Usable: these will be the guiding principles for great developer experience.
Dev infrastructure can be a bit of a fuzzy gray area, but we define it as the tooling which forms the connective tissue between your application code and your cloud primitives. Your cloud provider defines the limit of what’s computationally possible, your application code determines the particular what you’re focused on, and your developer infrastructure determines how quickly you're able to get your application code running in production and how well you can maintain it atop primitives from your cloud provider.
When it comes to sustained innovation in software development, good developer infrastructure is the secret weapon that gives the best companies a head start on their competition. It’s not often talked about because it’s often not the shiny apps your customers use, but it is critically important to velocity and quality. Developer infrastructure is a lot like public infrastructure: when it’s working well you forget it’s there, but when it’s not working, you’ve got yourself a major problem.
when it’s not working, you’ve got yourself a major problem
Over the last 10 years, developers at smaller companies have struggled to balance developing innovative apps while also managing the complexity of the cloud. Meanwhile, companies like Uber, Airbnb, Stripe, Netflix et al. have been able to invest heavily to build up in-house platform teams, which supports the continued productivity of their application developers. Some of the developer infrastructure those teams created were shared publicly. Two well knowns that I’ve personally adopted in high scale settings are:
- Kubernetes (opens in a new tab) - The now ubiquitous container deployment and orchestration system was born from Google’s famous internal Borg (opens in a new tab) system which provided abstractions for resource allocation. For most (stateless) use cases devs were able to “submit” a container and let K8’s handle how it got running on VMs. Needless to say there is now a massive ecosystem in continuous evolution around K8s.
- Spinnaker (opens in a new tab) - There were plenty of ways to build and deploy containers independently but they all required you to manage your own workflow. This meant brittle scripts, triggers, sometimes complete bespoke stacks maintained by internal teams. Spinnaker solved this with an orchestration first approach - a developer could string together many different steps which could live across team and system boundaries. Since then we’ve seen an explosion in this space (opens in a new tab).
Each of these was enthusiastically adopted by the developer community. At the time of their release, they each represented massive improvements over the status quo.
Yet, this wasn’t the end of the story. There were some issues. First off, it wasn’t sustainable for devs to continue to rely on larger companies sporadically open sourcing their tools. Increasingly ambitious business growth targets meant that devs needed consistent innovation of tooling to enable them to build more, faster. And more importantly, the tools had been developed by large organizations with huge dedicated platform functions; they weren’t optimized for application developers operating at a smaller scale without robust dev ops support. Simply stated, though the tools were powerful, they lacked a great dev experience. App devs were still having to go down the dev ops rabbit hole, spending far too much time trying to figure how to secure, deploy, and maintain their applications.
The way developers interact with the cloud is undergoing a profound shift, Erik Bernhardsson described it well in one of his recent blog posts, “Storm brewing in the stratosphere (opens in a new tab)”. The last 10 years were the initial phase of the cloud movement - shifting your compute and storage from your own server racks to those maintained by a commoditized public cloud. Now we are in the early days of the second phase - the abstraction of the cloud in order to undo the productivity loss caused by dev ops being splattered across the stack. We are pushing towards a future where every App and API dev will launch their product by focusing on the application primitives while maintaining the benefits of public cloud elasticity.
That’s why we’re beginning to see the paradigm start to shift. As the cloud has matured, we are now beginning to see the development of dev infra atop the underlying cloud primitives. Some of the biggest drivers for this shift are:
- The desire for great UX: Developers now expect their tools to not only be powerful, but also to be usable. A great UX means more personas in the org can insert themselves into the development loop, increasing leverage for the devs. A great dev tool is not only great UX but also great dev ex, as we explore below.
- The focus on differentiation: Developer time has never been in higher demand. Businesses need to focus the efforts of their developers on solving the problems that differentiate their business. Everything non-mission critical, wherever possible, should be handled by a 3rd party. Tools that take unnecessary tasks out of development and deployment are invaluable.
- The dev infra gold rush: The market is awash in solutions as startups armed with VC cash have rushed in to fill the need for cloud products with dev experience as the primary differentiator. For a dev looking to plug a gap in their development lifecycle or offload non-core work with 3rd party tooling, there have never been more options.
- Multi-Cloud: As organizations begin to consider the implications of cloud lock in, it becomes critical that their dev tooling remains consistent across platforms. Optimizing an application for multiple clouds is a vastly inefficient use of developer time. Dev infra developed by cloud vendors is typically limited to just their cloud and vertically integrated.
Cloud platforms rooted in developer productivity have seen rapid growth in the last few years. One of my favorite dev ex innovations recently is PlanetScale’s Revert (opens in a new tab) feature. A mention of database migrations can invoke anxiety in the most battle-hardened devs. Commit a stateless SQL file to manage a production database? No thank you! Another noteworthy mention is Cloudflare open sourcing their Workers runtime (opens in a new tab) - Devs can now deploy fullstack apps serverless-ly on the edge with just a click and with full transparency, amazing ! As this trend continues, the leverage of each developer will soar. For the majority of teams, dev ops will be a distant memory. We’re approaching the inflection point.
Companies like PlanetScale and Cloudflare are at the tip of the iceberg. The community of independent dev tool companies has really begun to blossom in the last few years. The cloud providers commoditized access to secure, reliable, scalable server capacity, This, in turn has provided the foundation required for dev infra companies 100% focused on building tools with a great dev experience to be viable.
As to what constitutes a great developer experience, it’s still early days so there aren’t many resources. However, when we’re building our tools, we grade our work against our developer experience pyramid:
The Dev Ex Pyramid
- Usable - An individual dev or team should be able to find the tool, set it up, and start using it without barriers or issues in 30 minutes.
- Composable - The tool should be modular enough for developers to slot it into their (probably complex) environments. Support for multiple frameworks and integrations is key to adoption.
- Extensible - Although most developers will only ever scratch the surface of a tool’s functionality, every tool will have its power users. Power users should be able to add functionality to the tool, for advanced use cases.
**Cloud Infrastructure (**These are table stakes!)
- Scalable - Able to elastically scale compute to the needs of the application.
- Reliable - This one is pretty easy. If a tool doesn’t have 99.99% reliability, then people won’t use it. If you are building infrastructure, you have to be dependable.
- Secure - You cannot jeopardize your client’s security. Your tools must be water tight. For us this means running within our client’s cloud environment and minimizing any external network communication.
We constructed this pyramid based on our experience working on enterprise software, and the things we valued in the tools we used. We would love to hear from other developers to see if this is in line with what they think is important. Are there things we’ve missed? We’d love to know.
The future of dev infra is bright, and we look forward to making our contribution. For any devs who want to pitch in and help us build great infra for the developer community, please check out the job board. We would love to hear from you! (opens in a new tab)