2. What to Expect from the Session
• Overview of Serverless Computing
• Introduction to AWS Services for the Workshop
• Outline of the Workshop Scenario
• Preview of the Labs
6. Amazon Elastic Compute Cloud (EC2)
• Allows developers to
obtain compute capacity
on-demand
• Create virtual servers in
the cloud with the click of
a button
• Launched in 2006
7. Amazon Elastic Compute Cloud (EC2)
Match Capacity and
Demand
Global Footprint Elasticity
Provision Servers in
Minutes
Infrastructure as
Code
Programmatic
Networking
9. Serverless Computing
Build and run applications and
services without thinking about
servers
• Fully Managed
• Developer Productivity
• Continuous Scaling
10. Serverless Computing
Fully Managed
• No provisioning
• No system administration
• No security patches
• Fault tolerant
Developer Productivity
• Focus on your application
• Experiment and innovate
quickly
Continuous Scaling
• Scale up and down with
demand
• Never pay for idle
resources
12. AWS Lambda
Run code without provisioning servers
• Run functions in response to events to build
back ends, data processing systems, event handlers
• Code runs in isolated containers on Amazon Linux
• Bring your own code and libraries: Node.js, Python,
Java (even native libraries)
• Run code in parallel – democratized scale
13. AWS Lambda
No Servers to Manage Continuous Scaling Don’t Pay for Idle Resources
Lambda allows you to run
application logic without
provisioning servers or worrying
about the health or security of
underlying resources
Lambda scales infrastructure
beneath your application logic;
just send requests and events
and Lambda will automatically
scale to accommodate it
With Lambda, you’re billed in
100ms increments of execution
time and number of requests
and you’re never charged for
anything when your code isn’t
running
14. The Serverless Manifesto
• Functions are the unit of deployment and scaling
• No machines, VMs, or containers visible in the programming model.
• Permanent storage lives elsewhere.
• Scales per request. Users cannot over- or under-provision capacity.
• Never pay for idle (no cold servers/containers or their costs).
• Implicitly fault tolerant because functions can run anywhere.
• BYOC - Bring your own code.
• Metrics and logging are a universal right.
15. Amazon DynamoDB
Fast and flexible NoSQL database service
for any scale
• Fully managed database built for applications
that need single digit millisecond latency at any scale
• Pay only for the throughput and storage that you need
• Supports both document and key-value data structures
• React to data changes via triggers to Lambda
16. Amazon API Gateway
Create, publish, maintain, monitor, and secure APIs at any scale
Create a unified API
frontend for multiple
backend microservices
DDoS and throttling to
protect your backend
microservices
Authenticate and authorize
requests to your backend
microservices
17. Amazon Cognito
Add user sign-up, sign-in, and data synchronization to your apps
Add user sign-up and sign-
in to your mobile and web
apps
Federate identities and
provide secure access to
AWS resources
Store and sync across
devices
18. Amazon Simple Storage Service (S3)
Durable, massively scalable object storage
• Designed for 99.999999999% durability and
99.99% availability
• Stores trillions of objects and regularly handles
millions of requests per second
• Effectively infinite storage without provisioning
capacity
19. Amazon Simple Storage Service (S3)
S3 is a low-cost, highly available solution for static
website hosting – and it’s completely serverless
• Reliably serve your static website and handle
unexpected peaks without worrying about scaling
your infrastructure
• Integrates with Amazon CloudFront for edge delivery
of content across the globe
21. Scenario: Wild Rydes
Wild Rydes needs your help! With fresh
funding from its seed investors, Wild
Rydes is seeking to build the world’s
greatest mobile/VR/AR unicorn
transportation system. The scrappy
startup needs a first-class webpage to
begin marketing to new users and to
begin its plans for global domination.
22. Scenario: Wild Rydes
The Wild Rydes Serverless Web Application Workshop introduces the
basics of building web applications using serverless infrastructure.
Amazon
S3
Amazon
CloudFront
AWS
Lambda
Amazon
Cognito
Amazon API
Gateway
Amazon
SES
AWS IAM
In this workshop you’ll build a serverless web site for Wild Rydes using
AWS services on the AWS Free Tier.
https://github.com/awslabs/aws-serverless-website-workshop
23. Lab 1: Static Website Hosting
OBJECTIVE: Create a bucket in Amazon S3 and configure it for
static website hosting. Distribute your the website globally using
Amazon CloudFront.
24. Lab 2: Beta Sign-up Mailing List
OBJECTIVE: Allow visitors to submit their email address to subscribe to an email
list for your beta program. Send each submission a confirmation email thanking
them for their interest and providing further details.
25. Lab 3: Administrative Interface
OBJECTIVE: Build an interface for your marketing team to be able to manage
aspects of your site. Start by adding a page to the administrative interface that
allows a user to see all email addresses that have signed up for your beta program.
26. Lab 4: Product Update Blog
OBJECTIVE: Provide visitors updates about your progress building your
product by publishing a blog. Blog entries are posted by administrators using the
administrative interface built in the previous lab.
In this session we’re going to introduce and the workshop and website we’re going to build over the next couple of hours.
First we’ll take a look at serverless computing – its benefits and what problems it addresses.
Next we’ll briefly talk about some of the AWS services that are central in building the website.
Then we’ll look at the workshop scenario and discuss what we’re specifically going to build in each lab.
Before cloud computing Internet startups first had to tackle figuring out how they were going to deliver their services.
Often this involved procuring servers, data center or colocation space, and physically racking, wiring, and managing those servers.
While acquiring and managing these servers wasn’t important to these businesses directly, it was a prerequisite for hosting their new product or application on the Internet.
Along with physical hardware comes a variety of concerns ranging from procurement, data center space, power and cooling, IP transit, networking, capacity planning, etc.
None of this work directly improves the product or services provided to users.
Cloud computing and the launch of EC2 changed the dynamics of building Internet services.
Instead of procuring and managing physical servers, developers could instead provision virtual servers in the cloud within minutes with the click of a button.
With EC2, many of the concerns on the previous slide are handled for you freeing you up to focus on your business and users.
Using EC2, developers realized many benefits along the axes of cost an agility:
EC2 allows you to match capacity and demand – rather than spending money up front to acquire hardware you can instead spin up and down virtual servers to match the resources you need to serve your users.
You can deploy into one of any 14 geographic regions and immediately take advantage of AWS’s global reach.
Easily scale up or down rather than committing to a bulk set of physical resources
Entire clusters of new servers can be provisioned within minutes
EC2 and services like AWS CloudFormation make it easy to define your network infrastructure and manage your infrastructure as code
While we’ve reduced our concern space significantly via cloud computing and moving from physical infrastructure to virtual servers, we’re still tasked with the undifferentiated heavy lifting of system administration of those servers and related infrastructure.
Managing servers still entails work that doesn’t necessarily directly benefit your users – items like managing security patches, ensuring fault tolerance, and capacity planning.
You have to do these items to ensure data security and uptime, but all of the time invested in these efforts is time you’re not spending improving your own products.
Serverless Computing allows you to build and run application without thinking about servers. Serverless services aim to be fully managed, to improve developer productivity, and to continually scale to the exact amount of resources required without developers explicitly configuring the underlying scaling dynamics.
To drill into each of these benefits:
Serverless computing provides fully managed services that do not require provisioning, system administration, updates, or any work on a developer’s plate to achieve fault tolerance. AWS takes responsibility for the underlying compute infrastructure and exposes the services to you an an API
Since you’re not managing servers and administrating configuration management systems, you can invest this time into development of your application on features that benefit your users. These serverless servers aim to lower the cost of experimentation and to help developers innovate more quickly.
This underlying compute infrastructure scales underneath your application which means users are guaranteed a uniform experience regardless of scale and developers never have to pay for spare, idle capacity to accommodate traffic spikes.
We’re going to briefly look at the services we’re going to use in this workshop and introduce some of the high level concepts and benefits.
AWS Lambda lets you run code without provisioning servers.
It lets developers to run functions in response to events – an event could be a file upload to S3, sensor data from an IoT device, a schedule, an API call from another application, etc.
These functions run across a large cluster in isolated containers on Amazon Linux using your own code and libraries. Because Lambda supports Node.js, Python, and Java, you can write the same code you’re writing today and deploy it to AWS Lambda rather than your own servers.
Lambda encourages developers to think of a Lambda function as the unit of parallelization. This allows developers to leverage the scale of AWS Lambda to achieve a high level of parallelization without their own cluster management.
Lambda provides several benefits of standard compute services:
Firstly, there’s no servers to manage. This translates into less work for you and your teams and allows you to instead focus on your application logic. You can instead invest that time into your own app and outsource the undifferentiated problems to AWS such as redundancy and high availability.
Lambda continuously scales along with demand so you don’t have to spend time thinking about provisioning appropriate capacity or defining and monitoring auto-scaling policies.
Typical compute services are billed by how long a given resource is running. Lambda doesn’t charge anything when code isn’t actually running and instead bills by number of requests and execution time of your code in 100 millisecond increments.
When the AWS Lambda team set off to build Lambda, they wrote this bulleted list of objectives for their service which guided the project. These guidelines reflect the design goals of Lambda:
Functions – not applications – are the unit of deployment and there are no machines, instances, VMs, or containers visible to developers.
Developers however can bring their own code based upon commonly used languages and frameworks.
Persistence lives elsewhere in other services and not within Lambda itself
Lambda scales per request and as a design tenant a developer should never pay for idle resources.
As functions can run anywhere, running functions on Lambda implicitly is fault tolerance
And finally, introspection for operations of your applications is an explicit goal phrased here as metrics and logging are core to the service.
The second service we’ll look at is DynamoDB. We’ll be using DynamoDB extensively in our workshop.
You can think of DynamoDB as a serverless database in a similar way to Lambda as serverless compute. As I mentioned, persistence was an anti-goal for Lambda, DynamoDB provides a persistence layer that you can leverage for your applications without managing servers.
It’s a fully managed NoSQL database designed to provide consistent, single-digit millisecond latency regardless of scale.
It supports both document and key-vale data structures similar to other NoSQL data stores you may have worked with in the past.
DynamoDB is fully integrated with Lambda in that you can build a Lambda function to execute and react to data changing within DynamoDB as a database trigger.
Amazon API Gateway allows you to build and publish APIs and offload the management and scaling of the underlying resources beneath those APIs.
API Gateway is integrated with Lambda meaning you can define an API endpoint – for example /posts – to execute a Lambda function and return the results to a user. This means developers can build full production user-facing APIs without provisioning a server for either the web or application layers.
It includes many advanced features like integrated authentication and authorization against AWS SigV4 authentication or your own custom logic, DDoS protection and throttling, and allocation of usage plans to different users of your API.
Amazon Cognito is a user management service. Instead of building, securing, and scaling a system to handle user management, authentication, and data synchronization, you can instead focus on creating great app experiences.
Every product development cycle contains a few weeks of undifferentiated items like “build a login flow” and “create a password reset system.” Cognito gives you a speed boost by taking care of these rote backlog items for you.
Cognito is integrated with third party login provides like Facebook, Twitter, Google, Amazon, or any third party identity provider that exposes a SAML interface. Likewise, with Cognito your user pools, you can manage your own users in the cloud securely without spending any time architecting your own identity system.
Amazon Simple Storage Service is one of AWS’ oldest services – it’s a massively scalable object store that provides serverless storage.
It stores trillions of objects and regularly handles millions of requests per second and provides effectively infinite storage without any provisioning.
Like other serverless servers, it provides continuous scaling, you never pay for idle resources, and allows you to focus on your application rather than commodity object storage.
In addition to providing serverless storage, it’s also a very lightweight static website hosting platform. In our workshop, we’ll lean on S3 to provide delivery of both HTML and assets for our marketing site.
When used in concert with CloudFront – AWS’ global web content delivery service – and services like API Gateway and Lambda, we can build an entire user facing website ready for users across the globe ready for any scale without any servers.
We’re now going to talk about the workshop and look the modules and what we’re aiming to build in each.
In this scenario, we’re building a marketing site for Wild Rydes, which is a fictional transportation startup that allows you to hail a unicorn from anywhere in the world.
The site we’re going to build is currently hosted on wildrydes.com. In this workshop we’re going to start with a static HTML website and build new features on top of it to promote our new business.
Using some of the services we talked about and other services like Amazon Simple Email Service – our email delivery service – and AWS Identity and Access Management – which provides control of access for AWS resources – we will build a serverless website.
All of these services are actually covered under the AWS Free Tier if your account is under 12 months old.
The materials are available open source on GitHub and we’ll be using that repo through the workshop today.
The first module of the workshop stages our static website on top of Amazon S3 and Amazon CloudFront. At the end of this lab, our website will be available via CloudFront and distributed through AWS’ content delivery network of over 60 POPs throughout the world.
Next, we’ll add some functionality to our website. As you can see on wildrydes.com, the landing page contains a form for users to submit their email addresses. In this lab, we’ll do several things:
We’ll create an email addresses table in DynamoDB for users who are interested in signing up with our beta program
We’ll use Amazon Cognito to allow unauthenticated users access to add their email address to our DynamoDB table
Using DynamoDB triggers, we’ll create a Lambda function to send a confirmation email to users who sign up with our beta program
The next lab layers on an administrative interface on top of our website.
Here we’ll use Amazon Cognito Your User Pools to create a pool of administrator users. These will be folks from our marketing department who want to manage aspects of our website.
We’ll then create an administration interface to allow these administrator users to look at the list of email addresses that have signed up with our beta program.
Building on our administration interface, we’ll next build a simple blog to update our beta users on our product development progress. Using API Gateway, we’ll create an endpoint to read all blog posts, and an endpoint to create new blog posts.
The endpoint to create blog posts will only be accessible by our administrator users and we’ll configure it to ensure only authorized users can post to our blog. Any visitor to our site should be able to view the blog.