How to succeed with Serverless? Automate best practices
I build, write and talk a lot about Serverless applications. Using AWS Serverless services extensively with my clients and, for many applications, it’s the best technology choice. Serverless adoption continues to grow, but the biggest pain-point for companies adopting Serverless is no longer vendor lock-in or cold-start times, it’s education and upskilling.
People often ask me, how do we find the best practices? Is this best practice? Will this scale? Will I regret this in 6 months?
This is not surprising. Serverless is an extremely powerful and flexible approach to building applications, and best practices continue to evolve.
I, like many in the Serverless community, spend a huge amount of time reading. Jeremy Daly’s newsletter alone takes up an afternoon. Serverless is a steep learning curve and a moving target. It’s a lot to expect teams to follow it closely and apply best practices consistently.
Serverless is a steep learning curve and a moving target
Many companies have gone down the reference component/reference architecture approach, investing a lot of time and resource in building an example application within their organisation with all the best practices baked in. This becomes easier with Serverless as so much of the infrastructure is managed as code. Therefore learnings can be encoded.
The problem is, things change and people make mistakes.
This is not a problem unique to Serverless. It’s why we use static analysis tools, review each other's codes and form guilds around particular topics. It’s also why some companies document their best practices. All of this is useful in helping teams adopt Serverless, but for many, it’s too big an area to cover quickly and they have to build (not read constantly).
That is why today I’m excited to announce the release of a new tool inside the open-source sls-dev-tools project — sls-dev-tools Guardian
What is sls-dev-tools Guardian?
sls-dev-tool’s iconic CLI Dashboard interface, now called sls-dev-tools HQ, is one of several tools in the new sls-dev-tools. Today, it is joined by sls-dev-tools Guardian.
sls-dev-tools Guardian is a highly opinionated, highly configurable, automated best-practice audit tool for Serverless architectures. Like all sls-dev-tools features, it’s framework agnostic (SAM, Serverless Framework…) and can be run in one simple command.
As discussed, Serverless brings a huge amount of abstraction, but there are complexities in building out architectures, and best practices continue to develop. sls-dev-tools Guardian can run locally, on a CI Platform or in a scheduled task to help you build with best practices from day one and resolve problems before they arise.
sls-dev-tools Guardian has a number of best practice rules that will run across architecture resources and configurations. Each rule is documented, in the style of ESLint, with consistent naming conventions and clear steps to resolve issues along with links to useful tools and documentation.
sls-dev-tools Guardian is not a static analysis tool for your code, it’s a dynamic check across your deployed architecture and it’s resources. This means it can make checks agnostic to the infrastructure as code you use.
In beta testing of the tool, users initially relied on it to audit their existing applications as well as adding it as a standard development tool to be run actively by developers. Some users have already integrated it into their CI pipelines, running checks on dedicated non-production environments. It can also be run on production with the same ease.
It is highly opinionated, trying to guide towards best practices. However, each rule can be configured on a resource or global level. These rules, like the whole tool, are open source and built by the community. If you’re missing a rule raise an Issue and we’ll work with you to expand the coverage of the tool. Feedback, improvements and opinions around the existing rules are also very welcome.
Get started with sls-dev-tools Guardian in one command
Install sls-dev-tools in your project or globally using one of the following commands:
- Run
npm install -D sls-dev-toolsoryarn add -D sls-dev-toolsto add the tool to your project (recommended if you’re using sls-dev-tools Guardian) - Alternatively, run
npm install -g sls-dev-toolsto install the tool globally
The sls-dev-tools HQ dashboard is the default behaviour of sls-dev-tools command and is typically run as follows:
sls-dev-tools(interactive configuration)sls-dev-tools [-l {YOUR_PROJECT_LOCATION}] [-p {PROFILE}] [-n {YOUR_STACK_NAME}] [-r {YOUR_REGION}] [-t {START_TIME}] [-i {INTERVAL}]
To run sls-dev-tools Guardian use the same command structure, but pass the — ci option:
sls-dev-tools --ci [-l {YOUR_PROJECT_LOCATION}] [-p {PROFILE}] [-n {YOUR_STACK_NAME}] [-r {YOUR_REGION}] [-t {START_TIME}] [-i {INTERVAL}]
The analysis will then be run with a high-level summary and a detailed breakdown of failing resources with a direct link to the rule documentation. The exit code will be 1 if any rule is failing.
Understanding the rules
Each rule in sls-dev-tools follows a consistent naming convention. If a rule fails, the list of resources failing the rule is displayed in a table along with a link to the rule page. This rule page details the reasons and impacts behind the rule, along with actionable steps and tools to fix the issue.
Configuring Rules
sls-dev-tools Guardian is intended to be opinionated, but when that opinion does not match your expectations rules can be ignored on a per resource or global level.
To ignore a rule add a guardian section to your slsdevtools.config.js file (create a new one at the same directory level as your IaC root).
module.exports = {
...,
guardian: {
ignore: {
"no-max-memory": true, // global
"no-max-memory": ["arn-1234"] // per resource
"no-max-memory": "1 May 2020 09:00 GMT" // ignore till then
}
}
};Rules can be ignored globally, per resource or until a specific date (e.g. delay checking this for 1 month).
Contributing Rules
This is an initial set of best practice checks we’ve implemented that we feel are ready for public release. If you have other ideas for rules we are missing open an issue on the repo and we can work to get it integrated.
The aim is to be an opensource set of automated checks by the community, for the community.
We see automation of best practice checks as the key to success with adopting and keeping up to date with Serverless, and sls-dev-tools Guardian as the tool to do it.
If you’ve not checked out the sls-dev-tools project yet take a look here:
It’s completely open-source and sls-dev-tools Guardian is just one tool. One npm install gives you the full toolkit, so you can run sls-dev-tools HQ and sls-dev-tools Guardian from one command.
sls-dev-tools Guardian is a highly opinionated, highly configurable, automated best-practice audit tool for Serverless architectures. Like all sls-dev-tools it’s framework agnostic (SAM, Serverless Framework…) and can be run in one simple command.
If you’re an sls-dev-tools fan, please drop us a ⭐️on GitHub, Open Issues on GitHub with feedback and Follow us on Twitter
Serverless Transformation is a Theodo initiative. Theodo helps companies leverage Serverless through expert delivery and training teams.
Learn more about Theodo and speak to one of our teams today!
If you like content like this consider subscribing to our weekly newsletter!
