Matt Rickard

Share this post

Infrastructure Defined Software

blog.matt-rickard.com

Discover more from Matt Rickard

Thoughts on engineering, startups, and AI.
Continue reading
Sign in

Infrastructure Defined Software

Sep 23, 2022
Share this post

Infrastructure Defined Software

blog.matt-rickard.com
Share

(2006-2010) Cloud increases average fleet size. Machines are difficult to configure at scale. Configure them programmatically, and ensure that they match the master configuration (since sys admins will go and manually change things). Solution? Configuration management tools built around native cloud infrastructure APIs (Puppet 2009, Salt 2011, Ansible 2012).

(2010-2015) Configuration drift of mutable infrastructure is a complex problem. Better cloud primitives (functions, containers, and VM improvements) make it easier to spin up and down ephemeral instances than to manage state (pets vs. cattle). Solution? Declarative templates for cloud infrastructure (e.g., CloudFormation 2011, Terraform 2014).

(2015-2018) Templates are direct reflections of the underlying cloud infrastructure APIs are challenging to write and manage. Templates often get reused, but this is difficult when dealing with a configuration language that (1) isn't typed and (2) has no control flow. Solution? Infrastructure as code (Pulumi, 2017, AWS CDK 2019). Treating infrastructure as code makes it easier to configure, but now infrastructure configuration finds itself in version control, in CI/CD pipelines, and as part of the developer lifecycle.

The next step? AWS CDK and Pulumi let you programmatically configure infrastructure 1:1 with the underlying APIs. But developers often think in patterns. A Fargate deployment usually needs a load balancer in front of it. A static site requires a CDN and object storage. Configuring these things together takes time and domain expertise (in a particular cloud's APIs). The configuration is highly similar across deployments – IAM policies that are needed for one service to talk to another, ports, and other references.

There's already a start to thinking about modules-as-code rather than simple infrastructure. A collection of well-tested interfaces made of different cloud services (see Interface Decomposition in the Cloud). Will it simply be open-source libraries written in Pulumi or AWS CDKs? Will startups ship their modules for self-hosters? Will these modules bankrupt open-source companies (by making it highly trivial to self-host)? Do cloud providers benefit? Is this the abstraction layer that makes AWS a dumb pipe?

Share this post

Infrastructure Defined Software

blog.matt-rickard.com
Share
Previous
Next
Comments
Top
New
Community

No posts

Ready for more?

© 2023 Matt Rickard
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing