Infrastructure-from-Code vs Infrastructure-as-Code

I frequently discuss Infrastructure-as-Code in these emails and I’m sure almost all of you understand what it is.

But a new emerging concept that you may not have heard of is Infrastructure-from-Code. I first heard of this term used by Jeremy Daly and the team at Serverless Cloud, so I’ll credit them with coining the term.

Infrastructure-from-Code is a way of creating applications such that, at deploy-time, your cloud provider inspects your application code and then automatically takes care of provisioning whatever underlying infrastructure your application code needs. This contrasts to Infrastructure-as-Code where you (the developer) need to explicitly define infrastructure resources in separate files, say within CloudFormation/Serverless Framework YAML or CDK stacks.

IfC tools will do this by looking for conventions and hints within your application code files. Let’s look at an example from the Serverless Cloud docs:

import { api, data } from '@serverless/cloud'

api.post('/users', async (req,res) => {
	await data.set(`users:${req.body.email}`, req.body)
	res.send({ message: 'User saved' })
})

Whenever you deploy the above code using the Serverless Cloud CLI, its hosted service detects the api and data constructs and understands that it needs to provision API and Data resources under the hood. I believe they use API Gateway and DynamoDB within AWS under-the-hood for these respectively, but the developer doesn’t need to know this, nor bother with the complex configuration (IAM, etc) that can come with using these resources.

The obvious major benefit of this is that it’s much less code to write and reduces or altogether removes the need to learn IaC languages such as CloudFormation, which many developers new to serverless cite as a significant learning curve. In his article on The Self-Provisioning Runtime, Shawn Swyx Wang states:

“If the Platonic ideal of Developer Experience is a world where you ‘Just Write Business Logic’, the logical endgame is a language+infrastructure combination that figures out everything else.”

I agree that this approach will be the future of application development. But that endgame may still be a few years away and my one concern in the short-term is the lack of flexibility that comes with this implicit conventional approach. Say I need to use a cloud service that isn’t supported yet or make changes to a setting of an underlying primitive that hasn’t been exposed. Or if I need to eject altogether, my app is completely written using proprietary constructs. I do think the vendor lock-in argument holds more weight for smaller cloud players compared to the AWS/Azure/GCP giants.

But as the feature set and capabilities of Infrastructure-from-Code tools such as Serverless Cloud grow, some of these concerns will decrease and who knows, maybe even some standards will emerge!

— Paul