Architecting Cloud-Native Serverless Solutions E-Book

Safeer Cm

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 503

Veröffentlichungsjahr: 2023

Beschreibung

Serverless computing has emerged as a mainstream paradigm in both cloud and on-premises computing, with AWS Lambda playing a pivotal role in shaping the Function-as-a-Service (FaaS) landscape. However, with the explosion of serverless technologies and vendors, it has become increasingly challenging to comprehend the foundational services and their offerings.
Architecting Cloud Native Serverless Solutions lays a strong foundation for understanding the serverless landscape and technologies in a vendor-agnostic manner. You'll learn how to select the appropriate cloud vendors and technologies based on your specific needs. In addition, you'll dive deep into the serverless services across AWS, GCP, Azure, and Cloudflare followed by open source serverless tools such as Knative, OpenFaaS, and OpenWhisk, along with examples. You'll explore serverless solutions on Kubernetes that can be deployed on both cloud-hosted clusters and on-premises environments, with real-world use cases. Furthermore, you'll explore development frameworks, DevOps approaches, best practices, security considerations, and design principles associated with serverless computing.
By the end of this serverless book, you'll be well equipped to solve your business problems by using the appropriate serverless vendors and technologies to build efficient and cost-effective serverless systems independently.

Leseprobe

Architecting Cloud-Native Serverless Solutions

Design, build, and operate serverless solutions on cloud and open source platforms

Safeer CM

BIRMINGHAM—MUMBAI

Architecting Cloud-Native Serverless Solutions

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Preet Ahuja

Publishing Product Manager: Surbhi Suman

Content Development Editor: Sujata Tripathi

Technical Editor: Arjun Varma

Copy Editor: Safis Editing

Project Coordinator: Sean Lobo

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Ponraj Dhandapani

Marketing Coordinator: Rohan Dobhal

First published: June 2023

Production reference: 2150623

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80323-008-5

www.packtpub.com

This book is dedicated to my beloved family: my parents, Mohamed Shafi and Rukiyya, who granted me the freedom to make my own choices, my wife, Sani, whose unwavering support propels me forward, and my sons, Aman and Ayaan, whose energetic presence keeps me on my toes every day.

Contributors

About the author

Safeer CM has been working in site reliability, DevOps, and platform engineering for 17 years. He is passionate about systems, networks, and anything in between. His recent focus areas include serverless computing, cloud-native landscape, and multi-cloud infrastructure. He is also an SRE and DevOps practitioner and consultant. Based out of Bengaluru (Bangalore), India, Safeer works as a senior staff SRE for Flipkart, the Indian e-commerce leader. Safeer has written several articles and has been a speaker at and organizer of multiple meetups. He is currently an ambassador for the Continuous Delivery Foundation, where he helps the organization with community adoption and governance.

A heartfelt thanks to my family for all their support. This book would not have been possible without the countless mentors and well-wishers who imparted their knowledge and kindness, which kept me going.

About the reviewers

Kuldeep Singh is an experienced data center migration architect and leader. He has expertise in infrastructure project management and has delivered successful data center projects for telecom giants such as AT&T (US) and Vodafone (Europe). He also holds various certifications for cloud solutions and project management. In his free time, he likes to keep fit by lifting weights at the gym.

I am grateful to my wife, my kid Mozo, and my family, for their constant support and encouragement throughout this project. I also appreciate the publisher for their professionalism and guidance in the publishing process. I hope this book will be useful and enjoyable for the readers.

Aditya Krishnakumar has worked in DevOps for the past 5+ years, with 3 years specifically spent working with serverless platforms on AWS and Google Cloud. He is currently working as a senior site reliability engineer at a US-based product-based organization that provides a DevSecOps platform designed for applications hosted on Kubernetes and containers. He previously worked for Boston Consulting Group (BCG), where he was responsible for the operations of a big data analytics platform hosted in Google Cloud. He provides contributions to the DevOps community via his blog and is a member of AWS Community Builders, a global community of AWS and cloud enthusiasts.

I’d like to thank my family, who have believed in me and understood the time and commitment it takes to review and test the contents of a book. Working in this field would not have been possible without the support of the DevOps community that has developed over the past several years.

Shubham Mishra is a prominent figure in the field of ethical hacking and is widely recognized as India’s youngest cybersecurity expert. He is the founder and CEO of TOAE Security Solutions, a company dedicated to the development of robust cybersecurity methods used worldwide. With over a decade of experience, Shubham has worked with some of the largest companies globally, providing updated and relevant content for the industry.

In addition to his professional achievements, Shubham is also an accomplished author, having written three books on various aspects of cybersecurity. His contributions to the field have cemented his reputation as a leading authority in the world of ethical hacking and cybersecurity.

Table of Contents

Preface

Part 1 – Serverless Essentials

1

Serverless Computing and Function as a Service

Evolution of computing in the cloud

Benefits of cloud computing

CAPEX versus OPEX

Virtualization, software-defined networking, and containers

Types of cloud computing

Cloud service delivery models – IaaS, PaaS, and SaaS

Serverless and FaaS

FaaS and BaaS

Microservice architecture

Containers, orchestration, and microservices

Event-driven architecture

Events

Structure and components of an EDA

Benefits of EDA

Use cases

Disadvantages

Brokers

FaaS in detail – self-hosted FaaS

Cloud FaaS versus self-hosted FaaS

API gateways and the rise of serverless API services

The case for serverless

Summary

2

Backend as a Service and Powerful Serverless Platforms

BaaS

Messaging systems

Message queues

Pub-sub

Message brokers and clusters

Messaging protocols

Push versus pull

Guarantees in messaging

Dead-letter queues

Cloud messaging

Object stores

Design and features

Workflow automation

Cloud workflows

NoSQL platforms

Cloud NoSQL platforms

Edge computing

PoP

CDNs

Serverless at the edge

IoT clouds

Stream processing

Future of serverless

Trends in serverless

Summary

Part 2 – Platforms and Solutions in Action

3

Serverless Solutions in AWS

Technical requirements

Useful AWS concepts to know and refresh yourself on

CloudFormation primer

Advanced constructs in the CloudFormation template language

Lambda – FaaS in AWS

How Lambda works

Important concepts

Important configurations

Lambda programming model

Edge computing

API Gateway

HTTP API

WebSocket API

REST API

Private REST API

API Gateway security

S3 – object store

S3 – components

S3 and serverless

DynamoDB

Fundamentals

Primary keys and indexes

DynamoDB and serverless

SQS

Types of queues

Features

SQS and other AWS messaging products

SQS and serverless

SNS

SNS and serverless

AWS EventBridge

Step Functions

AWS service integrations

Triggering workflows

Doing by example – lightweight alert manager

High-level solution design

Summary

4

Serverless Solutions in Azure

Technical requirements

Azure fundamentals

Azure Functions

Function apps and creating your first function

Developing and deploying a Python function

Azure Blob Storage

Creating and managing blob storage

Blob Storage and Azure Functions

Azure Cosmos DB

Elements of Cosmos DB

Data partitioning and partition keys

Creating and managing Cosmos DB

Cosmos DB and Azure Functions

Azure event and messaging services

Azure Event Grid

Azure Event Hubs

Azure Service Bus

Azure Event Grid with Azure Functions

Azure Logic Apps

Key concepts of Logic Apps

Creating a Logic Apps workflow

Project – image resizing with Azure Functions

Summary

5

Serverless Solutions in GCP

Prerequisites and GCP basics

Cloud Functions

Core features

The pricing model

Operating system (OS) and runtime support

Function triggers

Function's structure and dependency management

Creating your first function

GCP Pub/Sub

The different types of Pub/Sub flavors

Core concepts

GCS

Cloud Workflows

Common use cases

Writing a workflow

A sample workflow

More serverless services

Cloud Run

Eventarc

Cloud Scheduler

Databases and data stores

The project – nameplate scanning and traffic notice

Summary

6

Serverless Cloudflare

Cloudflare service portfolio

Cloudflare Workers – the workhorse at the edge

Service Workers – the namesake and power behind Cloudflare Workers

Cloudflare Workers – functionality and features

Other languages supported

Cloudflare Workers KV

Cloudflare Pages

JAMStack

Cloudflare Pages and JAMStack

Newest Cloudflare serverless offerings

Cloudflare R2 storage

Durable objects

Workers and KV – learning by example

Setting up the development environment with Wrangler

Creating your first worker

Deploying your worker

Workers KV store

Project

Implementation

More vendors in edge computing and JAMStack

Summary

7

Kubernetes, Knative and OpenFaaS

Containerization and Docker fundamentals

Docker images

Container orchestration and Kubernetes

Kubernetes architecture and components

Kubernetes how-to with minikube

Knative

Knative components

Knative Eventing

Knative and service meshes

Knative installation and setup

OpenFaaS

OpenFaaS architecture

Function runtime and watchdog

Asynchronous functions

FaaSD

OpenFaaS installation and setup

Example project – implementing a GitHub webhook with a Telegram notification

High-level solution

Design and architecture

Application code and infrastructure automation

Summary

8

Self-Hosted FaaS with Apache OpenWhisk

OpenWhisk – concepts and features

Actions and action chains

Architecture

Creating and managing actions and entities

Creating your first action

Triggers and rules

Packages

Feeds

Web actions

Administration and deployment

Project – IoT and event processing with IBM Cloud functions

Summary

Part 3 – Design, Build, and Operate Serverless

9

Implementing DevOps Practices for Serverless

General SDLC practices for serverless

The serverless framework

Getting started with the serverless framework

Framework concepts

Events

Updating and deploying the serverless service

Other features of serverless in a nutshell

Zappa – the serverless framework for Python

Creating and testing the IP information API in Flask

Infrastructure as code with Terraform

Terraform concepts

Terraform workflow

Getting started with Terraform

Infrastructure as code with the Pulumi SDK

Getting started with Pulumi

Testing serverless

Testing in serverless – challenges and approaches

Local manual tests

Unit testing for serverless

Integration tests

CI/CD pipelines for serverless

Summary

10

Serverless Security, Observability, and Best Practices

Security vulnerabilities and mitigation guidelines

The OWASP Serverless top 10

The CSA top 12 serverless vulnerabilities

Event injection

Broken authentication

Insecure configurations

Insecure secrets and credentials storage

Broken access control

Inadequate function monitoring and logging

Obsolete serverless resources

Insecure dependencies

Improper exception handling and verbose error messages

Cross-execution data persistence

Insecure deserialization

Other common vulnerabilities – XXE and XSS

Serverless observability

The challenges of serverless observability

Serverless observability in AWS

Serverless observability in GCP

Serverless observability in Azure

Serverless best practices

Summary

11

Architectural and Design Patterns for Serverless

Design patterns primer

Creational design patterns

Structural design patterns

Behavioral design patterns

Architectural patterns

Cloud architecture patterns – vendor frameworks and best practices

Three-tier web architecture with AWS

Event-driven architecture with Azure

Business process management with GCP

More serverless designs

The webhook pattern

Document processing

Video processing with the fanout pattern

Serverless job scheduling

Serverless applications in the Well-Architected Framework

Summary

Index

Other Books You May Enjoy

Preface

I still remember the first time I learned about AWS Lambda, shortly after its general availability. My introduction to and interest in the serverless world was triggered by it. What started as a casual experiment of a niche cloud service soon turned into a journey of exploring serverless as a computing paradigm and how to fit more business use cases into it. As months and years went by, more vendors started rolling out their own Function-as-a-Service (FaaS) alternatives as well as other serverless backends. It was an amazing evolution that brought in a new era of cloud computing.

As exciting as it is, with the explosion of serverless technologies and vendors, it has become challenging to even comprehend the foundational services and what they have to offer. With the era of hybrid cloud, it is not necessary to stick to one cloud vendor and their serverless platforms. You can do your due diligence and mix and match the services from different vendors or even build a private serverless cloud. But to make those decisions, it is vital to know about the choices you have across the vendors and open source technologies of serverless. While there is extensive documentation that each of these vendors supply, there was no one place from where an engineer could understand the basics of serverless offerings across the spectrum. This book is written with that audience in mind.

This book lays a strong foundation for serverless landscape and technologies in a vendor-agnostic manner. You’ll learn how to select the different cloud vendors and technology as per your needs. You’ll deep dive into the serverless services across Amazon Web Services (AWS), Google Cloud Platform (GCP), Azure, and Cloudflare, followed by open source serverless tools such as Knative, OpenFaaS, and OpenWhisk, along with their examples. You’ll explore serverless solutions on Kubernetes that can run on cloud-hosted clusters and on-premises with the help of real-world use cases. You’ll be able to extend your learnings by understanding the development frameworks, DevOps approaches, best practices, security, and design principles of serverless.

By the end of this serverless book, you’ll be equipped with the skills required to solve your business problems by using the appropriate serverless vendors and technologies and build efficient and cost-effective serverless systems on your own.

Who this book is for

This book is intended for platform, DevOps, site reliability engineers, and application developers who want to start building serverless solutions. It will be a valuable reference for solution architects trying to modernize a legacy application or working on a greenfield project. Besides, it is helpful for anyone solving business or operational problems without wanting to manage complicated technology infrastructure using serverless technologies.

What this book covers

Chapter 1, Serverless Computing and Function as a Service, introduces serverless technologies and the need for serverless. The chapter starts with an introduction to the evolution of the cloud and how internet infrastructure evolved over time. Then it dives into FaaS, its history, how FaaS works, and serverless in general.

Chapter 2, Backend as a Service and Powerful Serverless Platforms, talks about serverless backends and advanced backend services. While FaaS provides computing power in the serverless world, compute in isolation doesn’t add business value. This is where serverless backends come into the picture. The chapter discusses various serverless backends, including object stores, message queues, workflow orchestrators, and so on.

Chapter 3, Serverless Solutions in AWS, covers serverless solutions in AWS, starting with its flagship FaaS service: Lambda. Then it covers the core serverless services such as Simple Storage Service (S3), Simple Queue Service (SQS), DynamoDB, and so on. The chapter also delves into other serverless backends such as Simple Notification Service (SNS), EventBridge, Step Functions, and Cognito.

Chapter 4, Serverless Solutions in Azure, covers the Microsoft Azure cloud’s serverless offering. The most important service is the FaaS offering: Azure Functions. This chapter also covers other critical services such as Azure Cosmos DB, Logic Apps, Event Grid, Event Hubs, and so on.

Chapter 5, Serverless Solutions in GCP, covers the most important serverless services that Google Cloud offers. The chapter starts by covering in detail Google Cloud Functions, followed by the critical serverless backends such as Pub/Sub, Cloud Storage, Workflows, and so on. It also touches upon the newer serverless services such as Cloud Run, Eventarc, Cloud Scheduler, and many database services.

Chapter 6, Serverless Cloudflare, talks about how Cloudflare has a unique position among the serverless vendors by offering a number of services in its core role as a network and edge services vendor. Its FaaS platform – Cloudflare Workers – was brought in to supercharge its edge services. From that, Cloudflare’s serverless portfolios have evolved to add more services such as Workers KV, Cloudflare Pages, R2, and so on. This chapter covers all these services with examples and code snippets.

Chapter 7, Kubernetes, Knative, and OpenFaaS, covers the most cloud-native serverless solutions – based on Kubernetes. Knative is a cloud-native FaaS implementation that can be deployed in any Kubernetes cluster, which also powers Google Cloud Functions behind the scenes. This chapter covers its implementation with examples using a Kubernetes cluster. OpenFaaS is another open source platform that can be run on Kubernetes or on virtual machines, and the chapter covers the architecture as well as usage with examples.

Chapter 8, Self-Hosted FaaS with Apache OpenWhisk, talks about Apache OpenWhisk, which is an open source FaaS platform hosted and maintained by the Apache Foundation. It powers the FaaS platforms for IBM Cloud, Adobe I/O Runtime, and so on. This chapter covers its architecture and implementation with examples.

Chapter 9, Implementing DevOps Practices for Serverless, covers multiple frameworks that are helpful to implement your serverless story. It starts with the coverage of “the Serverless Framework,” followed by another framework called Zappa – both of which make serverless development easy. This chapter also talks about Infrastructure as Code (IaC) and its implementation with Terraform and Pulumi.

Chapter 10, Serverless Security, Observability, and Best Practices, talks about serverless security, which I find is a topic that is not given enough attention, where most of the security responsibility is offloaded to the vendor. This chapter examines the cloud responsibility matrix and the security best practices laid out by different organizations. It also talks about observability for serverless services and closes the chapter with industry best practices.

Chapter 11, Architectural and Design Patterns for Serverless, has the central theme of how to design better serverless solutions. To help with this, this chapter starts by giving an introduction to software design patterns followed by cloud architecture patterns. Then, this chapter discusses the Well-Architected Framework and patterns for serverless applications.

To get the most out of this book

Wherever possible, use the cloud shell provided by the cloud vendor for easier bootup. AWS, Azure, and GCP provide shells at the time of writing.

Software/hardware covered in the book

Operating system requirements

AWS, GCP, Azure, Cloudflare

Windows, macOS, or Linux

Kubernetes, Knative

A terminal or command-line application in your preferred operating system, plus a browser

OpenFaas, OpenWhisk

Knowledge of at least one cloud platform and the basics of Linux will help you

Serverless Framework, Zappa

Terraform, Pulumi

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Architecting-Cloud-Native-Serverless-Solutions. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/2fHDU.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “The /whisk.system namespace is reserved for entities that are distributed with the OpenWhisk system.”

A block of code is set as follows:

root@serverless101:~/hello-worker# cat index.js addEventListener('fetch', event => {   event.respondWith(handleRequest(event.request)) }) /** * Respond with hello worker text * @param {Request} request */ async function handleRequest(request) {   return new Response('Hello worker!', {     headers: { 'content-type': 'text/plain' },   }) }

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

root@serverless101:~/hello-worker# wrangler dev -i 0.0.0.0 Listening on http://0.0.0.0:8787 watching "./"

Any command-line input or output is written as follows:

aws cloudformation create-stack \ --stack-name MyS3Bucket \ --template-body file://tmp/cfntemplates/mys3.yml

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “The Kubernetes hairpin-mode shouldn’t be none as OpenWhisk endpoints should be able to loop back to themselves.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Architecting Cloud Native Serverless Solutions, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781803230085

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1 – Serverless Essentials

This part provides the foundational knowledge on serverless computing. We will understand the history and evolution of serverless, what Function as a Service (FaaS) is, why there is more to serverless than FaaS, and so on. We will explore the most important serverless services provided by top vendors, as well as the self-hosted alternatives and the special cases in serverless computing.

This part has the following chapters:

Chapter 1, Serverless Computing and Function as a ServiceChapter 2, Backend as a Service and Powerful Serverless Platforms

1

Serverless Computing and Function as a Service

Serverless computing has ushered in a new era to an already revolutionizing world of cloud computing. What started as a nascent idea to run code more efficiently and modularly has grown into a powerful platform of serverless services that can replace traditional microservices and data pipelines in their entirety. Such growth and adoption also brings in new challenges regarding integration, security, and scaling. Vendors are releasing newer services and feature additions to existing services all around, opening more and more choices for customers.

AWS has been a front runner in serverless offerings, but other vendors are catching up fast. Replacing in-house and self-hosted applications with serverless platforms is becoming a trend. Function as a Service (FaaS) is what drives serverless computing. While all cloud vendors are offering their version of FaaS, we are also seeing the rise of self-hosted FaaS platforms, making this a trend across cloud and data center infrastructures alike. People are building solutions that are cloud agnostic using these self-hosted platforms as well.

In this chapter, we will cover the foundations of serverless and FaaS computing models. We will also discuss the architecture patterns that are essential to serverless models.

In this chapter, we will cover the following topics:

Evolution of computing in the cloudServerless and FaaSMicroservice architectureEvent-driven architectureFaaS in detailAPI gateways and the rise of serverless APIsThe case for serverless

Evolution of computing in the cloud

In this section, we will touch on the evolution of cloud computing and why the cloud matters. We will briefly cover the technologies that drive the cloud and various delivery models.

Benefits of cloud computing

Cloud computing has revolutionized IT and has spearheaded unprecedented growth in the past decade. By definition, cloud computing is the availability and process of delivering computing resources on-demand over the internet. The traditional computing model required software services to invest heavily in the computing infrastructure. Typically, this meant renting infrastructure in a data center – usually called colocation – for recurring charges per server and every other piece of hardware, software, and internet they used. Depending on the server count and configurations, this number would be pretty high and was inflexible in the billing model – with upfront costs and commitments. If more customized infrastructure with access to network gears and more dedicated internet bandwidth is required, the cost would go even higher and it would have more upfront costs and commitments. Internet-scale companies had to build or rent entire data centers across the globe to scale their applications – most of them still do.

This traditional IT model always led to a higher total cost of ownership, as well as higher maintenance costs. But these were not the only disadvantages – lack of control, limited choices of hardware and software combinations, inflexibility, and slow provisioning that couldn't match the market growth and ever-increasing customer bases were all hindering the speed of delivery and the growth of applications and services. Cloud computing changed all that. Resources that were available only by building or renting a data center were now available over the internet, at a click of a button or a command. This wasn't just the case servers, but private networks, routers, firewalls, and even software services and distributed systems – which would take traditional IT a huge amount of manpower and money to maintain – were all available right around the virtual corner.

Cost has always been a crucial factor in deciding on which computing model to use and what investment companies are willing to make in the short and long term. In the next section, we will talk about the difference between the cost models in the cloud.

CAPEX versus OPEX

The impact of cloud computing is multifold. On one hand, it allows engineering and product teams to experiment with their products freely without worrying about planning for the infrastructure quarters or even years back. It also has the added benefit of not having to actively manage the cloud resources, unlike the data center infrastructure. Another reason for its wider adoption is the cost factor. The difference between traditional IT and the cloud in terms of cost is sometimes referred to as CAPEX versus OPEX.

CAPEX, also known as capital expenditure, is the initial and ongoing investments that are made in assets – IT infrastructure, in this case – to reap the benefits for the foreseeable future. This also includes the ongoing maintenance cost as it improves and increases the lifespan of the assets. On the other hand, the cloud doesn't require you to invest upfront in assets; the infrastructure is elastic and virtually unlimited as far as the customer is concerned. There is no need to plan for infrastructure capacity months in advance, or even worry about the underutilization of already acquired IT assets. Infrastructure can be built, scaled up or down, and ultimately torn down without any cost implications. The expenditure, in this case, is operating expenditure – OPEX. This is the cost that's incurred in running the day-to-day business and what's spent on utilities and consumables rather than long-term assets. The flexible nature of cloud assets makes them consumable rather than assets.

Let's look at a few technologies that accelerated the adoption of the cloud.

Virtualization, software-defined networking, and containers

While we understand and appreciate cloud computing and the benefits it brings, the technologies that made it possible to move from traditional data centers to the cloud need to be acknowledged.

The core technology that succeeded in capitalizing on the potential of hardware and building abstraction on top of it was virtualization. It allowed virtual machines to be created on top of the hardware and the host operating system. Network virtualization soon followed, in the form of Software-Defined Networking (SDN). This allowed vendors to provide a completely virtualized private network and servers on top of their IT infrastructure. Virtualization was prevalent much before cloud computing started but was limited to running in data centers and development environments, where the customers or vendors directly managed the entire stack, from hardware to applications.

The next phase of technological revolution came in the form of containers, spearheaded by Docker's container runtime. This allowed process, network, and filesystem isolation from the underlying operating system. It was also possible to enforce resource utilization limits on the processes running inside the container. This amazing feat was powered by Linux namespaces, cgroups, and Union Filesystem. Packaging runtimes and application code into containers led to the dual benefit of portability and a lean operating system. It was a win for both application developers and infrastructure operators.

Now that you are aware of how virtualization, SDN, and containers came around, let's start exploring the different types of cloud computing.

Types of cloud computing

In this section, we are going to look at different cloud computing models and how they differ from each other.

Public cloud

The public cloud is the cloud infrastructure that's available over the public internet and is built and operated by cloud providers such as Amazon, Azure, Google, IBM, and so on. This is the most common cloud computing model and is where the vendor manages all the infrastructure and ensures there's enough capacity for all use cases.

A public cloud customer could be anyone who signs up for an account and has a valid payment method. This provides an easy path to start building on cloud services. The underlying infrastructure is shared by all the customers of the public cloud across the globe. The cloud vendor abstracts out this shared-ness and gives each customer the feeling that they have a dedicated infrastructure to themselves. The capacity is virtually unlimited, and the reliability of the infrastructure is guaranteed by the vendor. While it provides all these benefits, the public cloud can also cause security loopholes and an increased attack surface if it's not maintained well. Excessive billing can happen due to a lack of knowledge of the cloud cost model, unrealistic capacity planning, or abandoning the rarely used resources without disposing of them properly.

Private cloud

Unlike with the public cloud, a private cloud customer is usually a single business or organization. A private cloud could be maintained in-house or in the company-owned data centers – usually called internal private clouds. Some third-party providers run dedicated private clouds for business customers. This model is called a hosted private cloud.

A private cloud provides more control and customization for businesses, and certain businesses prefer private clouds due to their business nature. For example, telecom companies prefer to run open source-based private clouds – Apache OpenStack is the primary choice of technology for a large number of telecom carriers. Hosting the cloud infrastructure also helps them integrate the telco hardware and network with the computing infrastructure, thereby improving their ability to provide better communication services. This added flexibility and control also comes at a cost – the cost of operating and scaling the cloud. From budget planning to growth predictions, to hardware and real estate acquisition for expansion, this becomes the responsibility of the business. The engineering cost – both in terms of technology and manpower – becomes a core cost center forthe business.

Hybrid cloud

The hybrid cloud combines a public cloud and a physical infrastructure – either operated on-premises or on a private cloud. Data and applications can move between the public and private clouds securely to suit the business needs. Organizations could adopt a hybrid model for many reasons; they could be bound by regulations and compliance (such as financial institutions), low latency for certain applications to be placed close to the company infrastructure, or just because huge investments have already been made in the physical infrastructure. Most public clouds identify this as a valid business use case and provide cloud solutions that offer connectivity from cloud infrastructure to data centers through a private WAN-wide area network. Examples include AWS Direct Connect, GCP Interconnect, and Azure ExpressRoute.

An alternate form of hybrid cloud is the multi-cloud infrastructure. In these scenarios, one public cloud infrastructure is connected to one or more cloud infrastructures hosted by different vendors:

Figure 1.1 – Types of cloud computing

The preceding diagram summarizes the cloud computing types and how they are interrelated. Now that we understand these types, let's look at various ways in which cloud services are delivered.

Cloud service delivery models – IaaS, PaaS, and SaaS

While cloud computing initially started with services such as computing and storage, it soon evolved to offer a lot more services that handle data, computing, and software. These services are broadly categorized into three types based on their delivery models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Let's take a quick look at each ofthese categories.

Infrastructure as a service

In IaaS, the cloud vendor delivers services such as compute (virtual machines, containers, and so on), storage, and network as a cloud service – just like a traditional data center would. It also covers a lot of supporting services, such as firewall and security, monitoring, load balancing, and more. Out of all the service categories listed, IaaS provides the most control to the customer and they get to fine-tune and configure core services, as they would in a traditional IT infrastructure.

While the compute, storage, and network are made available to the customers as infrastructure pieces, these are not actual physical hardware. Instead, these resources are virtualized – as abstractions on top of the real hardware. There is a lesser-known variant of IaaS where the real hardware is directly provisioned and exposed to the customer. This category of services is called Bare-Metal as a Service (BMaaS). BMaaS provides much more control than IaaS to the customer and it is also usually costlier and takes more engineering time to manage.

Platform as a service

PaaS allows customers to develop, test, build, deploy, and manage their applications without having to worry about the resources or the build environment and its associated tooling. This could be considered as an additional layer of abstraction on top of IaaS. In addition to computing, storage, and network resources, PaaS also provides the operating system, container/middleware, and application runtime. Any updates that are required for the upkeep of the platform, such as operating system patching, will be taken care of by the vendor. PaaS enables organizations to focus on development without worrying about the supporting infrastructure and software ecosystem.

Any data that's needed for the PaaS applications is the responsibility of the user, though the data stores that are required will be provided by the vendors. Application owners have direct control of the data and can move it elsewhere if necessary.

Software as a service

In the SaaS model, a cloud vendor provides access to software via the internet. This cloud-based software is usually provided through a pay-as-you-go model where different sets of features of the same software are offered for varying charges. The more features used, the costlier the SaaS is. The pricing models also depend on the number of users using the software.

The advantage of SaaS is that it completely frees a customer from having to develop or operate their software. All the hassle of running such an infrastructure, including security and scaling, are taken care of by the vendor. The only commitment from the customer is the subscription fee that they need to pay. This freedom also comes at the cost of complete vendor dependency. The data is managed by the vendor; most vendors would enable their customers to take a backup of their data since finding a compatible vendor or reusing that data in-house could become challenging:

Figure 1.2 – Cloud service delivery models

Now that we have cemented our foundations of cloud computing, let's look at a new model of computing – FaaS.

Serverless and FaaS

In the previous sections, we discussed various types of clouds, cloud service delivery models, and the core technologies that drove this technology revolution. Now that we have established the baselines, it is time to define the core concept of this book – serverless.

When we say serverless, what we are usually referring to is an application that's built on top of a serverless platform. Serverless started as a new cloud service delivery model where everything except the code is abstracted away from the application developer. This sounds like PaaS as there are no servers to manage and the application developer's responsibility is limited to writing the code. There are some overlaps, but there are a few distinctive differences between PaaS and serverless, as follows:

PaaS

Serverless

Always-on application

Runs on demand

Scaling requires configuration

Automatic scaling

More control over the development and deployment infrastructure

Very limited control over the development and deployment infrastructure

High chance of idle capacity

Full utilization and no idle time, as well as visibility to fine-tune and benchmark business logic

Billed for the entirety of the application's running time

Billed every time the business logic is executed

Table 1.1 – PaaS versus serverless

In the spectrum of cloud service delivery models, serverless can be placed between PaaS and SaaS.

FaaS and BaaS

The serverless model became popular in 2014 after AWS introduced a service called Lambda, which provides FaaS. Historically, other services could be considered ancestors of serverless, such as Google App Engine and iron.io. Lambda, in its initial days, allowed users to write functions in a selected set of language runtimes. This function could then be executed in response to a limited set of events or be scheduled to run at an interval, similar to a cronjob. It was also possible to invoke the function manually.

As we mentioned previously, Lambda was one of the first services in the category of FaaS and established itself as a standard. So, when we say serverless, people think of FaaS and, subsequently, Lambda. But FaaS is just one part of the puzzle – it serves as the computing component of serverless. As is often the case, compute is meaningless without data and a way to provide input and output. This is where a whole range of supporting services come into the picture. There are services in the category of API gateways, object stores, relational databases, NoSQL databases, communication buses, workflow management, authentication services, and more. In general, these services power the backend for serverless computing. These services can be categorized as Backend as a Service (BaaS). We will look at BaaS in the next chapter.

Before we get into the details of FaaS, let's review two architecture patterns that you should know about to understand serverless – the microservice architecture and the Event-Driven Architecture (EDA).

Microservice architecture

Before we look at the microservice architecture, let's look at how web applications were built before that. The traditional way of building software applications was called monolithic architecture. Enterprises used to develop applications as one big indivisible unit that provided all the intended functionality. In the initial phases of development and deployment, monoliths offered some fairly good advantages. Project planning and building a minimum viable product – the alpha or beta version – was easier. A single technology stack would be chosen, which made it easier to hire and train developers. In terms of deployment, it was easier to scale since multiple copies of this single unit could be thrown behind a load balancer to scale for increased traffic:

Figure 1.3 – Monolithic architecture

The problem starts when the monolithic application has to accommodate more features and the business requirements grow. It becomes increasingly complex to understand the business logic and how the various pieces that implement the features are interconnected. As the development team grows, parts of the application will be developed by dedicated teams. This will lead to a disconnect in communication and introduce non-compatible changes and more complex dependencies. The adoption of new technologies will become virtually impossible and the only choice to bring in changes that align with changing business requirements would be to rewrite the application in its entirety. On the scaling front, the problem is that we need to scale up the entire application, even if only a particular piece of code or business logic is creating the bottleneck. This inflexibility causes unnecessary provisioning of resources and idle time when the particular business logic is not in the critical path.

The microservice architecture was introduced to fix the shortcomings of the monolithic architecture. In this architecture, an application is organized as a collection of smaller independent units called microservices. This is achieved by building separate services around independent functions or the business logic of the application. In a monolithic architecture, the different modules of the application would communicate with each other using library calls or inter-process communication channels. In the case of the microservice architecture, individual services communicate with each other via APIs using protocols such as HTTP or gRPC. Some of the key features of the microservice model are as follows:

Loosely coupled – each unit is independent.Single responsibility – one service is responsible for one business function.Independently develop and deploy.Each service can be built in a separate technology stack.Easier to divide and separate the backends that support the services, such as databases.Smaller and separate teams are responsible for one or more microservices.The developer's responsibilities are better and clearly defined.Easy to scale independently. A bug in one service won't bring down the entire application. Instead, a single piece of business logic or a feature would be impacted:

Figure 1.4 – E-commerce application with the microservice architecture

While microservices help solve a lot of problems that the monolithic architecture posed, it is no silver bullet. Some of the disadvantages of microservices are as follows:

Given all inter-microservice communication happens via the network, network issues such as latency have a direct impact and increase the time it takes to communicate between two parts of the business function.Since most business logic requires talking to other microservices, it increases the complexity of managing the service.Debugging becomes hard in a distributed microservice environment.More external services are required to ensure visibility into the infrastructure using metrics, logs, and tracing. The absence of any of this makes troubleshooting hard.It puts a premium on monitoring and increases the overall infrastructure cost.Testing global business logic would involve multiple service calls and dependencies, making it very challenging.Deployments require more standardization, engineering investment, and continuous upkeep.It's complex to route requests.

This sums up the microservice architecture and its benefits. In the next section, we will briefly discuss a few technologies that can help microservices be deployed more structurally.

Containers, orchestration, and microservices

Containers revolutionized the way we deploy and utilize system resources. While we had microservices long before containers became popular, they were not configured and deployed optimally. A container's capability to isolate running processes from one another and limit the resources that are used by processes was a great enabler for microservices. The introduction of container orchestration services such as Kubernetes took this to the next level. It helped support more streamlined deployments and developers could define every resource, every network, and every backend for an application using a declarative model. Currently, containers and container orchestration are the de facto way to deploy microservices.

Now that we have a firm understanding of the microservice architecture, let's examine another architecture pattern – EDA.

Event-driven architecture

EDA is an architectural pattern where capturing, processing, and storing events is the central theme. This allows a bunch of microservices to exchange and process information asynchronously. But before we dive into the details of the architecture, let's define what an event is.

Events

An event is the record of a significant occurrence or change that's been made to the state of a system. The source of the event could be a change in the hardware or software system. An event could also be a change to the content of a data item or a change in the state of a business transaction. Anything that happens in your business or IT infrastructure could be an event. Which events do we need to process and bring under EDA as an engineering and business choice? Events are immutable records and can be read and processed without the event needing to be modified. Events are usually ordered based on their creation time.

Some examples of events are as follows:

Customer requestsChange of balance in a bank accountA food delivery order being placedA user being added to a serverSensor reading from a hardware or IoT deviceA security breach in a system

You can find examples of events all around your application and infrastructure. The trick is deciding on which are relevant and need processing. In the next section, we'll look at the structure of EDA.

Structure and components of an EDA

The value proposition of EDA comes from the fact that an event loses its processing value as it gets older. Event-driven systems can respond to such events as they are generated and take appropriate action to add a lot of business value. In an event-driven system, messages from various sources are ingested, then sent to interested parties (read microservices) for processing, and then persisted to disk for a defined period.

EDA fundamentally differs from the synchronous model that's followed by APIs and web stacks, where a response must be returned for every request synchronously. This could be compared to a customer support center using phone calls versus emails to respond to customer requests. While phone calls take a lot of time and need the support agent to be manually responding to the request, the same time can be spent asynchronously replying to a bunch of emails, often with the help of automation. The same principle applies to request-response versus event-driven models. But just like this example, EDA is not a silver bullet and can't be used on all occasions. The trick is in finding the right use case and building on it. Most critical systems and customer-facing services still have to rely on the synchronous request-response model.

The components of an event-driven model can be broadly classified into three types – event producer, event router (broker), and event consumer. The event producers are one or more microservices that produce interesting events and post them to the broker. The event broker is the central component of this architecture and enables loose coupling between producers and consumers. It is responsible for receiving the events, serializing or deserializing them, if necessary, notifying the consumers of the new event, and storing them. Certain brokers also filter the events based on conditions or rules. The consumers can then consume the interesting events at their pace:

Figure 1.5 – EDA

That sums up the EDA pattern. Now, let's look into the benefits of EDA.

Benefits of EDA

The following is not a comprehensive list of the benefits of EDA, but this should give you a fair idea of why this architecture pattern is important:

Improved scalability and fault tolerance due to a producer or consumer failing doesn't impact the rest of the systems.Real-time data processing for better decisions and customer experience – businesses can respond in real time to changes in customer behavior and make decisions or share data that improves the quality of the service.Operational stability and agility.Cost efficiency compared to batch processing. With batch processing, large volumes of data had to be stored and processed in batches. This meant allocating a lot more storage and compute resources for a longer period. Once batch processing is over, the computing resource becomes idle. This doesn't happen in EDA as the events are processed as they arrive, and it distributes the compute and storage optimally.Better interoperability between independent services.High throughput and low latency.Easy to filter and transform events.The rate of production and consumption doesn't have to match.Works with small as well as complex applications.

Now that we have covered the use cases of EDA, let's look at some use cases where the EDA pattern canbe implemented.

Use cases

EDA has a very varied set of use cases; some examples are as follows:

Real-time monitoring and alerting based on the events in a software systemWebsite activity trackingReal-time trend analysis and decision makingFraud detectionData replication between similar and different applicationsIntegration with external vendors and services

While EDA becomes more and more important as the business logic and infrastructure becomes complicated, there are certain downsides we need to be aware of. We'll explore them in the next section.

Disadvantages

As we mentioned earlier, EDA is no silver bullet and doesn't work with all business use cases. Some of its notable disadvantages are as follows:

The decoupled nature of events can also make it difficult to debug or trace back the issues with events.The reliability of the system depends on the reliability of the broker. Ideally, the broker should be either a cloud service or a self-hosted distributed system with a high degree of reliability.Consumer patterns can make it difficult to do efficient capacity planning. If many of the consumers are services that wake up only at a defined interval and process the events, this could create an imbalance in the capacity for that period.There is no single standard in implementing brokers – knowing the guarantees that are provided by the broker is important. Architectural choices such as whether it provides a strong guarantee of ordering or the promise of no duplicate events should be figured out early in the design, and the producers and consumers should be designed accordingly.

In the next section, we will discuss what our software choices are for EDA, both on-premises and in the cloud.

Brokers

There are open source brokers such as Kafka, Apache Pulsar, and Apache ActiveMQ that can implement some form of message broker. Since we are mostly talking in the context of the cloud in this book, the following are the most common cloud brokers:

Amazon Simple Queue Service (SQS)Amazon Simple Notification Service (SNS)Amazon EventBridgeAzure Service Bus queuesAzure Service Bus topicsGoogle Cloud Pub/SubGoogle Cloud Pub/Sub Lite

EDA, as we've discovered, is fundamental to a lot of modern applications' architectures. Now, let's look at FaaS platforms in detail.

FaaS in detail – self-hosted FaaS

We briefly discussed FaaS earlier. As a serverless computing service, it is the foundational service for any serverless stack. So, what exactly defines a FaaS and its functionality?

As in the general definition of a function, it is a discrete piece of code that can execute one task. In the context of a larger web application microservice, this function would ideally serve a single URL endpoint for a specific HTTP method – say, GET, POST, PUT, or DELETE. In the context of EDA, a FaaS function would handle consuming one type of event or transforming and fanning out the event to multiple other functions. In scheduled execution mode, the function could be cleaning up some logs or changing some configurations. Irrespective of the model where it is used, FaaS has a simple objective – to run a function with a set of resource constraints within a time limit. The function could be triggered by an event or a schedule or even manually launched.

Similar to writing functions in any language, you can write multiple functions and libraries that can then be invoked within the primary function code. So long as you provide a function to FaaS, it doesn't care about what other functions you have defined or libraries you have included within the code snippet. FaaS considers this function as the handler function – the name could be different for different platforms, but essentially, this function is the entry point to your code and could take arguments that are passed by the platform, such as an event in an event-driven model.

FaaS runtimes are determined and locked by the vendor. They usually decide whether a language is supported and, if so, which versions of the language runtime will be available. This is usually a limited list where each platform adds support for more languages every day. Almost all platforms support a minimum of Java, JavaScript, and Python.

The process to create and maintain these functions is similar across platforms:

The customer creates a function, names it, and decides on the language runtime to use.The customer decides on the limit for the supported resource constraints. This includes the upper limit of RAM and the running time that the function will use.While different platforms provide different configuration features, most platforms provide a host of configurations, including logging, security, and, most importantly, the mechanism to trigger the function.All FaaS platforms support events, cron jobs, and manual triggers.The platform also provides options to upload and maintain the code and its associated dependencies. Most also support various versions of the function to be kept for rollbacks or to roll forward. In most cloud platforms, these functions can also be tested with dummy inputs provided by the customer.

The implementation details differ across platforms but behind the scenes, how FaaS infrastructure logically works is roughly the same everywhere. When a function is triggered, the following happens:

Depending on the language runtime that's been configured for the function, a container that's baked with the language runtime is spun up in the cloud provider's infrastructure.The code artifact – the function code and dependencies that are packed together as an archive or a file – is downloaded from the artifact store and dropped into the container.Depending on the language, the command that's running inside the container will vary. But this will ultimately be the runtime that's invoking the entry point function from the artifact.Depending on the platform and how it's invoked, the application that's running in the container will receive an event or custom environment variables that can be passed into the entry point function as arguments.The container and the server will have network and access restrictions based on the security policy that's been configured for the function:

Figure 1.6 – FaaS infrastructure

One thing that characterizes FaaS is its stateless nature. Each invocation of the same function is an independent execution, and no context or global variables can be passed around between them. The FaaS platform has no visibility into the kind of business logic the code is executing or the data that's being processed. While this may look like a limiting factor, it's quite the opposite. This enables FaaS to independently scale multiple instances of the same function without worrying about the communication between them. This makes it a very scalable platform. Any data persistence that's necessary for the business logic to work should be saved to an external data service, such as a queue or database.

Cloud FaaS versus self-hosted FaaS

While FaaS started with the hosted model, the stateless and lightweight nature of it was very appealing. As it happens with most services like this, the open source community and various vendors created open source FaaS platforms that can be run on any platform that offers virtual machines or bare metal computing. These are known as self-hosted FaaS platforms. With self-hosted FaaS platforms, the infrastructure is not abstracted out anymore. Somebody in the organization will end up maintaining the infrastructure. But the advantage is that the developers have more control over the infrastructure and the infrastructure is much more secure and customizable.

The following is a list of FaaS offerings from the top cloud providers:

AWS LambdaGoogle Cloud FunctionsAzure Functions IBM Cloud Functions

Other cloud providers are specialized in certain use cases, such as Cloudflare Workers, which is the FaaS from the edge and network service provider. This FaaS offering mostly caters to the edge computing use case within serverless. The following is a list of self-hosted and open source FaaS offerings:

Apache OpensWhisk – also powers IBM CloudKubelessKnative – powers Google's Cloud Functions and Cloud RunOpenFaaS

All FaaS offerings have common basic features, such as the ability to run functions in response to events or scheduled invocations. But a lot of other features vary between platforms. In the next section, we will look at a very common serverless pattern that makes use of FaaS.

API gateways and the rise of serverless API services

API Gateway is an architectural pattern that is often part of an API management platform. API life cycle management involves designing and publishing APIs and provides tools to document and analyze them. API management enables enterprises to manage their API usage, respond to market changes quickly, use external APIs effectively, and even monetize their APIs. While a detailed discussion on API management is outside the scope of this book, one component of the API management ecosystem is of particular interest to us: API gateways.

An API gateway can be considered as a gatekeeper for all the API endpoints of the enterprise. A bare-bones API gateway would support defining APIs, routing them to the correct backend destination, and enforcing authentication and authorization as a minimum set of features. Collecting metrics at the API endpoints is also a commonly supported feature that helps in understanding the telemetry of each API. While cloud API gateways provide this as part of their cloud monitoring solutions, self-hosted API gateways usually have plugins to export metrics to standard metric collection systems or metric endpoints where external tools can scrape metrics. API gateways either host the APIs on their own or send the traffic to internal microservices, thus acting as API proxies. The clients of API gateways could be mobile and web applications, third-party services, and partner services. Some of the most common features of API gateways are as follows:

Authentication and authorization: Most cloud-native API gateways support their own Identity and Access Management (IAM) systems as one of their leading authentication and authorization solutions. But as APIs, they also need to support common access methods using API keys, JWTs, mutual-TLS, and so on.Rate limiting, quotas, and security: Controlling the number of requests and preventing abuse is a common requirement. Cloud API gateways often achieve this by integrating with their CDN/global load balancers and DDoS protection systems.Protocol translation: Converting requests and responses between various API protocols, such as REST, WebSocket, GraphQL, and gRPC.Load balancing: With the cloud, this is a given as API Gateway is a managed service. For self-hosted or open source gateways, load balancing may need additional services or configuration.Custom code execution: This enables developers to modify requests or responses before they are passed down to downstream APIs or upstream customers.

Since API gateways act as the single entry point for all the APIs in an enterprise, they support various types of endpoint types. While most common APIs are written as REST services and use the HTTP protocol, there are also WebSocket, gRPC, and GraphQL-based APIs. Not all platforms support all of these protocols/endpoint types.

While API gateways existed independent of the cloud and serverless, they got more traction once cloud providers started integrating their serverless platforms with API Gateway. As in the case of most cloud service releases, AWS was the first to do this. Lambda was initially released as a private preview in 2014. In June 2015, 3 months after Lambda became generally available, AWS released API Gateway and started supporting integration with Lambda. Other vendors followed suit soon after. Due to this, serverless APIs became mainstream.

The idea of a serverless API is very simple. First, you must define an API endpoint in the supported endpoint protocol; that is, REST/gRPC/WebSocket/GraphQL. For example, in an HTTP-based REST API, this definition would include a URL path and an associated HTTP method, such as GET/POST/PUT/DELETE. Once the endpoint has been defined, you must associate a FaaS function with it. When a client request hits said endpoint, the request and its execution context are passed to the function, which will process the request and return a response. The gateway passes back the response in the appropriate protocol:

Figure 1.7 – API Gateway with FaaS

The advantage of serverless APIs is that they create on-demand APIs that can be scaled very fast and without any practical limits. The cloud providers would impose certain limits to avoid abuse and plan for better scalability and resource utilization of their infrastructure. But in most cases, you can increase these limits or lift them altogether by contacting your cloud vendor. In Part 2