The first edition was published in 2020, and with the pace of change being as brutal and unforgiving as it is, I started making notes for the second edition within a month of finishing the manuscript. The overall structure has remained the same, but I go far deeper into the different topics in the 2nd edition. There are also more visuals and a couple of new topics. This series of articles provides a summary of each of the chapters with some personal afterthoughts. Serverless Beyond the Buzzword 2nd edition can be purchased here: https://link.springer.com/book/10.1007/978-1-4842-8761-3
Written article continues below the video
This is one of the largest chapters and covers DevOps basics, infrastructure as code, several tools and frameworks for development, and ways of working that are more productive for Serverless architecture.
The word DevOps is simply short for development and operations. It is more appropriate to call it a cultural movement by development teams than a framework or methodology. This cultural movement aims to enhance the collaboration between, or even merge, two departments involved in digital projects. This helps application changes get into production faster and more frequently while maintaining, or even improving, sustainability and scalability.
Infrastructure as Code (IaC)
Without IaC, DevOps would be considerably less effective. It is a crucial component for automating the consistent provisioning of cloud infrastructure. IaC templates describe the cloud services we want to provision with the configuration, permissions, and integrations. This approach is better than using the cloud UI and clicking through the different options for reasons we will cover next.
Launching a single server via the cloud interface is simple; it only takes a few clicks. However, an average Serverless application might have more than fifty microservices, ten supporting services, and all their integrations and permissions. It is considerably harder and more error-prone to provision these components manually one by one via the interface - especially if you want to consistently deploy the same set of components into multiple environments or regions.
AWS CloudFormation
The native IaC option on AWS is CloudFormation, a service provided and fully managed by AWS and well-integrated with the platform. This service is free to use, but you will need to pay for the services your CloudFormation templates provision. With CloudFormation, you can create reusable templates for provisioning cloud services and deploy them across multiple accounts, regions, and environments with predictable and consistent results.
When your template is run through the CloudFormation service, it creates a stack. A stack contains all of the associated resources that this template has provisioned. In the event of deployment failure, CloudFormation will automatically roll back to the previous working version, preventing a live application from breaking. As with most IaC tools, you can quickly delete a stack, removing all associated resources.
Hashicorp Terraform
Terraform is a third-party open-source IaC tool. It can provision infrastructure into many cloud providers and SaaS solutions such as DataDog, VMWare, Kubernetes, and Heroku. While the Terraform engine is cloud-agnostic, the individual templates are not. Each template uses the configuration and naming conventions that the targeted cloud platform expects. This means that a template written for AWS services will need to be re-written for resources in another cloud provider, such as Google Cloud.
Tools and frameworks
AWS Serverless Application Model (SAM)
AWS Serverless Application Model or SAM is an open-source framework for building Serverless applications on AWS. It is an abstraction of CloudFormation that makes it easier to provision Serverless architecture. The IaC templates can be smaller, and the framework will add the remaining details using defaults and best practices to generate the full CloudFormation template. Like CloudFormation, SAM is free to use, but the provisioned resources are billable.
Amplify
Amplify is another AWS tool and service that can be used to provision cloud resources. Amplify is intended for less technical users and simpler applications compared to the other tools. More of the infrastructure and configuration is automated with defaults behind the scenes making it well-suited to front-end and mobile developers looking for an easy way to create back-ends for their applications.
Cloud Development Kit (CDK)
CDK is an IaC framework released and open-sourced by AWS. Built on top of CloudFormation, it can achieve everything that CloudFormation can and more. Instead of developers learning a template syntax or being restricted by the limited capabilities of templates, they can use a full programming language to design and provision cloud infrastructure. The framework enables the creation, configuration, and deployment of cloud services using common programming languages such as JavaScript and Python. Full programming languages enable developers to utilise built-in capabilities such as loops, objects, classes, and functions to better automate and define infrastructure.
LocalStack
A useful tool for local testing is an open-source project called LocalStack. This AWS service emulator enables the provisioning of AWS services locally. The free, open-source version supports core Cloud APIs such as Lambda, API Gateway, and S3.
AWS CodeGuru
AWS CodeGuru is a code analysis tool that supports Java and Python programming languages. It automates code reviews and optimises application performance using machine learning to identify critical defects and any deviation from coding best practices. It scans through the source code repository to find lines of code that can be optimised to reduce resource requirements and costs. It can also be used for continuous monitoring to detect any operational issues and provide recommendations for resolving them.
Multi-repo
One more area this chapter covers is code repositories. With server-based applications, the entire application typically sits in a single repo. With serverless, we want to use multi-repo. This means that each serverless component, such as a microservice, sits in its own repo. From there, It can be independently accessed, worked on, and deployed. Like security in Serverless, this provides a far more fine-grained level of control over the application.
Check out the book's mini site for more information and ordering here: https://serverlessbook.co