Standard Serverless Architecture for Mobile Backend using AWS
In this story, we will discuss what a standard Serverless Architecture should have in building a Mobile Application, it is not a framework or bulletproof for any use cases, but it is kick start architecture for anyone who would like to have full total ownership of your Mobile backend but without the overhead of operation support and cost to maintain servers, the reason I mention about ownership is the control and extension that you want to have in the future. There are many ways can build Mobile Backend, some will have partial or zero control over what you allow to do to extend your Mobile Application, but they provide a very easy start for Mobile Centric development team to build a Mobile Application without a real backend, e.g: Firebase, Streamdata.io. Although the concept of serverless being around for quite some time, it is still not easy to switch your architecture mindset from Server to Serverless, I hope the example I share below will able to help you easily adapt serverless components in your future design.
Background
Everything starts from a list of requirements, to make the Architecture more relevant we give a setting for us to begin.
Company DoryNet just start as a new Mobile Virtual Network Operator in India, and sign up a Network Loan contract with one of the biggest Telco in India. As a new Telco business, they want to focus in Prepaid service in provide Data and Call plan to India people. To speed up the market adoption, they want a Mobile Solution for their customers to conveniently buy Data and Call Plan, to attract more user, they would like to introduce reward point for customer when they purchase Call and Data plan, the reward point that accumulated can be use to redeem voucher that partner with DoryNet. Lastly they would like to have Offer Deals for Call or Data plan to targeted customer to increase the sales.
User Stories
From the above background, we extract the following high-level stories:-
- As a user, I want to able to buy DoryNet telco products from the App.
- As a user, I want to receive a reward point when I buy DoryNet telco products.
- As a user, I want to view what kind of voucher I can redeem with my reward point.
- As a user, I want to enjoy the special offer DoryNet product.
High-Level Architecture Diagram
With some assumptions and the stories provided, we can come out the standard Architecture using serverless style as below:-
The architecture above explains the high-level components, CI/CD Pipeline, and developer tools to build and support your application. All the components select from either serverless or manage service by AWS, it considers as average difficulty in term of implementation and makes the balance of flexibility to grow in the future. If your team has enough skillset, you can consider replacing the traditional RESTful API for Admin Panel backend to GraphQL, as it gives more flexibility in creating the Admin Panel, but it will be more effort in the front-end development.
Here the rationals for use of each component:-
AWS Route 53:
It is the DNS service provided by AWS, it has many features, but in our use case it just serves as a DNS service, you can freely replace it with another DNS provider.
AWS WAF:
Web Application Firewall is required to protect your backend against common attacks such ask DDOS attack and API flooding.
AWS CloudFront:
AWS CDN manage service, it is very important to have CloudFront in a Serverless Architecture, it must be set up before the API gateway and S3 to effectively reduce backend latency with Caching. In the event of Campain running and suddenly increase the usage of the API, it will effectively mitigate the spike to the backend. Lastly, it also helps save costs when the user requests data from S3.
AWS API Gateway:
It is a must component to use in Serverless Architecture, it serves as an API management tool, authorizes, and an authentication layer in which you can implement Lambda authorizer to use your own authorization logic. And most importantly it can use to throttle the traffic the reduce the load to the downstream system. But it has one know limit which is the maximum timeout limit is 29 seconds, it will disconnect the connection after 29 seconds regardless of the backend connectivity. In a case where your API requires more than 29 seconds, and you want to use API synchronize call, your design it wrongly, you should either change to Pooling pattern or Fan-Out with Pub-Sub pattern to decouple the synchronous flow into an asynchronous flow.
AWS PinPoint:
It is a new managed service that launches in 2018 Jan to help businesses manage campaigns easily. It focuses on a few key areas which are campaign management, campaign channeling, and user segmentation. The key highly for their campaign channeling is a global reach service to multiple channels including email, SMS, push notification, and voice messages. In our use case, we will use it for the targeted customers to offer special telco products. For a replacement service, I can see Google Firebase is the direct replacement.
AWS Cognito service:
A managed service by AWS to help federate Social and Enterprise identity, it claims to be easily set up and AWS Cognito will help you manage authentication flow, it supports OAuth 2.0, SAML 2.0, and OpenID Connect protocol. In our use case, it will be used for access control on the Admin Panel, it allows federate to the existing user directory or it can be used to manage your user in AWS, more comprehensively you can apply role-based access control to manage module permission in Admin Panel.
AWS DynamoDb:
Key-value and document database that delivers single-digit millisecond performance at any scale. It’s a fully managed, multi-region, multi-master database with built-in security, backup, and restore. It can be easily integrated into AWS Lambda to run as a message broker. For our use case, it serves as persistent storage for campaign data, user data, product metadata, user rewards, redemption transaction, and more.
AWS Lambda:
Function base serverless compute service, you just need to concern about the code you write, AWS will handle the provisioning and scale for you. It is the first-class component in implement Serverless Architecture, the most powerful feature for AWS Lambda is, it is seamlessly integrated to near 50 types of AWS components. For our use case, we will use an API server for mobile, an API server for the admin panel, an image processor to generate a thumbnail to display voucher or merchant image in the app. One drawback of AWS Lambda is the Cold-start issue. As Lambda underneath also provision into the container, the time to spin up a new processor in the container will be varied by the code language you use, the memory size you provision, and VPC or non- VPC Lambda.
AWS S3:
Object storage service by AWS is theoretically unlimited grow the size and pay per use, it offers industry-leading scalability, data availability, security, and performance, it can store anything you can think of. In our use case, it will be used to store our admin panel static files such as Html, Js files, and CSS files. It also will be used to store all the resource files used by the mobile app and admin panel such as JSON files, images, pdf, and video. For static files use case, it can be directly converted into a webserver to run Single Page Application (SPA) if you plan to use Angular or RectJS.
AWS Elastic Cache:
Fully-managed in-memory data store, it offers Redis and Memcached engine, if you tend to store more on key-value data for string content, Memcached will be the choice, else Redis always the first consideration due to its rich data type support and features. Elastic Cache will be used as the cache layer to keep “Hot Data”, which will be the data that always want to get access but the chances of modifying are very rare, a simple use case to increase the read efficiency of voucher merchant list, the merchant list can keep in Elastic Cache for different copy base on the view type when the user opens the merchant list, it is not required to recalculate again to sort the data by different option.
AWS Pipeline:
The Pipeline here is the grouping of service set to form CI / CD setup, which is AWS CodePipeline, AWS CodeComit, AWS CodeBuild, and AWS CodeDeploy. It can be used to integrate to other 3rd party services like Github or Jenkin. The main use case of the AWS Pipeline toolset is because of its fully managed service, and you just require to configure, there is a very rare case of your build server not functioning.
AWS CloudWatch:
A monitoring and management service built for developers and infra team, underneath AWS services, AWS CloudWatch service as the main component to implement logging, monitoring, and scheduling, it is the default place to check your lambda log in the cloud environment. In our use case, it is used for Lambda logging and triggers Lambda to “warm up” Lambda.
AWS X-Ray:
Application monitoring service requires the code integration effort into your existing service. It gives the overall health status of your application by up to the last 6 hours, and it will be used for the developer to trace the problem in the AWS environment.
AWS SSM Parameter Store:
A parameter storing service to keep all your key to be used inside AWS environment, it can be used to store credential information, as only authorized users can decrypt and view the content. In our use case, it will be used to store connection information for Elastic Cache, DynamoDb table name, and other 3rd party credential key, an application will be load the actual key from the parameter store without keeping the key inside the code, which reduces the risk of credential leaking from the source code.
Conclusion
In this story, we discuss the benefit of porting from Server-based architecture to Serverless based architecture, and we use an example use case to start building a full Serverless Architecture for Mobile Backend. On top of that, we also discuss the usage of each suggested component in the design. As you can notice from the list of components we suggest, there is no server, and it is pay-per-use, unlimited scale, build in security feature, and high availability, it will be very hard to achieve similar scalability and availability by using conventional server way. Thanks for reading until here, do comments if you think of a better design for a Standard Serverless Architecture should be.
