Serverless: using serverless module for CD

Some time ago I got very excited about Serverless module, which helps with deploying Lambda functions to AWS (well, not only that, but that was my use case). I really liked the tool, it was easy and convenient and got us up to speed quickly. I am of the same opinion today, though there are a few remarks to add after an attempt to use it in our build pipeline.

After initial period of experimentation and rapid development, we got rid of serverless in favor of Terraform and then Ansible.

Those are the reasons:

  • It uses CloudFormation under the hood and attempts to rollback changes if something goes wrong.

In our experience, those rollbacks rarely succeeded, which left us with AWS resources in weird “ghost” state (aws-cli can’t find an object, but serverless cannot recreate it claiming it exists). Probably the most troublesome part of configuration was Kinesis Stream used as a lambda trigger — this association was not getting deleted and caused us to use different names with new deployments: we had lambda-0, lambda-1 etc. Eventually, things would get consistent, but for a frequently run deployment pipeline that was not a behavior we could tolerate.

  • We needed another tool to create other AWS services/resources

There was no point in using two tools, where one would be sufficient.

  • It is a node module

While that’s OK for Lambda functions in Javascript, it gets weird if you use it with Java. Developers get confused about node_modules folder and package.json file in Java project, and we liked the setting in which it’s the project directory that holds deployment configuration as well.

  • It’s slow

That’s probably CloudFormation, not Serverless itself, but we found Serverless to be quite slow compared both to Terraform and Ansible. When we used Serverless-configured packaging, that would also take unreasonably long.

  • It’s young

Even though we tried to cover quite basic configuration scenarios, we encountered a few annoying bugs (for example, passing .jar file in config file would not stop serverless from creating zip with contents of the whole folder). Bugs were fixed quickly, but it still seemed we jumped into it a bit too early.

  • Silent errors in config files

Serverless config is an .yml file. It happened to us a few times that someone mixed the indentation (for example, in “events” section where lambda triggers can be configured). Serverless would not let us know anyhow that there is something wrong, function would deploy successfully without reporting errors only for us to discover that the triggers were not configured so it was not getting called. I would expect the tool to catch such case.

Concluding, serverless is a great tool which will help you experiment with Lambda functions and will stop you from making mess on your AWS account - you can quickly deploy things and quickly remove all associated resources. Documentation is great and initial setup and configuration takes few moments.

It is not that great when used as a part of build pipeline, mainly due to problems with underlying CloudFormation operations and especially often failing automatic rollbacks. Java devs were not happy with the fact that it is distributed as node module, and Ops people were not keen to put up with yet another tool, when deployment of Lambdas could be done with Ansible or Terraform.

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.