Why we recommend serverless right now

When you hear "serverless," you might think — much like "headless CMS" meaning a CMS without a head — that it means operating without a server.

In a nutshell, it refers to "a system that requires no server management."

Applications always run on physical servers, but because those servers are hidden from the user and invisible, the approach is called "serverless."

Looking back at the history of IT infrastructure evolution, the trend has been to abstract the physical configuration of resources — such as servers, operating systems, networks, and storage — away from the user, enabling simpler, more user-friendly services and more efficient use of resources.
It all started with a single, physically independent machine. Over time, "virtual machines" emerged, allowing one server to function as if it were multiple servers. Then "containers" virtualized the application platform itself. Along with this, "cloud computing" — the service model that delivers all of this — became widely adopted.
The culmination of this evolution is "serverless": a virtualized platform where you simply register your programs or functions (Functions) and they execute automatically.

Because serverless programs are triggered by Functions, serverless-based systems are also referred to as FaaS (Function as a Service).
Well-known FaaS offerings include "AWS Lambda," launched by Amazon through Amazon Web Services (AWS) in November 2014, as well as Microsoft's Azure Functions (launched March 2016) and Google Cloud Platform's Google Cloud Functions (generally available March 2017).
Currently, AWS Lambda is the most widely used FaaS service in the world. Being the first to market, it has an extensive track record of real-world use cases and offers easy integration with other AWS services — advantages that developers around the world have come to appreciate.

So what makes serverless stand out? Let's go through some of its key benefits.

利用者がサーバーの構築や運用をする作業が不要になります。
一般的にWebサービスを提供する場合、少なくとも以下の作業が必要になります。

サーバーレスの場合、上記のうち、「サーバーにアプリケーションをデプロイする」だけを行えばよくなります。

最初にサーバーレスの設定などの必要な作業をUIから行う必要はありますが、一度設定が終わればあとの管理は基本的に不要です。

Servers are typically running 24 hours a day. With on-premises servers, that means electricity and space costs; with cloud-based servers, you're paying for usage the entire time they're running. Serverless, on the other hand, is on-demand — you only pay for what you use. Costs are incurred only during the time your application's functions are actually executing, which significantly reduces operational costs.

Even when load increases due to a spike in traffic or data volume, a mechanism called auto-scaling automatically adjusts the number of virtual servers in response. This eliminates the effort required to manually manage and operate server capacity.

That said, serverless does have its drawbacks.

Code and other assets that previously ran on traditional servers may not work as-is in a serverless environment. You'll need to review the supported programming languages and the rules governing how services run, then make adjustments accordingly.

Current serverless platforms have limitations on execution time and available resources. As a result, long-running processes or tasks like directly handling large data such as videos are not supported, and you'll need to integrate with other services to handle those cases.

While serverless removes the burden of managing infrastructure, it also means you have no control over the execution environment or performance. This can lead to instability, such as significantly slower execution speeds. There is also a known issue called a "cold start," where spinning up a new execution environment for a function that hasn't been running takes extra time. To work around this, you may need to set up periodic trigger functions that keep functions warm and in an active state.

In the past, each provider (vendor) had its own environment, restrictions, and proprietary technologies and specifications. This made it easy to become dependent on a specific vendor's technology, making migration to another vendor difficult. This issue has been addressed through ongoing standardization of technical specifications, and it's becoming less of a concern going forward.

We've given an overview of serverless along with its pros and cons.

The evolution of IT infrastructure has been driven by the goal of reducing the cost and effort of server management and operations, making it easier for teams to focus on development.

Why not consider serverless the next time you're evaluating technology options?