Designing Serverless Web Applications with Amazon Web Services

Hello everyone! I’m Stefano, a Data Engineer at Quantyca — an IT consulting company — and every day I am committed to facing new technological challenges in data management, system integration, Big Data architectures, and software development.

In this post, I will explain what serverless computing is and how to design a serverless architecture using Amazon Web Services (AWS) tools. In the first chapter, we will introduce the concept of serverless computing and list the advantages and disadvantages of this approach. In the second part, we will explore a typical three-tier architecture and which AWS services we can implement based on our needs. Finally, I will describe the sequence diagram of a simple use case implemented with some AWS serverless services.

Photo by Andreas Kind on Unsplash

What Is Serverless Computing?

Serverless computing is a method of providing backend services on an “as used” basis. Serverless architecture allows users to write and implement code without having to worry about the underlying infrastructure. However, despite the name, serverless does not mean that the code runs without servers, but it means that the concerns about the server management disappear for developers. For this reason, in this architectural paradigm, there is no need to purchase, rent, or provision servers in advance in order to host and execute the server-side code.

Traits of serverless architectures:

• Low barrier-to-entry: it’s relatively straightforward to start getting your code running in a serverless architecture.
• Hostless: there are no servers to work with, this brings a significantly less operational overhead on their maintenance.
• Stateless: the compute containers running your code will automatically be created and destroyed by your platform hence you can’t store anything in memory.
• Elasticity: this means there is no need for the manual management of resources, and that many challenges in resource allocation disappear.
• Distributed: since deployment units are very small, serverless architecture is intrinsically distributed.
• Event-driven: this paradigm promotes production, detection, consumption, and reaction to events and as a result, there will be a low level of coupling between the components of the architecture.

Limitations of serverless architectures:

• Vendor control: with any outsourcing strategy you are giving up control of some of your system to a third-party vendor and such lack of control may manifest as system downtime, unexpected limits, cost changes, loss of functionality, and more.
• Vendor lock-in: almost certainly Serverless features from one vendor will be implemented differently by another vendor. So, if you want to switch vendors you’ll probably need to change your operational tools, your code and, your design or architecture.
• Startup latency: cold starts may add latency to an invocation.
• Execution duration: the duration of executions can be limited.
• Unpredictable cost: since the majority of services are pay-per-use, it’s difficult to predict the final cost.
• Testing and debugging: since everything is and runs in the cloud, there is no local environment to test and debug the developed code.
• Monitoring and observability: the choice of adopting an architecture where services are decoupled leads to significant difficulty in monitoring and observing what is happening in the system.

Three-Tier Serverless Architecture With Amazon Web Services

In this section, I describe how AWS’s serverless services can be used to change the way you design three-tier architectures and implement popular patterns such as microservices, mobile backends, and Single-Page Applications. In order to give readers a more complete view of this type of architecture, some AWS non-serverless — but widely used — services will also be described.

A three-tier application generally consists of the following components:

1. Presentation Tier: it is a component that users directly interact with (Mobile App UI, Web Pages, etc.)
2. Logic Tier: it contains the application Business Logic (data processing, database operations, etc.)
3. Data Tier: it storages media (Databases, Object Stores, Caches, File Systems, etc.) and hold the data relevant to the application.

Presentation Tier

The presentation tier is responsible for interacting with the logic tier via the endpoints exposed over the internet. Any client or device can communicate with these endpoints, giving your presentation tier the flexibility to take many forms (Desktop Applications, Mobile Apps, Web Pages, IoT devices, etc.). Depending on your requirements, your presentation tier can use the following AWS serverless offerings:

• Amazon Cognito is a serverless user identity and data synchronization service that allows you to add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily.
• Amazon Simple Storage Service (S3) allows you to serve static websites, such as single-page applications, directly from an S3 bucket without requiring the provision of a web server.
• AWS Amplify is a static web hosting service that accelerates the application release cycle by providing a simple CI / CD workflow for building and deploying static web applications.
• Amazon CloudFront is a content delivery service that uses Amazon’s global network of edge locations as connection points for clients using your API. This helps decrease the response latency of your API.

Logic Tier

The logic tier of the three-tier architecture is where the business logic is implemented. You can design a serverless logic tier by adopting these services:

• Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. Clients integrate with the APIs exposed via API Gateway using standard HTTPS requests. API Gateway allows you also to associate a method with a Lambda function, so when you call that endpoint, API Gateway invokes the related Lambda function.
• AWS Lambda is a serverless computing service that allows you to run arbitrary code functions in any of the supported languages without provisioning, managing, or scaling servers. Lambda functions can perform any kind of computing task, from serving web pages and processing streams of data to calling APIs and integrating with other AWS services. You can use an AWS Lambda when: tasks run for a short time; tasks are self-contained; you need to decouple your application modules due to different levels of workload.
• Amazon Elastic Computing Service (ECS) is a highly scalable, fast, container management service that makes it easy to run, stop, and manage containers on a cluster. Your containers are defined in a Task Definition which you use to run individual tasks or as a service. Within an ECS cluster, you can adopt both AWS Fargate that is the serverless compute engine for containers and Amazon Elastic Compute Cloud (EC2) where you have complete control over your computing resources.

Data Tier

AWS offers a number of serverless and non-serverless data stores that you can use to compose a serverless data tier of your application.

These are serverless data storage options:

• Amazon Simple Storage Service (S3) is an object-oriented storage service that offers scalability, data availability, security, and performance.
• Amazon Aurora is a relational database that combines the performance and availability of traditional databases (e.g. MySQL and PostgreSQL) with the simplicity and cost-effectiveness of open source databases.
• Amazon DynamoDB is a fast and flexible non-relational (NoSQL), key-value, and document database. It is a fully managed, serverless, multi-region, multi-master, durable database with built-in security, backup and restore, and in-memory caching for internet-scale applications.
• Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL.
• Amazon Redshift Spectrum is a serverless feature of Amazon Redshift. It is a query processing engine that allows to join data that sits in Amazon S3 with data in Amazon Redshift.

These are non-serverless data storage options:

• Amazon Relational Database Service (RDS) is a managed web service that makes it easier to set up, operate, and scale a relational database using any of the available engines (Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server) and running on several different database instance types that are optimized for memory, performance, or I/O.
• Amazon Redshift is a fast, fully managed, data warehouse service that makes it simple and cost-effective to efficiently analyze all your data using your existing business intelligence tools (optimized for datasets ranging from a few hundred gigabytes to a petabyte).
• Amazon ElastiCache makes it easy to set up, manage, and scale distributed in-memory cache environments. It is a fully managed deployment of Redis or Memcached.

Logging And Monitoring

• CloudWatch is a monitoring and management service that provides data and insights for AWS, hybrid, and on-premises applications and infrastructure resources. CloudWatch enables you to monitor your complete stack (applications, infrastructure, and services) and leverage alarms, logs, and events data to take automated actions.

Web Application — Simple Use Case

In this section, I want to propose a serverless design and five AWS serverless services that can be used to implement a very simple Web Application.

These are the steps and the AWS services proposed:

1. The Client, via the specific URL, retrieves the static content of the Web Page located in an Amazon S3 Bucket.
2. The authentication of users is through Amazon Cognito which manages both the sign-up and the login.
3. In order to get dynamic content, the request passes through the Amazon API Gateway.
4. The request is authenticated with Amazon Cognito.
5. After request authentication, Amazon API Gateway invokes the AWS Lambda related to the specific endpoint.
6. The AWS Lambda implements Business Logic. When it is invoked, it processes the request and according to its purpose, it can create, retrieve, update, delete objects on a database, and make some computations over the data. In our example, the AWS Lambda interacts with Amazon DynamoDB. Finally, it is also in charge of preparing the response.
7. The response computed by the AWS Lambda is returned through the Amazon API Gateway to the Client that made the request.

Conclusion

The serverless approach can answer many of the architectural and operational questions, simplifying the life of developers as well as the operational team. In the previous chapter, we have seen that with only five AWS serverless services — and zero effort for managing and tuning the infrastructure— is possible to have an up and running Web Application. Anyway, adopting a serverless architecture is not the solution to all our problems. The decision to move to serverless should involve a careful analysis of business and technical requirements, taking into account all the pros and cons.

References

1. Mike Roberts (2018). Serverless Architectures.
2. Wisen Tanasa (2019). The traits of serverless architectures.
3. Amazon Web Services documentation