Serverless: A simple example

Serverless - Beyond the buzzword is a book about Serverless aiming to give you all the information you need to make informed business decisions. This is part of a series of articles summarising some of the topics from the book.
More information about Serverless - Beyond the buzzword can be found here: serverlessbook.co

You can also watch the video version of this here: https://youtu.be/334-J1YnPco

Simple Serverless architecture example design

This example is a registration form where a user is going to enter a few fields about themselves and upload an image.

Near the top, you can see a clear separation between the front-end or what the user sees - the User Form, and the Serverless backend - the API Service. These can be completely different technologies and even different teams working on them at the same time. The front-end could be web, mobile or desktop, for example.

The API Service in the design is a fully managed cloud service which can do a number of things. It can validate the fields that the user sends from the form to make sure all the required ones are present as well as the type of value and the length, for example. This means that no code needs to be developed by the team to achieve this. Similarly, the API Service can be paired with a firewall service or an authentication service to add security and login to the application without having to develop anything.

You can see how Serverless can be a great boost for developer productivity with significant components available out of the box as managed services.

After the API service, the data is divided into text data - the form fields, and the uploaded profile image. The image will be sent to the microservice on the right, which is an image processing microservice. You can start to see the reusability of this architecture here as an image processing feature is relatively generic and commonly needed for many applications. Microservices are not integrated into an application; they don't always need access to sensitive databases or storage services. You can give them input data, and they return a result. This independence means multiple applications can potentially use a single microservice. For example, your organisation could implement a shared environment with microservices that are available to any application that needs them, gradually reducing the development effort of future applications.

On the left, you can see the User Profile microservice. This is a great security advantage of microservices. In a monolithic application, if any function needs access to a sensitive database, then you must give access to the entire application. Even the entire server that the application is running on would be able to access that database. There's no way to separate access by function because it is a single collection of code running on a single server. With microservices, it is possible to give one microservice exclusive access to a sensitive database. That will be the only place of entry to the database where you can implement additional logging, auditing and authentication checks as-needed.

To go deeper on this topic and to read many more related topics about Serverless Architecture please buy the book Serverless - Beyond the buzzword here: serverlessbook.co

Serverless - Beyond the buzzword. The book about the strategic impact of Serverless architecture