Evolving Architecture | Serverless Patterns and Use Cases
It’s 2018. Unless you were hiding behind a rock, everyone has heard about Serverless. Today, serverless architectures are becoming popular day by day at an exponential rate.
As we know there are servers behind serverless architecture. So what is the point? Following are the key principles of Serverless.
No servers to provision or manage
Scales with usage
Built-in availability and fault tolerance
Above advantages make serverless simply irresistible to not to use it for new and existing solution architectures. Today, let’s discuss several real-world use cases for Serverless.
- Web applications
- Event-driven data processing
- Stream processing
- Conversation bots
- Serverless workflows
Although I am going to use AWS cloud diagrams to discuss above patterns, most of the leading Cloud Providers supports these architectural designs.
Serverless Web applications are the most popular use case of Serverless computing. Consider the following scenario.
You are the CTO of the largest shopping mall. You have 10,000 users daily visiting the site. The application has a web, mobile frontend and an API connected to a database. Currently it’s running inside on-premises servers that incur huge cost for the company. You want to move the entire site to AWS Cloud for higher availability and cost reduction.
How do you go about doing this migration?
Following considerations matters when it comes to serverless web applications.
- The running cost of the web application should be a minimum
- Ability to run and monitor web application to achieve business values
- Web application data must be protected at all cost
- Web application should be able to recover from service disruptions
- Web application should meet the performance criteria in the requirements
In the given scenario, we have a static web application that talks to an API. In AWS, the best way to host your static web application is on S3.
The very first request will be sent over to S3 to fetch website files, and CloudFront will cache the files when the content is returned to the user/browser. All subsequent requests coming from other browsers/clients will be served by CloudFront cache, hence it is quick!
Next we have a rest API to plug into the architecture. Let’s use AWS APIGateway as our rest api.
API Gateway is the serverless API offering from AWS. It scales up to serve any number of requests coming from the clients. Once the requests are received at the API Gateway it will forward to the attached resource or to the proxied service, in this case AWS Lambda. AWS Lambda is the serverless compute offering from AWS. It can spin up hundreds of thousands of parallel lambda functions to execute business logics from any number of requests. You don’t have to worry about scaling up or down hence Serverless!
The logic handling inside Lambda function could consist of talking to a database. In the above scenario, they say it’s online shopping mall. Let’s use AWS DynamoDB, the fully managed NoSQL database offering from AWS.
Yet our architecture is incomplete with out security in place. Since this is a online shopping mall, security is utmost important. Let’s plug AWS Cognito service into the architecture.
Separating users from the application is a good practice for a serverless application. This will allow the users to grow without affecting the performance of the Application. You can make sure that the application supports billions of users with industry standard authentication and authorization protocols.
AWS Cognito can be used for both authentication and authorization needs. Cognito has two parts, Cognito User Pool and Cognito Federated Identities.
Cognito UserPool is your pool of users. It will manage all the users of the application. It supports multiple industry standard protocols for authorization such as OAuth 2.0 and SAML.
Cognito Federated Identities, will apply AWS Policies for signed in users which state what resources are allowed or denied for the logged-in user. Once the user is logged in, he can make calls to downstream services, they will only allow if an only if the user is allowed to invoke them.
We can use IAM policies to secure downstream services at three levels.
- API Gateway level security
- Database level security
Alright! We have everything setup according to the given scenario.
Event Driven Data Processing
Now that the application is up and running successfully on S3, developers started optimizing the site. One of the complaints from customers was, “The site is very slow”.
You found that, loading high-resolution product images at the landing page causes the slowness. As a remedy, you decided to generate a thumbnail each time a product image is uploaded and show it on them on the landing page hence, speed up the site loading.
Event driven data processing is another major use case of serverless computing. According to the above scenario, let’s create a Thumbnail of the uploaded image to S3 asynchronously.
When the site admin uploads a product image to S3, it will emit S3 PUT event. We can set a Lambda function that is triggered by this event. This is completely asynchronous processing, hence it nicely fit into the architecture by decoupling the thumbnail generation process. Moreover, since we use lambda for processing it will scale out well even at high number of requests.
Let’s continue with the scenario.
As another improvement, you wanted to add a Search Engine to the website such that users can search products conveniently even without knowing the exact name/brand of the product.
You decided to use Elasticsearch to index all the product information as the new products are added to the database.
How can you plug Elasticsearch into the current architecture?
Elasticsearch is a Lucine based search engine. According to the scenario, we can index products in the Elasticsearch cluster to search products super fast. In order to index items in Elasticsearch in more asynchronous manner, we can use DynamoDB stream.
Stream is a time-ordered sequence of data. DynamoDB generates a stream of item level modifications. We can setup a Lambda function to be triggered when an item is created in the DynamoDB.
Lambda function will only be triggered by the create-item stream. It will extract the new create item payload from the stream and index in the Elasticsearch, hence frontend users can query against the elasticsearch for quick and easy search.
The CTO got more requests from management.
As the site getting popular, Managers wanted to view website metrics in real-time to get insight about,
> Who visits the website
> Visitor count
> Time spent on the site
> Page views
> How many visitors almost bought a product and quit
How can you implement real-time data processing in the architecture?
One of the key pillars of a well-architected serverless application is “Operational Excellence”. Managers should be able to derive business values monitoring logs. Following is a real-time user event-log aggregator that provides valuable analytics as described in the scenario for the managers.
The website is hosted in S3. We can set up AWS Pinpoint service to log user events at points of interests(Checkout page/ Login Page etc…) and stream those events to Kinesis Firehose.
In order to analyze the events for interested data and run aggregation we can use Kinesis Data Analytics to tap into the stream during a predefine window (Time-based or Size-based). Kinesis Data Analytics uses SQL to query data stream. It creates a virtual table from the defined window of stream and run the SQL query. We can hook a Lambda function consume that information and index in Elasticsearch. Once the data is in the Elasticsearch, we can use Kibana or another visualization tool to visualize interesting patterns.
We have an interesting requirement for the website.
To improve the user experience (UX) of the site, you as the CTO, decide to integrate conversation bot where users can search and order items by voice. The bot will reply in voice for all queries of users.
AWS Lex is a managed service that allows developers to create conversational bots in simple steps. The developers don’t need to be Deep Learning or NLP (Natural Language Processing) experts. They just have to provide several example phrases and corresponding Lambda functions to execute. AWS Lex will then create an NLP model with Deep Learning functionalities. It will be trained over the time.
Lambda functions attached to Lex can perform operations (Eg: Create order) and respond in voice using AWS Polly, which is a text to speech service.
Let’s go on with the online shopping mall scenario.
You have three main vendors that supply inventory for the company. You need to set up a workflow to check your inventory for products quantity less than 5 and place orders from the corresponding vendor. If the vendor cannot be contacted label the products as less than 5 items otherwise update the new quantity.
How can you break down the workflow into steps?
How can you keep the state (Track the step) of the request?
According to the story, the company has only three main vendors. All the products belong to one of these vendors. If a product quantity is less than five, a reordering process should happen from the corresponding vendor.
Lambda is the compute building block for the serverless application. Lambdas are intended to run single operation at a given invocation. When we add logics for multiple operations that depend upon one another, there could be timeouts if all operations took more than 300s to complete. Then there is a problem.
In fact, Single Responsibility Principle (SRP) is a good design patterns to follow at any context to have decoupled and manageable unit of code. Because of that, AWS introduced Step Function, that provides a set of connected tasks (Can be lambda functions) to run workflows.
When we distribute the workflow across multiple lambda functions, how can we keep the status of the request? In other terms, how can we keep the state?
Step Function provides the solution. It is a state machine that will be invoked upon an event (Eg: Http call from APIGateway) and keep it running until the workflow is completed. Hence keep the status/state of the request.
Above diagram is a picture of the state machine. At the first step, it will run a lambda function to get all the products with less than five items. At the second step, it will run another lambda function on the payload that is passed from the first step to extract the vendor. Then it will run a SWITCH on vendors. It is just like a normal switch logic, that triggers corresponding reorder function from the corresponding vendor. (Eg: Calling the API of Vendor). If vendor did not reply, it will trigger the default lambda that will update the product’s label as *Less than 5 items.
We almost at the end of this long post. This post is about Serverless patterns and use-cases. Serverless architecture allows us to start small with minimum cost and gradually evolve the architecture with rich features and functionalities yet keeping the architecture highly scalable and cost-effective.
That’s why we all love serverless!
For AWS video tutorials visit — https://awsvideos.com