Serverless use cases — web apps

This article describes a classic serverless scenario: the ubiquitous web application and identifies key components and integrations to ensure best practices.

Serverless use cases: web apps

This article is part of several writings about serverless. Previously wrote about what is serverless, design & technical trade offs, business benefits, market offerings comparison, service-full vs no-code, integration patterns: orchestration & choreography, and voice apps. The idea is to go through scenarios to understand when and how to get the best of serverless.

Why serverless is a good fit for web applications?

Serverless is a good fit for web apps when:

• traffic in the web app comes and goes in short bursts
• you need your app to be available and resilient with no-effort
• you want to outsource the whole maintenance except for your own code
• you want to pay only for what you use

What are the components of a web application?

Not all components are required to build a web application, depends on the case. This is a a quick summary reference of the services.

• Content Delivery Network: a geographically distributed network of proxy servers to provide high availability and performance.
• Object Storage: manages data as objects, as opposed to other architectures like file systems and block storage.
• API Gateway: acts as a reverse proxy between the client and your serverless back-end compute.
• Functions: allocates computing resources when needed.
• NoSQL Database: stores data in a non-tabular way.
• User directory and authentication: a simple user identity and data synchronization service.

Solution design

The following diagram describes a simple web application using serverless components for a dynamic web application. In case of a simple static web site, please check below. All cloud vendors offer components that deliver the same functionality (for more info check market offerings comparison).

Simple web application using serverless components

How does it work?

If we follow this simple serverless architecture diagram from the client:

1. Based on the request geographical location, the Content Delivery Network (CDN) will provide web content from the network of proxy servers.
2. If the file requested is not yet cached, the CDN service retrieves it from the origin — for example, an Object storage service where content is stored. Then, for the next local request for the same content, it’s already cached nearby and can be served immediately.
3. The API Gateway will expose REST or WebSocket APIs that are integrated with backend HTTP endpoints. So, requests will be routed by the API Gateway to the right function or service.
4. Functions are triggered as a response to inbound HTTP requests. However, they can be triggered in different ways, for instance other services such as an object into the object store, an element placed into a queue, etc.
5. Functions can access other services such as database services to insert, delete or retrieve data.

What if I need only a static web site?

You can use the Object Store to host a static website. On a static website, individual webpages include static content such as HTML, CSS, JavaScript, etc. And using a CDN you can provide high availability and low latency by being close to the user location.

Conclusion

Using serverless components, you can deploy your entire web application including static or dynamic options, user identity and authentication (if required) and storage.

References

• [1] AWS Well-Architected Framework, Serverless Applications Lens — Web Applications

Disclaimer

This is a personal article. The opinions expressed here represent my own and not those of my employer.