> For the complete documentation index, see [llms.txt](https://notes.danfitz.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notes.danfitz.com/javascript/serverless-bootcamp/a-introduction.md).

# Introduction

## Introduction to Serverless Framework

The Serverless framework is a **function as a service (FaaS)**.

You deploy your code as *functions* in the cloud.

Then, when specific *events get triggered*, your functions execute.

Examples of events:

* Picture gets uploaded to AWS S3 bucket
* AWS API Gateway exposes a public endpoint that receives an http request
* AWS DynamoDB creates a new record in a database

!\[AWS services trigger an event, which invokes a function]:function as a service

### `serverless.yml`

In any serverless framework application, the `serverless.yml` file is the *heart* of your application.

It's where you define:

* Service name
* Provider
* Functions
* Resources
* Etc.

### Infrastructure as code (IaC)

The Serverless framework is an example of **infrastructure as code (IaC)**. This is an approach to infrastructure where you define your application's infrastructure *as code*.

Benefits:

* Infrastructure is side by side with the code that uses it, so it gets the benefit of *version control*! Roll back your code, and you roll back your infrastructure automatically.
* There is *less room for human error*, as manual configuration of infrastructure can be dangerous.
* You get increased site reliability because you don't have to take down your entire infrastructure when making a change; IaC knows the current state of your deployment and knows exactly what needs to change and makes the changes for you.
* You don't have to deal with the extreme complexity of defining your infrastructure.

### AWS

In AWS, all Serverless framework applications are deployed as **CloudFormation** stacks!

**Pro tip**: If you go under the "Resources" tab inside your CloudFormation stack, you will likely see many resources there. Imagine having to configure every one of those resources manually. The Serverless framework **saves you time**.

## Introduction to Microservices Architecture

### Monolithic architecture

In the traditional **monolithic architecture**, you have a *single* application all written in the same language and in the same repository made up of multiple modules: orders, auth, live chat, notifications, etc. Each of these modules communicates with a *single* database that gets massive and hard to manage.

### Microservices architecture

In the **microservices architecture**, each module gets broken up and has its own dedicated service/services. Orders might get its own API gateway that interacts with its own database. Notifications gets another API gateway that places messages into a queue.

### Distributed system

The microservices architecture supports having a **distributed system**. This has a few benefits:

* Reduces dependency between development teams
* Can scale independently of other services
  * *Example*: If one of your modules gets more traffic at a certain time of the day, you can scale it without having to scale the entire application (unlike a monolithic application)
* Can be deployed and updated independently of other services
  * If I need to deploy code changes to my service, I don't have to deploy the entire application (unlike a monolithic application)
* Allows for flexibility in technology choices
  * *Example*: If I want to introduce a new service but realize it would be best to write it in a new language, I can without having to worry about the rest of the application
* Reduces points of failure
  * *Example*: If one service crashes, it's far less likely that it will take down the entire application (unlike a monolithic application)
* Better reflects the structure of your business
  * Having each module separate reflects how the business treats things

### Communication between services

One apparent benefit of a monolithic architecture is that it's obvious how you share functionality between services: if module A needs a function from module B, it can just import it and use it, since they're in the same repository.

With microservices, there are a few approaches to communicating between services:

**HTTP Requests**: Service A makes an HTTP request to service B in order to make a change.

* This is not the best method and should be a last resort.

**Pub/Sub**: One service *publishes* a message, while another service *subscribes* or listens for a message.

* In AWS, we use Simple Notification Service (SNS) to achieve this.

**Message Queue**: A third-party queue accepts messages from services, while another service receives those messages from the queue.

* This is beneficial in high-traffic situations, as the queue can control how much gets processed at a time.
* In AWS, we use Simple Queue Service (SQS) to achieve this.

**Event Streams**: Some services are *event producers*, while other services are *event consumers*.

* This is different from pub/sub because in pub/sub, messages that don't get handled will evaporate.
* Whereas in event streams, there is a **storage layer** that sources the entire state of your application (known as *event sourcing*).
* In AWS, we use Kinesis or Apache Kafka to achieve this.