Where Serverless plugin stops and platform starts

You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!

I’m a long-time user of the Serverless framework and a big fan of its plugin system. It offers tremendous flexibility and there exists a rich ecosystem of community-driven plugins. It’s easily the Serverless framework’s greatest strength and the reason why I keep going back to it.

However, I have observed a common pattern where customers would overextend the use of plugins. A typical example is using plugins to manage log subscriptions for log aggregation.

Centralised logging is a “centralised decision” that applies to all your serverless projects. What logging service do you use? How do you ship the logs from CloudWatch to that service? Do you use Lambda directly or proxy through a Kinesis stream first?

Executing this decision at the project level has some problems:

  • Copy-and-paste configuration in every serverless.yml. It’s laborious and difficult to enforce consistency in a large organization.
  • It’s difficult and risky to change that decision later. You’d need to do a coordinated rollout of every project to every environment.

Instead, for decisions that apply to ALL projects, you should build them into your platform. And by “platform”, I mean a collection of capabilities that are implemented once per account or region.

Capabilities such as:

  • logs would be delivered to your chosen logging service, be it Elasticsearch, Logz.io, Loggly, NewRelic or whatever it might be.
  • log retention policies are configured to X days to reduce storage cost.
  • functions can record custom metrics with StatsD format log messages.
  • CloudFormation tags are propagated to all resources to enable better cost tracking.

But not all decisions are applicable to all your projects. Decisions that are specific to one project, or need to be tailored for each project, should be implemented at the project level. Plugins are a good way to implement these decisions.

For instance, serverless-webpack makes it easy for you to use webpack to bundle and minimize your deployment artefact. It can have a big impact on reducing the cold start duration of your function too.

The decision to use webpack is specific to one project. It’s a decision based on the needs of that project. For example, you’re building a user-facing API using Node.js, so you care about cold start durations.

How do you implement such a platform?

In the simplest form, you can implement it using two CloudFormation templates:

  • an account template for account level resources such as IAM roles, CloudTrail and S3 bucket, etc.
  • a region template for regional resources such as VPCs, security groups, etc.

This approach is likely sufficient for a small startup. But it’s not going to scale for Enterprises, where you have many teams and complex security and compliance requirements. That’s where AWS Control Tower comes in.

Control Tower lets you template the baseline configuration for new accounts. You can then use the account factory to quickly provision them. If you’re new to Control Tower, then check out this session from re:inforce 2019.

The Serverless Application Repository (SAR) is a good way to make reusable components that can be plugged into your platform. Here are some SAR apps that I have published to implement platform-level capabilities:

  • lambda-janitor: cron job to delete old, unused versions of all Lambda functions in the region to free up storage space.
  • auto-subscribe-log-group-to-arn: subscribes new and existing CloudWatch log groups to a Lambda function, Kinesis stream, or Firehose delivery stream by ARN.
  • auto-set-log-group-retention: updates the retention policy for new and existing CloudWatch log groups to a specified number of days to reduce CloudWatch Logs cost.
  • async-custom-metrics: lets you record custom metrics by writing to stdout (which is recorded in CloudWatch Logs) which is then parsed and forwarded to CloudWatch metrics as custom metrics.
  • propagate-cfn-tags: propagates CloudFormation tags to resources that are not automatically tagged, e.g. CloudWatch log groups.
  • autodeploy-layer: automatically deploys a Lambda layer to all new and existing functions in the region. Supports opt-in and opt-out via function tags.

The Serverless framework has also introduced Serverless Components. It is an alternative to SAR for building reusable and composable applications. But since it’s specific to the Serverless framework, you won’t be able to use it with Control Tower’s account factory. Because account factory relies on AWS Service Catalog and CloudFormation.

Summary

In summary, the rule of thumb is:

  • If the capability is universal and should apply to all of your serverless projects, then build it into your platform.
  • Otherwise, use a plugin to implement capabilities that are required at a project-by-project basis.

References

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter


Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.


Skill up your serverless game with this hands-on workshop.

My 4-week Production-Ready Serverless online workshop is back!

This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.

We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.

If you enrol now you can also get 15% OFF with the promo code “yanprs15”.

Enrol now and SAVE 15%.


Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.


Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!


Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!