DevOps in a Serverless Environment: 7 Best Practices

DevOps isn’t one size fits all. Instead, it’s tailored to the specific environment that it serves. No two DevOps implementations will likely be the same.

For instance, a serverless environment and implementation will require DevOps processes that are significantly different from those that will best serve a monolithic application. When you think about this, it makes sense — we’re talking about the deployment of many serverless services and microservices vs. a single application.

In light of that, it might seem strange then to be talking about best practices. Best practices, however, can apply across environments but can and should be tailored to each implementation. It’s like obeying the spirit of the law instead of the letter of the law. To get the most out of your serverless DevOps processes, adopt these best practices in concept, and adapt them to your own environment.

‍

7 Best Practices of DevOps in a Serverless Environment

Define the Process Before Implementing It

Your DevOps process should be treated with the same care that any other project gets — and that means defining it before you try and implement it. This way, you’ll create a reliable process that answers both the stakeholders’ needs and creates an optimal developer experience.

Creating your DevOps process should follow a standard project lifecycle, beginning with planning, including requirements gathering and discovery. From there, you can move on to the design, implementation, testing, and deployment of the process.

Part of planning and design means taking the environment itself into consideration. Be sure your process can scale with a serverless footprint. Also, make sure to include your stakeholders and end-users — the developers — as you work through your process workflows. An effective process works for all parties involved.

Document the Solution

Documenting your DevOps process is critical to success. For instance, what you see in the diagram below represents a tried and true DevOps process that has worked in real serverless environments. Documenting in as much detail as possible will help provide clarity and streamlines getting buy-in from impacted teams.

An important element to include is the onboarding of new microservices so that developers understand what the process requires from them. This onboarding documentation could consist of:

• Playbooks
• Checklists
• Templates
• Any other documentation that makes the processes consistent and repeatable

The goal here is to simplify the development of new serverless services for your developers.

If you’re really trying to make developers your best friend, consider creating AWS Lambda folder structure templates along with turnkey solutions that developers don’t have to think about to integrate with. These templates can be used as a boilerplate for all developers to speed development. Some things you might consider creating templates for include:

• Folder structure
• Build file location
• Location of supporting DevOps files like deploy scripts

Use Source Control and a Good Branching Model

Our diagram above includes branching and source control within the process, and for a good reason. Using these tools is key to a successful DevOps process.

The source code tools you choose should fit into what the developers are already used to using. GitFlow is a tried and true tool that works well and can be adapted to match your use cases. Since many developers are already familiar with Git, using it improves the developer experience.

Of course, using source control is also a best practice for traditional reasons, including tracking code and branches. It also helps to limit mistakes in code. Source code tools can help you enforce process rules, like code reviews and unit test coverage, among others.

Branching strategies in a serverless environment are also important. Using a single repository for many microservices or a new repository for each of them depends on your expectations around the volume of microservices you’ll be managing.

One repository for many microservices is an appropriate choice to contain your entire codebase within the repository. This is easier to maintain than your other option.

There are good reasons, though, to choose one repository for each microservice. This branching model makes it easier to separate code and to deploy code individually. However, it does make it difficult to maintain when you have hundreds or even thousands of microservices and, by extension, repositories.

We recommend using one repository per microservice, but only if your serverless footprint won’t grow to thousands of services. This is the best scenario for deploying services individually and separates the codebases for the developers.

If, however, individual repositories aren’t feasible, consider a hybrid model. With this strategy, you combine related serverless services into one repository based on individual application components. For example, you may have a connector that is made up of five AWS Lambdas — combining these into a single repository rather than five separate repositories puts like with like and can be a good hybrid strategy with the right balance.

Use Automation

Of course, a best practices list for DevOps wouldn’t be complete without talking about leveraging automation. Your DevOps process should automate as much as is appropriate and feasible.

Automation tasks can include:

• Deployments
• QA
• Security checks

Take the time, however, to build alerts into the automation process. Proper alerts prevent the DevOps team from monitoring everything manually and can be highly informative and helpful in troubleshooting issues.

CI/CD in the Lower Environments, Manual Approvals for Production

Continuous deployment in lower environments is a great way to accelerate the process. If a dev or test environment breaks due to a bad code release, no one will be overly concerned. If production breaks, however, you could have a full-blown incident on your hands.

Instead, keep CD to the lower environments and add manual approvals for production deployments. A Change Advisory Board (CAB) can be implemented for production-level approvals and is a common strategy. The CAB can line up deployments based on the approvals and with the organization’s mandates, like production deployments happen on Tuesdays or other such rules.

When approving production deployments in a serverless environment, you can deploy all changes at once, one at a time, or deploy in chunks. The manual approval and the process allow you to dictate what gets deployed when.

Use Infrastructure as Code as Much as Possible

To put it plainly, it would be tough to manage a sizeable serverless footprint without using Infrastructure as Code (IaC). IaC is self-documenting, ensuring that all of your growing serverless services are documented, and it’s a key enabler of automated deployments.

As you can see in the code snippet below, the self-documenting nature of IaC is very obvious. You can clearly see an AWS Lambda defined, a Lambda trigger, and an SQS queue. Using IaC forces DevOps engineers to document the serverless services, and creates a repeatable script to easily deploy them as well.

HELLOWORLDLAMBDA:
TYPE: AWS::LAMBDA::FUNCTION
PROPERTIES:
RUNTIME: NODEJS12.X
ROLE: !GETATT DEFAULTLAMBDAROLE.ARN
HANDLER: SRC/HELLO-WORLD.HANDLER
CODE: ./SRC/HELLO-WORLD.JS
MEMORYSIZE: !REF LAMBDASIZE
HELLOWORLDLAMBDASQSTRIGGER:
TYPE: AWS::LAMBDA::EVENTSOURCEMAPPING
DEPENDSON: DEFAULTLAMBDAROLE
PROPERTIES:
BATCHSIZE: 10
EVENTSOURCEARN: !GETATTHELLOWORLDQUEUE.ARN
FUNCTIONNAME: !GETATTHELLOWORLDLAMBDA.ARN
ENABLED: TRUE
HELLOWORLDQUEUE:
TYPE: AWS::SQS::QUEUE

There are several different options for implementing IaC:

• CloudFormation: AWS CloudFormation templates describe resources and dependencies for stack deployments
• SAM: Serverless Application Model (SAM) is an open-source framework used for IaC
• Serverless Framework: Another open-source framework for IaC, written in Node.js for AWS Lambda
• Terraform: A multi-cloud tool for IaC

And there are many others as well. Whatever the tool, IaC is critical to the success of an ever-growing serverless footprint.

Review Measures and Goals

While we’ve already talked about the importance of measurement and goals when we looked at common blind spots, it also belongs in any list of best practices for serverless DevOps.

Before implementation, get baseline measurements of all-important benchmarks and KPIs. During planning and design, you should also be defining the goals for your serverless implementation. What does success look like? How will you know — and how will you prove — that what you’re doing is helpful for the organization?

Taking a baseline isn’t enough. Once implementation is completed and after each iteration, review your metrics. A few measurements to include might be:

• Number of rollbacks
• Deployment success
• Deployment time
• Bugs caught in QA
• Downtime
• Etc.

These metrics shouldn’t just sit in your back pocket, however. Data is worth a thousand words to communicate the success of your serverless DevOps implementation effectively. Showing positive results will help to create a culture of DevOps within your organization better than anything else you could do.

These best practices are a roadmap for what should be included in your implementation. You should take them and adapt them to your environment and situation. If you have questions on how best to apply DevOps and the right version of these best practices to your serverless implementation, let us know.