Your serverless-first line in the sand

You’re a senior technical decision maker in your organisation. Your knowledge and confidence level with building a serverless application on AWS is now pretty good.

It’s almost time to commit. A time to draw a line in the sand and state explicitly that “from now on all new applications and services that we build will be serverless-first”.

This might sound a little intimidating, inflexible or even dogmatic, but it doesn’t need to be. By adopting a serverless-first mindset, you’re saying that a service with fully/mostly serverless attributes should be the default starting point for each system use case when designing an architecture. But if it proves that another non-serverless option will result in a better outcome, then that should be selected.

The key thing is establishing a clear, consistent, and well-communicated default way to build going forward.

So what does this look like in practice?

Greenfield systems are certainly easier to begin with. Here are a few practical pledges to get you started:

• All new apps/services get their own AWS account and aren’t lumped in beside existing server-based workloads. This is a key enabler for other items below.
• Everything must now be Infrastructure-as-Code. Easiest way to enforce this is to create a CI/CD pipeline right from the outset of a project which deploys to a fresh environment and runs integration and E2E tests on every merge to mainline. Broken deployments/tests will quickly catch missed IaC.
• Add significant friction to using “non-serverless” cloud services such as EC2, VPC and RDS. Do this by creating a Service Control Policy (SCP) which forbids the creation of such resources in all new AWS accounts. If you really need to use one of these services in the future, you can always amend the policy.
• Employ a NoSQL data modelling approach by default for application databases (DynamoDB by default if on AWS)

If you’ve existing workloads still in active development running on EC2, you probably shouldn’t rewrite them to be serverless, but there are still a few commitments you can make:

• All future cron jobs will be implemented as Lambda functions with an EventBridge schedule rule (see The smallest way to introduce serverless into a brownfield application)
• No new EC2 servers get added to the architecture for new features (not counting auto-scaling group instances here). Find a serverless cloud service that already does what you need or build your own serverless-based microservice for it. Trade-off the upfront hit of now having an extra service to deploy for the longer-term benefit that it will have lower operational cost as well as getting the developers on this team familiar with working with serverless.

Have you made a serverless-first commitment within your team or organisation? If you did, what pushback, if any, did you get? If not, what is holding you back from doing so? Hit reply and let me know.

—Paul