Workshop : Wild Rydes Takes Off - The Dawn of a New Unicorn
•
1 like•1,006 views
by Rich Cowper, Manager of Solutions Architecture, AWS
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Workshop : Wild Rydes Takes Off - The Dawn of a New Unicorn
Similar to Workshop : Wild Rydes Takes Off - The Dawn of a New Unicorn (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (18)
Workshop : Wild Rydes Takes Off - The Dawn of a New Unicorn
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Rich Cowper, Startup Solutions Architect 26-Jan-2017 Wild Rydes Takes Off – The Dawn of a New Unicorn Building Serverless Web Apps
- 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
- 5. Physical Hardware – Concern Space • Procurement • Power • Cooling • Asset Tracking • Remote Hands • IP Transit • Colocation • Capacity Planning • Hardware Refreshes • Storage • Depreciation • Physical Security • Networking Equipment • Cabling
- 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
- 8. Servers – Concern Space • Configuration Management • Security Patches • Server Utilization • Operating Systems • Auto-scaling Policies • Monitoring • Intrusion Detection • Resiliency • Machine Images • Access Management • Capacity Planning • Hourly Billing • Code Deployment
- 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
- 11. Services
- 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.
- 28. Remember to complete your evaluations!
Editor's Notes
- 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.