Serverless Architectures Examples
Serverless Architectures
Serverless hosted website: MyBlog.com
- This website should scale globally
- Blogs are rarely written, but often read
- Some of the website is purely static files, the rest is a dynamic REST API
- Caching must be implement where possible
- Any new users that subscribes should receiv a welcom email
- Any photo uploaded to the blog should have a thumbnail generated
- S3 static website, API Gateway, ElasticeCahce for S3, Kinesis with SNS, DynamoDB, Simple Email Service (SES)
Serving static content, globally
Adding a public serverless REST API
Leveraging DynamoDB Global Tables
User Welcome email flow
Thumbnail Generation flow
SQS, SNS, S3, Lambda, S3, CLoudFront
AWS Hosted Website Summary
- We’ve seen static content being distributed using CloudFront with S3
- The REST API was serverless, didn’t need Cognito because public
- We leveraged a Global DynamoDB table to serve the data globally
- (we could have used Aurora Global Database)
- We enabled DynamoDB streams to trigger a Lambda function
- The lambda function had an IAM role which could use SES
- SES (Simple Email Service) was used to send emails in a serverless way
- S3 can trigger SQS/SNS/Lambda to notify events
Micro Services architecture
- We want to switch to a micro service architecture
- Many services interact with each other directly using a REST API
- Each architecture for each micro service may vary in form and shape
- We want a micro-service architecture so we can have a leaner development lifecycle for each service
- API Gateway, AWS Dynamo global stream, Aurora Global, Lambda, Route53, Elastic Load Balancer, ElasticCache
Micro Services Environment
Dicussions on Micro Services
- You are free to design each micro-service the way you want
- Synchronous patterns: API Gateway, Load Balancers
- Asynchronous patterns: SQS, Kinesis, SNS, Lambda triggers (S3)
- Challenges with micro-services:
- repeated overhead forr creating each new microservice
- issues with optimizing server density/utilization
- complexity of running multiple versions of multiple microservices simultaneously
- complexity of running multiple versions of multiple microservices simultaneouly
- proliferation of client-side code requirements to integrate with many separate services
- Some of the challenges are solved by Serverless patterns
- We sell videos online and users have to paid to buy videos
- Each videos can be bought by many different customers
- We only want to distribute videos to users who are premium users
- We have a database of premium users
- Links we send to premium users should be short lived
- Our application is global
- We want to be fully serverless
- DynamoDB, Lambda, REST HTTPS, Cognito, CloudFront, OAI
Start simple, premium user service
Add authentication
Add Videos Storage Service
Distribute Globally and Secure
Distribute Content only to premium users
Premium User Video service
- We have implemented a fully serverless solution:
- Cognito for authentication
- DynamoDB for storing users that are premium
- 2 serverless applications
- Premium user registration
- CloudFront Signed url generator
- Content is stored in S3 (serverless and scalable)
- Integrated with CloudFront with OAI for security (users can’t bypass)
- CloudFront can only be used using Signed URLs to prevent unauthorizeed users
- What about S2 Signed URL? They’re not efficient for global access
Software updates offloading
- We have an application running on EC2, that distributes software updates once in a while
- When a new software update is out, we get a lot of request and the content is distributed in mass over the network. It’s very costly
- We don’t want to change our application, but want to optimize our cost an CPI, how can we do it?
- ECS, load balancer, Cloudront, S3 + OAI, Lambda, DynamoDB
Our application current state
- auto scaling group, multi-AZ, Amazon EFS
Easy way to fix things!
- CloudFront
- No changes to architecture
- Will cache software update files at the edge
- Software update files are not dynamic, they’re static (never changing)
- Our EC2 instances aren’t serverless
- But CloudFront is, and will scale for us
- Out ASG will not scale as much, and we’ll save tremendously in EC2
- We’ll also save in availability, networl bandwith cost, etc
- Easy way to make an existing application more scalaable and cheaper!
Big Data Ingestion Pipeline
- We want the ingestion pipeline to be fully serverless
- We want to collect data in real time
- We want to transform the data
- We want to query the tranformed data using SQL
- The reports created using the queries should be in S3
- We want to load that data into a warehouse and create dashboards
- Dynamo realtime, S3 select, Athena, Kinesis Redshift, Kinesis stream, S3 static
Big Data Ingestion Pipeline
- IoT devices, Kinesis Data streams, Kinesis Data Firehose, AWS Lambda, S3 Bucket, Simple queue Service, AWS Lambda, Athena, S3, Amazon QuickSight, Amazon Redshift
Big Data Ingestion Pipeline discussion
- IoT Core allows you to harvest data from IoT devices
- Kinesis is greate for real-time data collection
- Firehose helps with data delivery to S3 in near real-time (1 minutes)
- Lambda can help Firehose with data transformation
- Amazon S3 can trigger notifications to SQS
- Lambda can subscrible to SQS (we could have connecter S3 to Lambda)
- Athena is a serverless SQL service and results are stored in S3
- The reporting bucket contains anlyzed data and can be used by reporting tool such as AWS QuickSight, Redshift, etc…
This post is licensed under CC BY 4.0 by the author.