Use Continuous Deployment as an accelerator to learning serverless

When I’m working with a client development team that is new to serverless, I strongly encourage the practices of Continuous Integration (ideally through trunk-based development) and a fully automated Continuous Deployment pipeline through to production. This can often make teams a little uncomfortable as these practices are often something else that’s new to them and can seem “risky”.

While these DevOps concepts have been around for ages and are not specific in any way to serverless, they have the side-benefit of greatly accelerating learning of the serverless landscape for the developers on the team. My goal when working with a client team is to make them self-sufficient as soon as possible. And while I can point them in the way of documentation and training materials, it’s not until the rubber hits the road and they’re forced to implement and deploy features—and resolve any issues which ensue—when the real learning starts.

With serverless architectures, application developers typically have a wider responsibility than they were used to in server-based architectures. In the past, they may have been used to an Infrastructure or DevOps engineer taking their application code and deploying it to staging and production environments for them. Their job is now more than just implementing the application code in their favourite imperative programming language. This is undoubtedly a good thing given the autonomy and flow it can bring, but it does take a little getting used to.

Left alone, developers at the start of a new project may retreat to the perceived comfort of working in local branches and not merging for days or weeks. By instead introducing the healthy pressure of practising continuous integration and having their changes run through a CD pipeline, areas they don’t understand or missed are quickly flushed out. In particular, I’ve seen it really help with the following:

• Ensuring that all cloud resources are managed via Infrastructure-as-Code and not by point-and-clicking in the AWS Console in the dev account
• Ensuring that configuration settings—environment variables or SSM Parameter Store values—are set correctly
• Ensuring that post-deployment integration and E2E tests have been run and no regressions have been introduced

If you’re trying to introduce serverless onto a team on a greenfield project, I strongly recommend practising CI with a fully automated Continuous Deployment pipeline. Not only will you get the generally acknowledged and statistically proven benefits of these practices, but it will also bring much accelerated learning of this new serverless world to your team.

(And if you need help putting any of this in place, there are a few different ways that I could help you, just drop me a reply.)

— Paul