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.