Serverless does not mean one large Lambda function

In a serverless architecture, the cloud provider operates the server operating systems, baseline capacity scaling, and much of the availability foundation. The application is assembled from focused compute, storage, messaging, and identity services whose pricing can follow actual consumption. On AWS, that may include Lambda, DynamoDB, S3, Cognito, API Gateway, and event services.

Operations do not disappear. Logs, alarms, permissions, backups, cost guardrails, and failure paths still need deliberate design. Done well, the responsibility moves from patching servers and reserving capacity to observing how the system behaves. Done poorly, the result is an opaque collection of services without a common structure.

Poggers Oy uses the serverless model in its own Kierto Commerce and Vainuri products, combining Lambda back ends with managed AWS services. The model fits because usage varies, the products need several ready-made cloud capabilities, and the environments must scale without a separate server team.

Start with the shape of the workload, not a guessed bill

The first question is not the number of users but the shape of the load. Ten thousand requests on one campaign day are a different problem from the same number spread evenly across a month. Lambda function billing follows requests and execution duration. A Fargate container is billed for its requested CPU, memory, and task runtime. The cost of an always-on service therefore begins before the first user request, while event-driven compute follows usage more closely.

Compute price alone does not decide the answer. Include the database, log volume, data transfer, fixed networking components, backups, monitoring, and human maintenance. A cheap function does not make the system cheap if every request emits excessive logs or the architecture depends on costly always-on supporting services.

Compare at least three scenarios: a normal month, a nearly idle month, and the expected traffic peak. Add incident investigation and deployment work. Only then are the alternatives comparable.

When is serverless a strong starting point?

Serverless is often a sound default for a new web product, API, internal tool, or automation while usage remains uncertain. A small team gets scalable compute, file storage, queues, and identity without building a round-the-clock server operations model before the first customer arrives.

  • Load varies considerably or the service has long idle periods.
  • Work starts from an HTTP request, schedule, queue, file, or another clear event.
  • Each unit of work can be bounded and its state stored in a durable database or storage service.
  • Fast delivery and low operational overhead matter more than complete control of the runtime.
  • The system must absorb a temporary traffic spike without pre-provisioned peak capacity.

When is an always-on service clearer?

A container or virtual server is often more natural when an application performs steady work around the clock and its required capacity is predictable. The same applies when a process must keep a connection open for a long time, retain a large in-memory state, use specialised system libraries, or control its own processes precisely.

One invocation of a conventional Lambda function can run for at most 15 minutes. A long business workflow can be split into events or orchestrated with a state machine, but not every task should be forced into that model. If the work genuinely is one calculation that runs for hours, or an existing application already runs well in Docker, an always-on or task-based container may be easier to understand and test.

  • Load is consistently high and steady.
  • The process runs for a long time or needs a persistent connection to a client or external system.
  • The application requires a specialised operating system, hardware acceleration, or detailed process control.
  • An existing container application would need a substantial rewrite solely to adopt serverless.
  • The team already has a sound container platform, monitoring, and capacity management.

Cold starts, databases, and repeated events

A cold start is not an automatic reason to reject serverless. Its importance depends on the allowed latency, programming language, deployment size, initialisation work, and invocation frequency. An ordinary admin-screen request and the critical path of real-time control need different answers. Provisioned Concurrency can reduce latency, but it also turns some capacity into a continuously billed resource.

A traditional SQL database needs connection management because rapidly growing function concurrency can open more connections than the database can support. The answer may be pooling, a proxy, a concurrency limit, or a data model better suited to the workload. A database should not be selected merely because it belongs to the same architecture trend.

An event-driven system must be designed for failures and retries. The same message may be processed more than once, so a payment, order, or other state change must be idempotent: a retry must not repeat the business effect. Queues, dead-letter handling, and alarms are part of the product, not a maintenance add-on for later.

A hybrid is often the most practical architecture

The whole system does not need one universal answer. A static front end can be delivered through a CDN, ordinary API requests and events can run in functions, a long background job can run in a container, and business data can remain in a managed SQL database. Draw boundaries around workload characteristics rather than the organisation chart.

A hybrid works only when it removes complexity. If a small product adopts functions, containers, Kubernetes, two databases, and three messaging services just in case, the operational burden grows without visible user value. The smallest sufficient system is usually the best first release.

A seven-question decision test

Write down the answers before selecting services. When an answer is unknown, build a small load-testable experiment around the most important uncertainty instead of locking the whole architecture to an assumption.

  • Is the load steady, spiky, seasonal, or still completely unknown?
  • How long does one unit of work run, and can it be divided safely into stages?
  • What latency is acceptable normally and after a cold start?
  • Where is durable state stored, and how many concurrent connections can it support?
  • What can and does the team want to operate two years from now?
  • How do normal use, an idle month, and a traffic peak change total cost?
  • Can a workload later move to another model without rewriting the whole product?

Validate the decision before building the system

Choose one important user journey and one heavy background task. Estimate normal and maximum concurrency, execution time, memory, data volume, and external dependencies for each. Build a cost estimate for the actual AWS Region and include supporting services. Test the least certain part under production-like load.

Document a threshold for revisiting the decision. A steadily growing baseline load, a stricter latency requirement, or a new long-running process may be an agreed reason to move one workload into a container. Good architecture does not predict the future perfectly; it makes the next change manageable.

Related work and services

Frequently asked questions

Is serverless always cheaper than a server?

No. Serverless is often economical for small or variable load because idle compute is not billed in the same way. At consistently high load, a container or committed capacity may cost less. Compare the complete system and maintenance effort, not only the compute list price.

Can AWS Lambda power a normal web application back end?

Often yes. Short HTTP requests, integrations, and event processing are natural fits. Latency, concurrency, database connections, and failures in external services need deliberate attention.

Should an existing Docker application be rewritten as serverless?

Usually not without a clear business benefit. If the application works and its operations are controlled, it can run in a managed container service while only genuinely event-driven parts are separated into functions.

Can a serverless application use a SQL database?

Yes. Connection count and concurrency still need to be designed. Depending on the workload, use pooling, RDS Proxy, concurrency limits, or a database model better aligned with serverless access patterns.

Sources and further reading