What would cloud-native Ruby-on-Rails look like?
- Route handlers mapped to AWS Lambda functions, Google Cloud Functions, and Azure functions.
- An ORM that automatically deploys and migrates AWS RDS, DynamoDB, Google Cloud SQL, and Azure SQL.
- Static files that are uploaded and cached on an automatically provisioned CDN endpoint like AWS CloudFront, Google Cloud CDN, and Azure CDN.
- Deployments that build and package themselves as reproducible Docker containers
- Mailers that automatically configure and send via AWS SES, background jobs that run via ephemeral containers or functions, and more.
Vercel has coined this idea as framework-defined infrastructure, and I think it's directionally the future.
Why now? We saw two downstream effects as the public cloud APIs matured and higher-level abstractions were developed (e.g., Kubernetes, FaaS). The first was serverless primitives (scale-to-zero and elastic scaling), and the second was infrastructure-as-code.
The framework-defined infrastructure uses both to avoid complex state management at the framework level (are there enough individually mapped pieces?) and at the infrastructure level (declarative configuration moves complex state management to the provider).
While framework-defined infrastructure seems like a step in the right direction, I wonder whether it is a net benefit to companies like Vercel or cloud providers like AWS. The age-old question of value creation vs. value capture.
Suppose the infrastructure is serverless, and the mapping from code to infrastructure is already well-defined in an open-source framework or API. What is the developer paying the provider of framework-defined infrastructure? (More in IaC: Strength or Weakness for Cloud Providers?).
Ruby on Rails created immense value for startups (see the list of getting to market with rails), but the authors captured relatively little of it – Tobias Lütke (Shopify) and DHH (Basecamp) indirectly monetized their contributions to Rails through more domain-specific startups.