There are so many cloud solutions that describing them all would increase this article’s volume so much that nobody would want to read it. So in order to make it more consistent, I decided to focus on two main cloud providers: Amazon Web Services and Google Cloud Platform.

These two are among the most popular cloud providers and they also happen to be important technologies for The Software House. AWS in particular is a key technology with TSH’s position as AWS Advanced Partner. If you are interested in learning more about this, read about how we help our clients use the AWS cloud efficiently in weeks.

Serverless technology & AWS

AWS is great for serverless – a cloud-native development model that makes it possible to build and run apps without having to deal with servers.

In fact, a lot of AWS services are purpose-built to support serverless application:

• AWS Lambda is a serverless computing platform, which allows you to run pretty much any type of application or backend – no server management required.
• AWS Fargate is another computing platofrm, which is great for dockerized apps. It is compatible with Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS
• AWS SQS works in tandem with Lambda in order to process asynchronous tasks – this is perfect for distributed serverless architectures.
• AWS Step Functions lets you organize multiple services into serverless workflows – great for more complex serverless architectures.

Regardless of whether you use AWS or not, you should take a look at the use cases below. They will allow you to better understand what serverless is and how you can use it in practical ways to enrich your systems.

Serverless and static page hosting

Yes, you can have a website without running a server by yourself! How cool is that? 

Modern websites are mostly built using static assets -– these are HTML, CSS, and JavaScript files. No code run on a server-side during page rendering makes the site more responsive, faster, and even cheaper to maintain. Considering that trend, cloud solutions are an attractive option for hosting a static website. 

Both cloud providers allow you to host a static website with their data storage service:

• Amazon Web Services – Simple Storage Service (S3), 
• Google Cloud Platform – Cloud Storage.

Think about the storage service as a disc in your personal computer.

Amazon’s S3 provides many features and configuration options. All you need to do in AWS is create a bucket and configure it with a few clicks. After that, you can put your website files into that bucket. Remember that these can be only static assets. If you need to use backend API, you can also rely on serverless technologies – I’ll explain that later. 

Useful resource alert! 

AWS has created a really thorough step-by-step tutorial on how to configure a static website on Amazon S3. Similarly, the Cloud Storage service has similar content on hosting a static website here. I highly recommend them.

If you are interested in such a website, you should definitely check out our SRR vs SSG in Next.js overview, which also goes over tools for static site generation including Gatsby.

Serverless functions

Serverless functions are single-purpose functions written by developers, maintained, and executed on a cloud-provider infrastructure. Using serverless functions can reduce costs and improve the efficiency of your solution. Here are a few short case studies proving my case.

Processing and manipulating images

In one of The Software House’s projects, we needed to create thumbnails and add watermarks to every picture in the system. The team resolved that by using serverless components provided by AWS. Files were stored in S3. The solution looked more or less like that:

1. The user uploads an image via an application to S3.
2. S3 triggers a lambda function whenever a new object is created in a specified bucket.
3. Lambda function operates on the uploaded image, creates a thumbnail, adds a watermark, and uploads images to the S3 bucket.

Pretty simple, right? You could also transform images to another format, resize them, upload to another FTP or anything that comes to your mind. 

Triggering actions based on document changes

Serverless functions are handy when you need to do something when something else happens.  Sounds super “scientific”, I know, but the aforementioned case was a very simple example – after uploading a file the serverless function is triggered. The end, applause. 

However, there are more advanced use cases of serverless functions. 

In another software project, one team used Firestore as a database for a few services. It’s a cloud-hosted, NoSQL database by Google. There was a need to take action in one service when another happened in a different service. Google Cloud Functions came to the rescue because it allowed us to integrate your serverless functions with other services, including Firestore.

The solution provided by the developers worked like this:

1. The document in the Firestore database is changed due to action in the first service.
2. Firestore triggers an event that Google Cloud Function subscribes.
3. Google Cloud Function updates the user roles in another service. 

This is only a single serverless use case for Firestore and Google Cloud Function subscriptions, but bear in mind that the possibilities are huge in a variety of ways. Not to look far – we also used Google Cloud Functions to change a user’s online status or update unread messages on chat.

Serverless and backend API

After creating a serverless website, it’s usually time to add some backend. There are a few ways of doing it. One way is to use previously mentioned serverless functions and API Gateway. Cloud providers supply powerful consoles to create RESTful API with just a few clicks. Here are some real-life use cases.

CRUD

If you want to create a basic application, there is no need to provision a dedicated server or worry about auto-scaling. A cloud provider will do it for you. Hence why serverless functions are a great solution for CRUD backend API. 

Imagine you are creating a fully serverless shopping list app. You already have your frontend as a static website on the Amazon S3 bucket. Now you need an API for it. 

For AWS you can use Amazon API Gateway and Lambda functions. You will need the database to store data. I recommend DynamoDB –  a fully managed and serverless NoSQL solution. In the picture below, you can find an example request route.

After triggering a request, API Gateway routes it to a serverless function. Lambda makes necessary operations using the database and returns the result.  

It’s worth mentioning, you don’t need to configure an application’s architecture with the console by yourself. There is a dedicated solution that helps to deploy serverless applications – Serverless Framework.

Triggering asynchronous jobs

Sometimes you need to execute a task that lasts longer than a standard API request. In this case, asynchronous processing with serverless functions is a great choice. 

Last month we organized an internal hackathon. One of the projects was to automate our bootcamp launch for new developers. You know how it is – new people come to work with us and we need to onboard them quickly but qualitatively. Every bootcamp starts with creating a Slack channel, Jira board, Bitbucket repository, etc. It’s a great case for practicing automatization. And so we did it using asynchronous jobs. Communicating with external services for data exchange is a great case for serverless functions. 

More or less it goes like this:

1. The team leader starts a process via the Slack command. Slack makes a request to the API.
2. API Gateway routes request to first Lambda function.
3. Lambda function accepts the request and passes the request load to the second Lambda.
4. The first Lambda is returning a response with the message “Task accepted to process”. 
5. The second Lambda is making requests asynchronously. It creates a Slack channel, Bitbucket repository, Jira project, etc. 

Serverless functions are great for such cases, however, remember serverless functions cannot run code forever. Lambda functions have a maximum time of 15 minutes execution, while Google Cloud Functions can last a maximum of 9 minutes. For longer tasks, use an alternative serverless approach – a serverless computing engine for containers. For Amazon, it’s AWS Fargate, for Google Cloud Platform – Cloud Run. Both provide a similar range of features and allow you to deploy your containerized applications on a fully managed serverless platform. 

If you’re not crazy about serverless computing engines for containers, the other option is to divide some larger processes into smaller pieces and combine them in one workflow. But no spoilers, we’ll move on to that later.

One interesting alternative to API Gateway is Backend For Frontend – a pattern in which each individual frontend has its own dedicated API that communicates with external APIs. We used this pattern in a project for Qiwa, a commerce platform for businesses in Saudi Arabia. It also involved Node.js and React.

Serverless and scheduled tasks 

Serverless computing can be useful for planned tasks execution. There are cloud-based solutions that execute serverless functions according to a given schedule. In AWS it’s done via CloudWatch Events. Google Cloud Platform uses Cloud Scheduler. 

Executing serverless functions works as typical CRON job schedulers and can be used to:

• create daily reports,
• make automated backups,
• trigger business logic (e.g. deactivating subscriptions), 
• send emails and notifications.

Serverless and notifications

Notifications are an important serverless use case, especially in mobile applications. It’s another job for serverless functions. These notifications can be sent in real-time or be scheduled. In Google Cloud Platform you can use the Firebase Cloud Messaging mechanism together with Cloud Functions. Amazon Web Services provides the SNS – Simple Notification Service. 

Check out this graph for simple mobile notifications:

1. After getting a new like in a social media app, the information is saved in a database. 
2. Database triggers an event that is subscribed by a serverless function. 
3. The serverless function uses a notification service.
4. The notification service sends notifications to the end-user.

In the AWS environment, it looks practically the same. Just replace Cloud Function with AWS Lambda and FCM with SNS:

Serverless and workflows

Sometimes you need to break down large business processes into smaller parts. If tasks must be executed one by one, you can orchestrate the whole process. And guess what, there are cloud services doing just that. In AWS it’s the aformentioned AWS Step Functions. Google Cloud Platform introduced a similar mechanism at the beginning of 2021, called Workflows. 

You can use different services while executing workflows. For example, in the AWS solution, you can use DynamoDB in an on-demand mode for keeping transaction data between the step functions.

Serverless use cases – endless possibilities your next cloud- and AWS-based project

As you can see, there are so many use cases for serverless computing that you will surely find something to benefit your next project.

Possibilities of the pay-as-you-go model, zero server management, auto-scaling should only encourage you to try it. Ten years ago it was even unthinkable to create such systems without running your own server. 

Let’s wrap up the most popular use cases for serverless architecture:

• static website hosting,
• processing images,
• triggering actions based on various events,
• backend API,
• asynchronous jobs,
• scheduled tasks,
• notifications,
• advanced business workflows.

With skilled developers and serverless, you can create scalable, efficient, and easy-to-manage solutions that will keep your apps competitive!