Eat your own dog food: how AWS leverages Serverless
Tim Bray from Amazon gave a great talk at re:Invent 2018 where he shows us how AWS uses Serverless technologies. Did you know that some of the newer services such as API Gateway and EKS are using API Gateway and Lambda to implement the control plane? In this post, I summarise a few interesting points he made. I also encourage you to watch the full video.
SQS provides message queues as a service. The following figure shows a high-level architecture of the SQS service.
When a client make calls to the SQS API, you talk to the Front End service of SQS. The Front End service asks the Metadata service (backed by DynamoDB) for internal data about the queue. Does it exist? How does the queue policy look like? Which Back End cluster is responsible for the queue? Once the Front End knows the answers, it likely checks if the requestor is allowed to make the request and routes the request to one of the many Back End clusters to process the message. A single Back End cluster is responsible for one or many queues (or partitions of a queue) and stores your messages in a distributed manner on the cluster.
In the background, the Load Manager service continually checks the utilization of the Back End clusters. If a cluster gets hot, the queues are partitioned and/or moved to other/new clusters. If clusters idle, queues are moved as well to shut down whole clusters. As users of SQS, we don’t see any of this. We send and retrieve messages.
One funny anecdote Tim shares with us: the SQS team replaced an Oracle Database with DynamoDB.
Hej, Andreas & Michael here!
We launched the cloudonaut blog in 2015. Since then, we have published 325 articles: small tips and tricks, best practices, and service reviews. We enjoy writing about all things AWS a lot.
Do you like our blog posts and podcast episodes? Have you learned something new? Consider supporting us create in-depth and independent AWS content. Please help us with a monthly or one-time payment through GitHub Sponsors.Start supporting us today!
Amazon MQ runs ActiveMQ brokers on your behalf. The following figure shows a high-level architecture of the ActiveMQ service.
The brokers itself run on EC2 Instances and likely persist your state on EBS volumes. Tim calls this the Data Plane. Interestingly, the Control Plane (e.g., the public API) is implemented using API Gateway and Lambda functions that store the state about the ActiveMQ clusters in DynamoDB.
Also, Tim talks about a few other services that come with Serverless control planes:
- Amazon SageMaker
- AWS Batch
- AWS Elemental
- AWS AppSync
- AWS IoT Core
- Amazon GuardDuty
- Amazon EKS
- Amazon API Gateway
Funny story: API Gateway itself uses a Serverless control plane.
I hope you are now interested in the full talk!
What’s your favorite talk from re:Invent? Let me know!