What is serverless computing? An explanation of its mechanisms, benefits, and suitable systems from an AWS perspective.

Serverless computing is a cloud usage model that allows developers to focus on running applications without having to worry about building or operating servers. With the widespread adoption of cloud services such as Amazon Web Services (AWS), it has become a standard choice in modern infrastructure design.

However, there are many practical questions, such as "Will the server completely disappear?" and "How is this different from traditional cloud (virtual servers)?", and in many cases, the criteria for deciding whether to implement it are unclear.

This article provides a thorough explanation of serverless architecture, including its mechanisms, advantages, and disadvantages, comparing them to traditional server configurations. Using major AWS services as examples, we've organized everything from specific design patterns to adoption criteria from a practical, real-world perspective.

What is serverless?

Serverless computing is a cloud model that allows users to run applications without being aware of the existence of servers. By having cloud providers handle physical and virtual infrastructure operations such as OS patching and capacity adjustment, developers can concentrate on implementing business logic.

"Abstraction" of server management

The term "serverless" does not mean that servers physically disappear. In reality, servers are running in the cloud provider's data center, but the complex management process is "abstracted" so that it is not visible to the user.

In traditional configurations, users were responsible for everything from OS selection and middleware configuration to load-based scaling design. In contrast, serverless computing provides these services as managed services. Taking AWS Lambda as an example, developers only need to "upload their code" and don't need to worry about the number of servers running in the background or their maintenance.

Changes in the point of responsibility

The biggest advantage of adopting serverless computing is that the scope of responsibility for operation and maintenance (the point of responsibility division) shifts significantly to the cloud provider.

• Responsibilities of Cloud Providers
  • Manages physical hardware, virtualization layers, operating systems, and runtimes, and performs autoscaling.
• User Responsibility
  • Application code, data design, IAM (permission management), monitoring configuration.

While the burden of infrastructure management will be dramatically reduced, this does not mean that design considerations will no longer be necessary. In practice, correctly understanding that "server management will be reduced, but the responsibility for code efficiency and security design still rests with the user" is key to preventing discrepancies between expectations and reality after implementation.

Serverless architecture

Unlike the traditional "always-on, on-demand" model, serverless computing operates on a dynamic mechanism of "running only when and as needed." This explanation will cover the three pillars that support this mechanism.

Event-driven architecture

The foundation for serverless computing is "event-driven" architecture. It automatically executes processes triggered by "changes" that occur within the system.

• Specific example of a trigger: API request by a user (Amazon API Gateway)
  • Saving files to storage (Amazon S3)
  • Database updates or scheduling

This mechanism allows developers to run the system simply by defining "what happens (trigger) and what to do (action)."

Execution of Functions via FaaS

This "action" is handled by FaaS (Function as a Service). In this model, exemplified by AWS Lambda, applications are managed not as a huge monolith, but in units of "small functions" that have specific functionalities.

If developers register their functions (program code), the cloud provider will allocate resources such as containers only at the moment of execution and immediately release them once processing is complete. This frees developers from the "preparation of the execution environment," such as booting the OS or preparing the runtime.

Linking automatic scaling with costs

The true value of serverless computing lies in its direct connection to operational flexibility and cost savings.

• Auto-scaling
  • If 10 requests come in, the cloud provider instantly prepares 10 execution environments in parallel; if 1,000 requests come in, it prepares 1,000 environments. Users do not need to worry about increasing server capacity.
• Pay-per-use billing in millisecond increments.
  • You are only charged for the time the code is running. Since there are no requests during idle time, you are not charged, eliminating unnecessary costs.

Differences from conventional server configurations

The easiest way to understand the characteristics of serverless architecture is to compare it with other execution environments. The biggest difference lies in the "infrastructure management layer."

Comparison with On-Premise vs. IaaS: Freedom from Management

With on-premises or IaaS (such as Amazon EC2), users are responsible for managing the physical or virtual "box."

• On premises
  • We own servers as physical assets. From procurement and installation to hardware failure support, every layer is under our control.
• IaaS (Virtual Server)
  • While you'll be freed from hardware management, applying OS patches, optimizing middleware, and configuring security settings remain the user's responsibility.

In contrast, serverless architecture entrusts the maintenance and management of the "execution environment itself" entirely to the cloud provider.

Comparison with containers: Depth of abstraction

Container environments like Amazon ECS/EKS package applications and enhance portability, but the concepts of "resource allocation (how much CPU/memory to use)" and "cluster operation" still remain.

Serverless architecture even abstracts away the concept of containers. The user's concern narrows further from "container specifications" to "function execution."

However, containers excel in systems with long processing times and complex dependencies, so the general rule of thumb is to use serverless if you want to minimize operational burden, and containers if you prioritize flexible customization and portability.

Comparison Summary

The differences in the scope of responsibility for each model can be summarized as follows:

Advantages of Serverless

Implementing serverless computing is more than just "outsourcing infrastructure management"; it brings about dramatic changes in business speed and cost structure. The main benefits are as follows:

Dramatic reduction in operational load

The biggest advantage is being freed from the so-called "server maintenance." Applying OS security patches, runtime updates, and planning for hardware replacements due to hardware aging—all of these tasks, which were previously essential in traditional environments, become the responsibility of the cloud provider.

Engineers can redirect resources previously spent on "system maintenance" directly to "value creation," such as developing new features or improving the user experience.

Nearly unlimited scalability

Serverless computing renders the concept of pre-planned capacity a thing of the past. From a few requests to tens of thousands of spikes, the cloud automatically adjusts resources in milliseconds. Users don't need to set auto-scaling thresholds or worry about the number of servers based on load test results.

This solution simultaneously addresses both the risk of the site crashing due to excessive traffic and the inefficiency of maintaining an excessive number of backup servers.

Cost optimization through "true pay-as-you-go" pricing.

Serverless billing is a system where you pay for the "work (execution)" performed, rather than the "existence" of the server.

• Elimination of idle costs
  • No charges will be incurred during waiting times, such as late at night when processing is not in progress.
• Ideal for a small-scale start
  • During periods of low usage, it can be operated at an extremely low cost, and as the business grows, costs increase proportionally, thus minimizing investment risk.

Disadvantages of Serverless

Serverless computing is not a panacea. Its unique execution model presents new challenges that were not considered in traditional server configurations.

Response delay due to cold start

The biggest technical limitation of serverless computing is "cold start." As a consequence of the mechanism that releases resources when there are no requests, there is a delay (latency) when running the system after a long period of inactivity, waiting for the environment to start up.

• 影響
  • A delay of several hundred milliseconds to several seconds occurs.
• (I.e.
  • This issue can be mitigated by utilizing "Provisioned Concurrency," which ensures a constant number of execution environments, and by choosing lightweight runtimes (such as Go or Python).

In web applications where real-time performance is crucial, and in situations where initial delays that could lead to user abandonment are unacceptable, designing with this characteristic in mind is essential.

Vendor lock-in risk

Serverless computing truly shines when it's tightly integrated with the proprietary managed services provided by cloud providers. A configuration centered around AWS Lambda, combined with Amazon DynamoDB and EventBridge, maximizes development efficiency, but makes migration to other clouds (such as Google Cloud or Azure) difficult.

Because it relies on unique API specifications and connection rules between services, systems that prioritize "portability that allows switching to another company at any time" require careful consideration, compared to introducing an abstraction layer or exploring container technology.

Fragmentation of monitoring and debugging

Because the system becomes a "collection of small functions," troubleshooting becomes more difficult. The traditional "tracking logs within a single server" approach is no longer effective. Requests flow across multiple services such as API Gateway, AWS Lambda, and databases, requiring distributed tracing techniques to pinpoint the source of the failure.

Ensuring "observability," which involves visualizing the entire request process using tools such as AWS X-Ray, is a prerequisite for stable operation.

Systems that are suitable or unsuitable for serverless computing

The success or failure of serverless computing depends on its compatibility with the workload (processing characteristics). Instead of simply applying serverless to everything, use the following criteria to assess its suitability.

[Suitable for] Irregular and sudden tasks

This is a case where the inherent strength of serverless architecture is utilized, as resources are only activated when an event occurs.

• API backend
  • Web and mobile apps with volatile traffic fluctuations.
• Event-driven data processing
  • Asynchronous processing such as "resizing images when they are saved to Amazon S3" and "sending notifications when database updates are detected."
• Intermittent batch processing
  • Regularly scheduled jobs that run several times a day or take only a few minutes to complete.
  • Since you are only charged when the application is running, you can eliminate waiting costs.

【Not suitable for】High-load, long-duration, and low-latency processing

This is a case where the limitations of serverless architecture (execution limits and cold starts) become a bottleneck.

• High load and long-duration processing at all times
  • Processes that continuously occupy the CPU for several tens of minutes to several hours (such as machine learning training and video encoding).
  • This can easily exceed the AWS Lambda execution time limit (maximum 15 minutes) and also result in higher costs.
• Extreme real-time performance
  • Financial transactions and real-time games that constantly require responses in milliseconds.
  • Systems where a few seconds of delay due to a cold start is unacceptable.
• Large Monolith
  • Existing applications with large and complex dependencies
  • The cost of breaking down serverless architecture into "function units" becomes enormous, potentially leading to a breakdown in management.

Typical AWS serverless services

Serverless architectures are built not on a single service, but on a combination of multiple managed services with different roles. Here, we organize the key services that form the core of the design by "role."

Computing: AWS Lambda

This is the execution environment that acts as the command center for serverless systems.

Without needing to be aware of the server's presence, programs are executed triggered by specific events (such as API requests or file creation). AWS automatically controls everything from scaling to accommodate increases and decreases in requests to destroying the execution environment, allowing users to focus solely on writing the "business logic (code)."

Frontend API Management: Amazon API Gateway

This service acts as the "gateway" to the system.

It accepts external HTTP requests and securely forwards them to backend services such as AWS Lambda. It provides a full range of managed functions necessary for API operation, including authentication, authorization, and request flow limiting (throttling).

Datastore: Amazon DynamoDB / Amazon S3

This is a storage location that does not require server management to maintain "state (data)".

• Amazon DynamoDB
  • Ultra-fast, highly scalable NoSQL database
  • Because it can automatically adjust throughput according to the amount of access, it is an excellent match for AWS Lambda.
• Amazon S3
  • Unlimited object storage capacity. It not only stores data but also acts as a trigger, notifying AWS Lambda when a file is placed.

Integration and control: Amazon EventBridge / AWS Step Functions

It's the glue that connects disparate services into a single, cohesive system.

• Amazon EventBridge
  • We connect different services using events (notifications).
  • For example, it's possible to integrate processes by simultaneously sending an event such as "an order has been placed on the e-commerce site" to multiple processes.
• AWS Step Functions
  • It visually manages complex workflows (procedures) such as "If process A succeeds, proceed to process B; if it fails, retry."

Basic Patterns of Serverless Design

Designing serverless architecture is like putting together a puzzle of managed services. Here are two classic patterns that are frequently used in practice.

Pattern 1: API backend for web/mobile apps

This is the most versatile configuration and is well-suited for "synchronous processing," which involves returning an immediate response to a request.

1. Reception: API Gateway catches the user's request.
2. Execution: AWS Lambda is invoked to process logic such as authentication and data processing.
3. Save: Write data to Amazon DynamoDB and return the results to the user.

This configuration provides stable performance while minimizing operational effort, making it ideal for new services with unpredictable traffic or reservation sites that experience high traffic during specific time periods.

Pattern 2: Asynchronous Data Processing Pipeline

This pattern involves triggering heavy processing in the background based on events such as "file uploads." It is suitable for "asynchronous processing" that does not keep users waiting.

• trigger
  • Image uploads to S3 and system notifications via EventBridge
• Job execution
  • AWS Lambda performs image resizing and log analysis.
• Flow Control
  • If multiple steps are required, Step Functions will control the order (e.g., "execute A, then B") and retry in case of errors.

There is no need to keep a batch server running 24 hours a day, and large-scale data processing can be achieved with costs only incurred for the amount of processing actually performed.

Should you implement serverless computing? Key points to consider.

Serverless computing is a powerful tool, but blind adoption can be counterproductive. Before deciding to implement it, evaluate your company's situation from the following two perspectives.

1. Do the team members have sufficient design and operational skills?

Serverless eliminates the need for "server management," but instead requires "advanced distributed design."

• A paradigm shift is needed.
  • The traditional approach of "logging into the server and investigating" is no longer viable. Skills in function granularity design, fine-grained permission management using IAM, and distributed tracing using Amazon CloudWatch, etc., are essential.
• Consideration of learning costs
  • If the team is accustomed to traditional server operations, development speed may temporarily slow down. In such cases, the standard practice is to gradually introduce the new system, starting with peripheral batch processing rather than the main functionality, and accumulate knowledge along the way.

2. Workload characteristics and the "break-even point" of costs

Serverless pay-as-you-go pricing means "0 yen" when there is no access, but the cost can skyrocket in proportion to the number of requests.

• Cases where serverless becomes cheaper
  • This is ideal for systems in the early stages of development or those with intermittent access (only a few hours a day, or irregular spikes). Because it eliminates wasted standby resources, it is significantly less expensive than IaaS.
• Cases where server containers become cheaper
  • For systems that experience a consistently high level of requests 24/7, 365 days a year, it's more cost-effective to "reserve" resources on Amazon EC2 or AWS Fargate at a fixed rate rather than accumulating the cost per execution of AWS Lambda functions.

Summary

Serverless computing is a powerful model that frees you from server management and allows you to focus on development, but it's not a panacea. While it offers benefits like automatic scaling and pay-as-you-go pricing, it also has limitations such as inherent latency and design complexity. When implementing it, it's essential to calmly assess the characteristics of your workload and make the right decisions about which AWS services to use in the right places.