Book Image

Hands-On Serverless Applications with Go

By : Mohamed Labouardy
Book Image

Hands-On Serverless Applications with Go

By: Mohamed Labouardy

Overview of this book

Serverless architecture is popular in the tech community due to AWS Lambda. Go is simple to learn, straightforward to work with, and easy to read for other developers; and now it's been heralded as a supported language for AWS Lambda. This book is your optimal guide to designing a Go serverless application and deploying it to Lambda. This book starts with a quick introduction to the world of serverless architecture and its benefits, and then delves into AWS Lambda using practical examples. You'll then learn how to design and build a production-ready application in Go using AWS serverless services with zero upfront infrastructure investment. The book will help you learn how to scale up serverless applications and handle distributed serverless systems in production. You will also learn how to log and test your application. Along the way, you'll also discover how to set up a CI/CD pipeline to automate the deployment process of your Lambda functions. Moreover, you'll learn how to troubleshoot and monitor your apps in near real-time with services such as AWS CloudWatch and X-ray. This book will also teach you how to secure the access with AWS Cognito. By the end of this book, you will have mastered designing, building, and deploying a Go serverless application.
Table of Contents (17 chapters)

Concurrent execution

AWS Lambda dynamically scales capacity in response to increased traffic. However, there's a limited number of an executed function's code at any given time. This number is called concurrent execution, and it's defined per AWS region. The default limit of concurrency is 1,000 per AWS region. So, what happens if your function crosses this defined threshold? Read on to find out.

Lambda throttling

Lambda applies throttling (rate limiting) to your function if the concurrent execution count is exceeding the limit. Hence, the remaining incoming requests won't invoke the function.

The invoking client is responsible for retrying the failed requests due to throttling by implementing a back-off...