Let's see the following few examples of static websites:

Static hosting is the simplest and oldest kind of serverless hosting. A static website, by definition, doesn't require server-side logic. You just need to map your site URLs to HTML files. In this book, we are going to use Amazon S3 to distribute HTML, CSS, JavaScript, and image files. Using Amazon Route 53, you give AWS the rights to route all domain requests to an S3 bucket that acts like a simple and cheap filesystem.

Hosting static files on a storage system is by far the best solution. It s cheap, fast, scalable, and highly available. There is no drawback. There is no function with cold start, no debugging, no uncertainties, and changing vendors is an easy task.

If you are thinking of using WordPress to build a static site, please reconsider. You would need to spin up a server to launch a web server and a database that stores data. You start paying a few dollars per month to host a basic site and that cost greatly increases with your audience. For availability, you would add another machine and a load balance, and the billing would cost at least dozens of dollars per month. Also, as WordPress is so largely used, it s a big target for hackers and you will end up worrying about periodic security patches for WordPress and its plugins.

So, how should you build a static site with a serverless approach? Nowadays, there are dozens of tools. I personally recommend Jekyll. You can host on GitHub pages for free, use Disqus to handle blog comments, and easily find many other plugins and templates. For my personal blog, I prefer to use Amazon because of its reliability and I pay just a few cents per month. If you want, you can also add CloudFront, which is a Content Delivery Network (CDN), to reduce latency by approximating users to your site files.

Once you learn how to build a serverless website, it s extremely fast to transform an idea into a running service, removing the burden of preparing an infrastructure. Following the lean philosophy, your prototype reaches the market to validate a concept with minimum waste and maximum speed.

In this section, I ve used the qualifier small. This is because there are many studies that correlate the time to load a page with the probability for the customer to buy something. A few tens of milliseconds later may result in loss of sales. As already discussed, serverless brings reduced costs, but the cold start delay may increase the time to render a page. User-facing applications must consider whether this additional delay is worth it.

If the e-commerce sells to a small niche of customers in a single country, it s very likely that the traffic is concentrated during the day and reduces to almost nothing at late night. This use case is a perfect fit for serverless. Infrequent access is where most of the savings happens.

A real story to back this use case was described on Reddit. Betabrand, a retail clothing company, made a partnership with Valve to sell some products to promote one game. Valve created a blog post to advertise the deal and after a few minutes, the website broke because it couldn t handle the instant peak of a massive number of users. Valve pulled out the post and Betabrand had the mission to improve their infrastructure in one weekend.

Betabrand solved the problem building a small website using serverless. Valve advertised them again and they were able to handle 500,000 users in 24 hours, with peaks of 5,000 concurrent users. The post starts saying that it had an initial cost of only US$ 0.07, but it was corrected in comments to US$ 4.00 for backend and US$ 80.00 to transfer large (non-optimized) images, which is still an impressive low cost for such a high traffic (source: https://www.reddit.com/r/webdev/3oiilb).

Consider, in this section, websites that are built just for short events, like conferences, that receive a big number of visitors. They need to promote the event, display the schedule and maybe collect e-mails, comments, photos, and other kinds of data. Serverless helps handling the scale and provides a fast development.

Another related use case is for ticketing websites. Suppose that a huge, popular concert will start selling tickets at midnight. You can expect a massive number of fans trying to buy tickets at the same time.

A common example is a mobile application that sends an image to a RESTful service. This image is stored and it triggers a function that will process it to optimize and reduce its size, creating different versions for desktop, tablet, and phones.

Most chatbots are very simple and designed for specific use cases. We don't build chatbots to pass the Turing test. We don't want them to be so complex and clever as to deceive a human that it's another human talking. What we want is to provide a new user interface to make it easier to interact with a system under certain conditions.

Instead of ordering a pizza through an application using menus and options, you can type a message like "I want a small pepperoni pizza" and be quickly done with your order. If the user types "Will it rain today?", it is perfectly fine for the pizza chatbox to answer "I couldn't understand. Which kind of pizza do you want for today? We have X, Y, and Z." Those broad questions are reserved for multipurpose AI bots such as Siri, Cortana, or Alexa.

Considering this restricted scenario, a serverless backend can be pretty useful. In fact, there is a growing number of demos and real-world applications that are using serverless to build chatbots.

Internet of Things (IoT) is a trending topic and many cloud services are providing tools to easily connect a huge number of devices. Those devices usually need to communicate through a set of simple messages, and they require a backend to process them. Thinking of this use case, Amazon offers AWS IoT as a serverless service to handle the broadcast of messages and AWS Lambda for serverless processing. Configuring and managing those services is so easy that they are becoming a common choice for IoT systems.

You can set up your code to be executed on a regular, scheduled basis. Instead of running a dedicated machine to execute a code, one per hour, which creates some database reads or small file processing, you can use serverless and save costs.

Actually, that s a great way to introduce new features using serverless into a running solution since scheduled events are usually composed of simple tasks in separated modules.

There is a growing number of applications that are substituting traditional big data tools such as Hadoop and Spark for serverless counterparts. Instead of managing clusters of machines, you can create a big data pipeline, converting your input to data streams and loading chunks of data into concurrent serverless functions.

The benefit of this approach is the reduced management and ease of use. However, as you have a constant processing of data, you can expect higher costs. Also, on AWS, a Lambda function can't run for more than 5 minutes, and this limit may force changes to reduce chunks of data to smaller sizes before processing.

Avoid applications that have the following features:

Regarding multiplayer games, you can build a serverless backend that handles the communication between players with very low latency through serverless notifications. It enables turn-based and card games, but may not fit so well for first person shooters, for example, which require constant and frequent server-side processing.