In 2018, I wrote a series of posts about my experience working AWS Serverless for a global high volume public facing web application. It took us about a year and a half, about 15 software engineers, and a lot of stumbling to get it working. In 2016, when we started, AWS Serverless was newish. The community was abuzz about how cool it was. The Serverless Framework was the only real tool that developers could use. There were just no examples in the wild. At FastUp we continue to develop business applications on the AWS Serverless stack of API Gateways, Lambda and Dynamo Database. In this post I am going to cover how our approach to building and deploying Serverless has changed over the years.


AWS SAM was first released in Aug 2017!

sam release png

In 2017, there was no AWS SAM CLI. It was first released in Aug 2017. Until then, we wrote code in the language of our choice, wrote the instructions to build it and used cloudformation to deploy it. Now, SAM has come a long way. SAM allows developers to write code, test it on the local workstation as if it is running in a lambda function and debug it locally.

sam local invoke

Serverless as Code

In 2017, API Gateways, API Deployments, Domain Names, API Keys, Lambda Functions all of those had to be crafted in Cloudformation. Now, SAM provides for event configurations on Serverless Functions and custom API settings on API Gateways.

Serverless API customization


In 2017, each time we wanted to deploy a new version of the lambda function with ability to rollback at will, we would have to create new versions of a deployed lambda function, alias them and integrate them with api gateway - all of these separately. Additionally, we would handcraft an API Deployment to a stage of our choice in long cloudformation scripts. There was not an easy way to manage and control deployments other than making someone responsible for it.

The biggest step forward in this space is AWS multi-account design. Using multiple accounts, we can now deploy versions in dedicated accounts. This eases the burden of managing and controlling dev vs prod environments. Secondly, SAM introduced a few constructs to enable automated version upgrades and downgrades. However, I fee like it is hard to be prescriptive in this area. Each customer has their own requirements of management and control. AWS could improve SAM around how it deploys artifact versions across accounts.

Cloudwatch Logs and Metrics

In 2017, we did not have logs insights and metric math. This means it was necessary to stream all cloudwatch logs into a visualization and search tool such as ELK. Now, cloudwatch logs insights allows search natively in AWS. Metric math allows us to react to percentage degradations in service rather than jumping out of our seats for each error.

In-VPC improvements

Everyone hates cold starts. In my experience, this is still a problem, however, it has been eased greatly. I remember our QA complaining that they have to wait almost 30 seconds for the UI to respond when the came in every day and at the same time failing to prove any performance issues in formal load tests (HA!).

What is still missing

  1. Ability to deploy and rollback specific apis without configuring too much cloudformation.
  2. Ability to deploy a single binary in multiple accounts without having to rebuild functions (and thus losing traceability)

I have had this conversation before. The problems are not with capability of the platform. I would say that AWS Serverless is highly configurable and can fulfill almost any traditional use case. I think the problems are related to enterprise friendliness.


I have seen first hand that AWS Serverless has improved vastly over last 4 years. I feel like AWS will continue to invest in this direction and make it even more enterprise friendly than it is. Some research organizations have predicted a very high growth rate for serverless over next few years. I can see why and I can only wait excitedly.