Serverless

TLDR

Traditionally, when you build a comprehensive Web application, effectively you are managing a number of applications that provide services: Nginx serves the HTML front-end, Express.js handles the API calls, MongoDB acts as a backend storage, etc. Serverless is an abstraction where you don't have to worry about managing these applications and only need to care about writing the code that ties them together. That being said, anyone who says that Serverless is the end-all-be-all, at least in it's current state, doesn't know what they're talking about.

Rise of Serverless

Success of Cloud Computing (IaaS)

• Reduced Cost

  • Less staffing, reduced infrastructure cost

• Reduced Risk

  • Hardware failures and redundancy handled by provider

• Improved Scaling

  • Starting small and growing to additional instances is easy

• Decreased Lead Time

  • Faster to start up with than on-premises equipment

Infrastructural Outsourcing

• Enabled by Economies of Scale

  • Letting one vendor do the same over and over is more efficient than independent vendors

    • Cloud Providers can buy and maintain in massive bulk

  • Largely enabled by OS virtualization

    • One Physical Machine hosting many VMs means more flexibility.

• Public Cloud vs. On-Premises

  • Economies of scale primarily refers to public clouds like AWS and Azure

• Remaining Challenges

  • Server config and management

    • Software updates

    • Security Fixes

Steps Toward Serverless

• Platform as a Service (PaaS)

  • Managing the OS system layer was the next logical step

  • Platform as a service providers like Heroku pop up to allow focusing on applications as a whole

  • Remove or abstract concerns over OS maintenance and scaling

• Containers [as a Service] (CaaS)

  • Containers and container services like the EC2 Container Service (ECS)

  • Similarly allows focusing on the application layer that runs within Docker containers

• IaaS, PaaS and CaaS - Compute as a Service

  • Historically less flexible

    • Charging per hour (though more recent shifting towards per second billing)

    • Taking longer to spin up (sometimes minutes)

What is Serverless?

Defining Serverless

• Serverless

  • Relying on others to manage and configure underlying servers

  • Focused on a single request or requests in aggregate

  • Can scale automatically to a required load without significant additional configuration

  • Costs are tied very closely to utilization and time code spends running

  • Highly available underlying components that are managed for you

• Not Serverless

  • Managing or configuring a dedicated server (physical or virtual)

  • Focus on long-running machines or applications

  • Requires considerations of the number, capacity and utilization of servers

  • Costs are tied to time servers are running (even when idle)

  • High availability is possible with careful planning and management of underlying parts

Backend as a Service (BaaS)

• What Is It?

  • Infrastructural outsourcing of application components

  • Examples:

    • Managed databases

    • Identity management [as a Service] (IDaaS)

    • Email delivery

  • Save us time by providing a part of our application

  • Many BaaS technologies - not all are serverless

• Interfacing with BaaS

  • Usually done via provider's API

  • Frequently integrated right into your application

• Key Benefits

  • Time savings - we don't need to build it

  • Highly available services that are supported by teams specialized to support those services

  • Potential cost savings - economies of scale

Functions as a Service (FaaS)

• What is it?

  • Generic environment in which we can run our code

  • Bundles of code and dependencies are "Functions"

  • Functions run in response to events like

    • HTTP API requests

    • Scheduled events

    • File Uploads

    • Many more!

• Benefits

  • Developers focus more on code and less on infrastructure

  • Code running in response to events means better utilization

  • Costs come from time when functions are actively running

Serverless Application Architectures

Presentation and Delivery Layers

• What Are They?

  • How a user interacts with your application

  • Not all application layers have a traditional 'presentation' layer - imagine an API

  • Traditional applications have these layers too

  • Frequently thought of together as one layer

• Presentation Technologies

  • Static Website Files

  • Frontend Frameworks

  • Mobile Applications

• Distribution Technologies

  • Content Delivery Networks

  • DNS Configurations

• How Is this Different for Serverless?

  • Serverless websites rely on managed content delivery

  • No server ports to configure

  • No scaling or bandwidth to plan for

  • Outsource these responsibilities for hosting delivering and scaling the presentation of your content

Application Layer

• API and HTTP Listerners

  • Usual entry-point for serverless applications

• FaaS

  • Core method of meeting computing needs

  • Request-focused and short-lived

• Integrations

  • BaaS products to help with:

    • Identity

    • Monitoring

    • Email

    • SMS

    • Other common components

Persistence Layers (Data Layer)

• Databases

  • Serverless applications usually rely on fully-managed databases

    • AWS DynamoDB

    • FaunaDB

    • Google Firebase or Firestore

  • The are of serverless lags behind due to issues like:

    • Costs tied to provisioned capacity (not utilization)

    • Data replication is still a challenging and expensive task

    • SQL is still a norm for data analysis and exploration

    • Serverfull databases being the norm

• File Storage

  • Relies completely on cloud services to ensure:

    • High availability

    • Effortless scaling

    • Accessibility

    • Security

  • Examples

    • AWS S3

    • Azure Storage

    • Google Cloud Storage

Multi-Layer Concerns

• Security

  • Partly offloaded to vendors

    • Infrastructure redundancy

    • Securing physical locations

    • Securing provided services to work 'as expected'

  • Still many responsibilities on the organization

    • Configuring access controls

    • Restraining permission creep

    • Not exposing sensitive data and secrets

  • Benefits over traditional IaaS security model

    • Offloads OS and networking security

    • Relies more on IaaS vendors with dedicated security teams

• Logging, Monitoring, and Debugging

  • One of the biggest challenges for serverless applications

  • Serverless is distributed by nature

  • Isolating and fixing issues means knowing how all the components work together

• Deployment

  • Serverless application layers are designed to be decoupled

  • Challenging to deploy and test together

  • Reliance on frameworks and CI/CD pipelines is crucial

Serverless Benefits

Reduced Costs

• Labor and Infrastructure

  • Less operations work

    • Core compute infrastructure is managed by providers

    • Deployment is code focused not infrastructure focused

    • Relying on third-party services means less infrastructure to manage directly

  • Less development work

    • Using third-party services to save developer time

    • Less code to deal with infrastructure means more feature-related code

  • Infrastructure Costs

    • We don't have to over-provision, instead we can scale and pay proportional to actual use

Reduced Risk

• Infrastructural Outsourcing

  • Less for us to worry about

    • Leverages experience of others

    • Offloads maintenance of certain functionality

  • Economies of Scale

    • Usually specialists can build more efficient and resilient services

    • We probably can't solve issues faster than the experts

    • A team focused on one area will likely have better uptimes

  • Example - DynamoDB

    • Do we roll our own NoSQL?

    • Or we rely on a service provider with a known good track record?

    • Frequently, relying on a service provider is less risky than starting from scratch.

Flexible Scaling

• Automatic Scaling

  • In applications where we want it, we should scale automatically with use

    • Scaling up should happen seamlessly

    • Scaling down should be automatic to avoid additional costs

    • All tied closely to small measures of use - usually at the request level

• Limitations and Risks

  • IaaS provider limitations

    • Account limits for maximum capacity of one resource or another

    • Potential restrictions on scale-down activity (DyanmoDB)

  • Risks

    • Automatic scaling means automatic price increase - tie this to your business value or be careful

    • Take steps to mitigate against DDoS attacks - partly the reason for provider limitations

Faster Development

• Less Code to Write

  • Avoiding writing entire chunks of an application - offload to a service provider

  • When you need new functionality, write a third-party integration rather than an entire service

• Streamlined Development Process

  • Smaller chunks of code (the functions in FaaS) are easier to write and maintain than monoliths

  • Smaller services can be iterated and deployed more quickly

  • Can have serverless monoliths but lends itself to microservices more easily

• Faster Development Process Still Scales

  • Normally development speed is traded for scalability

  • Even with rapid development the underlying services can still scale effectively

  • Technical debt still occurs, but services still scale after creation.

Limitations of Serverless

Latency

• Highly Distributed Services

  • Usually at the HTTP level

  • Using multiple vendors with their own latencies and distribution networks

  • Potential for delay

• Limited Ability to Optimize

  • Minimal access to OS and networking layer

  • Rely on provider infrastructure and locations

  • Depends on provider to reduce latency

Giving up Control

• Configuration

  • Limited levels of configurations

  • Opinionated APIs to interact with services

  • Specific runtime environments

• Performance

  • Hardware customization is off the table

  • Many software layers are not customizable

• Issue Resolution

  • Can solve your own bugs

  • Provider issues are out of your hands

• Security

  • IaaS provider handles much of this

  • Limited by options of IaaS providers and other service providers

  • Certain services may not meet organizational or legal needs

• Vendor Lock-In

  • Relying on a vendor means relying on a vendor

  • Development practices can mitigate this

  • Choose carefully

  • Take appropriate precautions

Tooling

• Local Testing

  • Distributed services means local testing can be painful

  • Impossible to locally test some vendor services

  • Tooling to reduce this pain point is growing

• Logging and Debugging

  • Distributed services and distributed logs

  • Tracing issues can required debugging skill and knowledge of the entire serverless stack

• Deployment and Testing

  • Distributed deployment and testing can be a challenge with many moving parts

  • Serverless frameworks can streamline the deployment process

  • Testing portions of frameworks still evolving to fit needs of new development process

AWS Serverless Layers

1. Presentation/Delivery Layer

   1. S3

   2. Route53

   3. Cloudfront

2. Application Layer

   1. Lambda

   2. Gateway

   3. Step Functions

   4. Lex

   5. Polly

   6. SNS

   7. SES

   8. SQS

3. Persistence/Data Layer

   1. AWS DynamoDB
   2. Athena

   3. S3

   4. DynamoDB Accelerator

4. Logging

   1. CloudWatch

5. Security

   1. IAM