The Castle That Appears on Command: Serverless Architecture

Sometimes the finest fortress is the one that exists only when it is needed.

A Fortress Without a Permanent Gate: What Serverless Actually Changes

For most of software history, deploying an application meant giving it somewhere permanent to live. A server was provisioned, a runtime installed, and a process waited for requests whether anyone arrived or not. Virtual machines changed how servers were acquired, and containers changed how applications were packaged, but the assumption remained: something was running, and engineers were responsible for keeping it alive. Serverless challenges that assumption by asking whether the fortress needs to exist when nobody is visiting. The name is misleading because servers still exist. What disappears is not infrastructure, but much of the responsibility for operating it.

Instead of maintaining a long-running machine or container, an engineer provides executable code and defines what should cause it to run. The cloud platform supplies execution capacity, performs the work, and may remove that capacity afterward. The castle has not escaped the laws of masonry. The kingdom has simply handed much of the construction and night watch to someone else. That shift changes state, scaling, failure handling, and cost.

The useful question is not whether serverless is better than servers, containers, or virtual machines. It is what kind of work benefits from a fortress that appears only when called. Serverless removes familiar infrastructure responsibilities while introducing less visible constraints. Understanding that exchange matters more than learning provider-specific syntax.

The Wizard Behind the Walls: Shifting Infrastructure Responsibility

In the previous chapter of The Kingdom in the Clouds, cloud infrastructure became a question of responsibility. Infrastructure as a Service leaves engineers with substantial control over machines, while Platform as a Service and managed services move more work to the provider. Serverless pushes the boundary farther by moving the execution environment behind the curtain. The engineer is no longer primarily deciding which machine should remain online, but rather what work should happen and which event should trigger it.

Virtual machines exist before requests arrive and remain afterward. Containers improve portability, but their services commonly remain long-lived. Kubernetes automates scheduling, replacement, health checks, and scaling, yet engineers still describe a desired population of running workloads. The keeper of a thousand castles may be efficient, but there are still castles to keep.

Serverless asks the platform to manage whether those execution environments exist at all. An HTTP request arrives, a file lands in storage, a queue receives a message, or a scheduled time is reached. The platform provides capacity, executes code, and manages workers. What changes is not necessarily the business logic, but the contract surrounding its execution. When execution becomes temporary, anything important must survive somewhere else.

The Smallest Summoned Chamber: Functions as a Service

The most familiar form of serverless computing is Functions as a Service, or FaaS. Instead of deploying a continuously running application server, engineers deploy smaller units of executable logic associated with triggers. Imagine a royal archive that receives documents from distant provinces. A traditional system might keep a clerk in an empty records room all day in case a courier appears. In a serverless model, the room opens when the courier arrives, the work is completed, and the room disappears again. Ten couriers may cause ten rooms to appear, while a quiet afternoon may require none.

A simplified HTTP function might look like this:

export async function getOrder(request) {
    const orderId = request.params.id;

    const order = await orderRepository.findById(orderId);

    if (!order) {
        return {
            statusCode: 404,
            body: JSON.stringify({
                message: "Order not found"
            })
        };
    }

    return {
        statusCode: 200,
        body: JSON.stringify(order)
    };
}

Nothing inside the function is unusual. It receives a request, looks up data, and returns a response. The architectural difference exists around the code. The engineer does not necessarily provision a web server, maintain a process manager, or decide how many instances should remain running overnight. The platform connects an event to executable code and manages the required capacity.

That convenience does not eliminate machinery. Execution environments still have startup costs. Networks fail. Databases have connection limits. Messages may arrive more than once. Functions can time out. An experienced engineer therefore treats managed infrastructure as hidden infrastructure, not nonexistent infrastructure. Serverless reduces the mechanisms engineers operate directly, but not the mechanisms they must understand.

The Bell at the Gate: Event-Driven Architecture

Serverless becomes easier to understand when engineers stop thinking primarily about functions and begin thinking about events. A function is one possible response to something that happened. HTTP requests, file uploads, queue messages, database changes, and scheduled times can all become triggers. Serverless platforms are especially effective when work begins in response to discrete occurrences rather than requiring a process to remain active while waiting.

Serverless computing and event-driven architecture are closely related but not identical. Event-driven applications can run on virtual machines or containers, and a serverless function can simply respond synchronously to an HTTP request. The models fit well together because temporary execution naturally aligns with work that begins only when something occurs.

Suppose users upload profile images to object storage. One design could keep a service running that repeatedly checks for new files. An event-oriented design allows storage to announce that a file has arrived, invoke a function, process the image, and finish. Polling asks the castle guard to repeatedly walk to every gate and ask whether anything has changed. Events allow the gate bell to ring when something actually does.

That flexibility reduces unnecessary coupling but raises concerns about delivery guarantees, retries, ordering, and eventual processing. Those concerns grow more important once services rely on messages rather than direct conversations.

The Memory Kept in the Archives: Stateless Computing and Durable State

Temporary execution creates an obvious problem because applications still need memory. Shopping carts, workflows, sessions, and orders all depend on information that must persist beyond a single invocation. If a function may disappear after every execution, application correctness cannot depend on anything stored only inside that worker.

Serverless systems therefore encourage stateless computation. A function should behave as though each invocation may run in a fresh environment. Anything important belongs in durable storage such as a database, object store, cache, queue, or workflow service. The worker retrieves the required state, performs bounded work, records the result, and finishes.

This does not mean serverless applications have no state. It means state must be placed deliberately. Long-running applications sometimes hide state in memory, local files, or instance-specific sessions simply because the process remains alive. Those assumptions become dangerous when applications scale horizontally, or workers are replaced. Serverless exposes them earlier because the platform does not promise that a particular worker will still exist later. If losing a worker destroys important information, the information was stored in the wrong place.

A Thousand Towers at Once: Automatic Scaling and Concurrency

Traditional scaling requires engineers to estimate capacity. Serverless changes the unit of scaling by allowing execution capacity to expand in response to invocations. Ten events may produce ten concurrent executions, while a surge may produce hundreds or thousands. This is especially useful for uneven workloads such as scheduled reporting, webhooks, image processing, or systems that spend much of their time waiting.

Automatic scaling, however, does not mean unlimited scaling is healthy. Imagine a function writing to a database that supports two hundred concurrent connections. If one thousand executions begin simultaneously, the compute layer may scale successfully while the database layer beneath it fails. One part of the kingdom can summon a thousand rooms, but the treasury still has one doorway. A system is never more scalable than the least elastic dependency on its critical path.

Serverless makes that lesson unusually visible because compute may expand faster than databases, APIs, caches, and other dependencies. Engineers must think not only about whether functions can scale, but also about whether the systems behind them can withstand the resulting concurrency.

When the Castle Vanishes: Scale-to-Zero and Workload Economics

One of serverless computing’s most distinctive characteristics is the ability to scale to zero. Conventional applications usually keep some capacity running continuously. A serverless workload may consume little or no execution capacity when nothing is happening, making the model attractive for intermittent automation, low-volume APIs, prototypes, event processors, and bursty workloads.

That does not automatically make serverless inexpensive. A continuously busy workload may gain little from scale-to-zero, while a cheap-looking function may invoke several managed services each time it runs. The real economic advantage is that resource consumption can more closely track useful work when demand is irregular.

Bursty and short-lived workloads often fit that model well. Predictable heavy workloads may benefit less because resources are consumed continuously anyway. Operational labor belongs in the calculation, too, since reducing infrastructure maintenance can yield substantial value even when raw compute pricing is not the lowest option. The kingdom may save money by refusing to heat empty castles, but that does not mean every building should vanish after sunset.

The Castle Still Forming: Cold Starts and Startup Latency

A castle that appears on command still needs time to form. Serverless platforms often reuse existing execution environments, but they cannot guarantee that one will always be ready. When a fresh environment must be created, the platform may initialize a runtime, load application code, establish dependencies, and prepare the function before useful work begins. The resulting delay is commonly called a cold start. It is a reminder that serverless infrastructure has not vanished. It has moved behind the provider boundary.

Cold-start behavior varies with runtime, package size, framework overhead, network configuration, and initialization work. For asynchronous workloads, the delay may be irrelevant. If an uploaded image begins processing a fraction of a second later, most users will never notice. A user-facing API with strict latency requirements is different because the first request after inactivity may behave differently from subsequent requests.

Experienced engineers therefore ask whether cold starts matter for the workload rather than simply whether they exist. Some platforms can keep execution capacity ready, reducing startup latency at the cost of continuously prepared resources. That tradeoff may be worthwhile, but it changes the economics of scaling to zero. Every abstraction eventually reveals the physical system beneath it when performance matters.

The Crowded Courtyard: Concurrency, Queues, and Backpressure

Automatic scaling can expose the limits of everything it touches. A function rarely works alone. It calls databases, APIs, queues, caches, payment providers, and other dependencies that may scale more slowly than the compute layer.

Suppose an order-processing function normally receives a modest stream of work. Then a promotion begins, and ten thousand orders arrive within minutes. The platform may create hundreds or thousands of concurrent executions while the database exhausts its connection pool or an external payment service begins throttling requests. The function platform scaled successfully. The system did not.

Queues and backpressure help control that mismatch. Instead of translating every incoming event into immediate downstream work, a queue can absorb a burst while consumers process messages at a sustainable rate. Concurrency limits, rate controls, and batch sizes can further protect dependencies. A city gate designed for fifty wagons per minute does not become wider because five hundred gatekeepers appear.

Consider an online store that creates invoices after successful purchases. The customer does not need the invoice before checkout finishes, so the ordering service can place that work on a queue:

export async function processInvoice(event) {
    for (const message of event.records) {
        const order = JSON.parse(message.body);

        const existingInvoice =
            await invoiceRepository.findByOrderId(order.id);

        if (existingInvoice) {
            continue;
        }

        const invoice = await invoiceService.generate(order);

        await invoiceRepository.save({
            orderId: order.id,
            invoiceUrl: invoice.url
        });
    }
}

The important decision is the check for an existing invoice. Distributed systems commonly provide at-least-once delivery, meaning a message may be retried after an unspecified failure. If the function blindly repeats its work, retries can create duplicate effects.

The ability to repeat an operation without causing unintended additional results is called idempotency. Some operations are naturally idempotent, while others require deduplication keys, unique constraints, or transactional checks. Charging a customer twice because the same message appeared twice is not graceful retry behavior. It is a production incident wearing a queue as a disguise. An exception is something the code encounters. A failure mode is something the system must survive.

Retries also need limits. Permanently invalid events should not circulate forever. Dead-letter queues or similar failure destinations allow problematic messages to be isolated while the rest of the system continues.

The Hourglass on the Table: Execution Timeouts and Bounded Work

Serverless functions are designed for bounded execution. Exact limits vary by platform, but the model favors work that has a clear beginning and end: validate a request, transform a file, process a message, send a notification, generate a thumbnail, or respond to a webhook. These tasks fit temporary workers naturally.

Other workloads fit less comfortably. Long-running computations, persistent connections, multiplayer sessions, or processes that depend on durable in-memory coordination may be fighting the execution model rather than benefiting from it. Serverless components can still support those systems, but the core workload may belong in containers, virtual machines, or another long-lived environment.

Breaking a large task into several functions can work when the workflow has natural stages. A video pipeline might validate a file, extract metadata, transcode formats, and create thumbnails separately. Each stage can retry independently, but every new boundary adds state, tracing, coordination, and another failure point. Serverless rewards meaningful decomposition, not fragmentation. The finest fortress is not the one with the greatest number of rooms. It is the one whose rooms exist for reasons the inhabitants can explain.

The Royal Ledger: Usage-Based Pricing

Serverless economics become more granular once an application moves beyond scale-to-zero. Traditional infrastructure often presents cost as a visible barrier, while serverless pricing tends to be driven by activity. Invocations, execution duration, memory allocation, network traffic, storage operations, database access, queues, and logging may all contribute to the bill.

That changes the optimization problem. A traditional service may waste money because a server sits idle, while a serverless system may waste money because inefficient work runs millions of times. One extra database read per invocation seems trivial until the function executes ten million times.

Serverless therefore encourages engineers to think in terms of cost per useful unit of work. How much does processing one image cost? How many managed-service operations occur because one order entered the system? A continuously busy service may still be cheaper on long-running infrastructure because its capacity is heavily utilized. The decision is mathematical, not ideological.

The Kingdom Beyond the Function: Managed Services and Provider Coupling

Functions receive most of the attention in serverless discussions, but many serverless systems consist largely of managed services surrounding them. Object storage holds files. Databases preserve state. Queues buffer work. Event buses distribute notifications. API gateways expose endpoints. Identity, workflow, and observability services handle other responsibilities.

This matters because serverless architecture is less about functions than about reducing responsibility for the continuous operation of infrastructure. A function may contain only a few dozen lines of code, while most of the architecture lies in the relationships among managed services. The team operates less machinery directly, but it must understand more service contracts, including retries, quotas, permissions, consistency guarantees, concurrency, and billing.

That convenience creates provider coupling. Application code may use a portable language, while triggers, identity policies, workflow definitions, database APIs, and monitoring systems become tied to a single cloud ecosystem. Avoiding every provider-specific feature can defeat the value of managed services, while embracing every proprietary capability without considering exit cost can make future change expensive.

The useful question is not whether lock-in exists. It usually does in some form. The better question is whether the value gained from a dependency justifies the cost of changing it later. A kingdom that hires a wizard to summon its towers should understand the contract before allowing the wizard to design every road and gate around the spell.

The Vanishing Crime Scene: Observability in Temporary Execution

Temporary execution changes debugging. In a traditional application, an engineer may inspect a running server or attach diagnostic tools to a long-lived process. A serverless function that failed thirty minutes ago may no longer exist.

Logs, metrics, traces, correlation identifiers, and structured events therefore become essential. Engineers need sufficient telemetry to reconstruct what happened without relying on the original worker being present. This becomes especially important when a business operation spans multiple managed services.

An API request may invoke a function that stores data and publishes an event. Another function processes that event and places a message on a queue. A third consumes the message and calls an external service. Each component may be simple, while the overall failure requires reconstructing the path through several temporary workers.

Serverless architecture should therefore not be confused with simpler architecture. It can simplify infrastructure operations while increasing the importance of distributed-system observability. A disappearing castle still needs a history. If engineers cannot reconstruct why it appeared, what happened inside it, and why it vanished, the abstraction has hidden too much.

The Work Worth Summoning: Choosing Serverless Workloads

The strongest serverless designs begin with workload shape rather than technology preference. A team should examine what causes the work to begin, how long it lasts, whether state can live outside the worker, and whether demand changes enough for elastic execution to provide real value. Event processing, scheduled automation, webhooks, file transformations, background jobs, low-volume APIs, and bursty workloads often fit naturally because the computation is intermittent and bounded. In those cases, keeping permanent infrastructure alive can mean paying for waiting.

Predictable workloads can point in the opposite direction. A service receiving steady traffic throughout the day may gain little from scaling to zero because zero rarely arrives. Long-running containers or virtual machines may provide more predictable latency and, depending on utilization and pricing, lower cost. The decision depends less on whether serverless is modern and more on whether the workload naturally behaves in a temporary-execution manner. Choose serverless because the workload behaves like serverless work, not because the architecture diagram looks more sophisticated afterward.

The Fortress That Should Stay Standing: When Serverless Is the Wrong Fit

Some systems naturally resist temporary execution. Applications that maintain persistent connections, long-lived streaming processes, or durable in-memory coordination often benefit from workers that remain available. Serverless components can still support those systems, but forcing the core process into short-lived execution may introduce more complexity than it removes.

Highly latency-sensitive applications deserve similar caution. If startup variation consistently matters, engineers may prefer infrastructure where runtime availability is tightly controlled. Provisioned serverless capacity can reduce startup delays, but once substantial capacity must remain continuously ready, the team should reconsider whether the original operational and economic advantages still justify the model.

Long-running computation can also be a poor fit. A batch job lasting several hours may belong in a containerized job system designed for extended execution. Breaking that work into many functions can help when the stages are genuinely independent, but it can also transform an understandable process into a distributed workflow that requires more state coordination, tracing, and failure recovery.

Mature cloud architectures rarely depend on a single execution model. A production system may use image-processing functions, containers for an active API, object storage for files, a managed database for durable state, and queues for asynchronous work. No single technology needs to conquer the entire kingdom. Architecture improves when each tool is assigned according to the problem it solves.

Too Many Tiny Keeps: Function Boundaries and Architectural Design

Serverless can encourage the assumption that small functions automatically produce modular software. They do not. A poorly designed monolith can be divided into dozens of poorly designed functions and emerge with the same conceptual problems plus network latency, distributed failure modes, deployment complexity, and harder debugging. Small deployment units are useful only when they correspond to meaningful responsibilities.

A function that responds to a new image and creates thumbnails has a coherent purpose. A function that processes an invoice may have another. A function that exists only because every source file received its own deployment unit is not necessarily architecture at all. The boundary should represent responsibility, not enthusiasm for decomposition.

The lessons from containers and Kubernetes still apply. Packaging does not create good architecture. Orchestration does not create good architecture. Serverless execution does not create good architecture either. These technologies expose decisions that engineers still have to make intentionally.

A well-designed serverless system may contain only a handful of functions, while another may legitimately contain hundreds. Function count tells us little about architectural quality. A better test is whether each boundary makes the system easier to reason about, change, recover, and operate.

The Crown Still Has Weight: Responsibility and Operations

The recurring lesson in The Kingdom in the Clouds is that cloud computing does not eliminate the need for infrastructure. It redistributes responsibility. Serverless pushes that redistribution farther by moving operating-system maintenance, host replacement, much of runtime provisioning, and significant portions of scaling behind the provider boundary. In return, engineers accept constraints around execution lifetime, quotas, event delivery, retries, observability, managed-service behavior, and cost.

That exchange can be valuable. Small teams can build event-driven systems without maintaining server fleets, and intermittent processes can run without reserving permanent compute resources. Infrastructure expertise can be concentrated where it provides real advantage, rather than spent keeping idle workers alive.

The remaining responsibility is still substantial. Someone must decide where state belongs, protect downstream systems from uncontrolled concurrency, define retry behavior and permissions, and understand what happens when a provider abstraction behaves differently from expected. Traditional operations often focus on machines, while serverless operations focus on workflows: invocation counts, execution time, failure rates, retries, queue age, concurrency, timeouts, and downstream saturation. The health of a serverless application exists in the relationships among events, functions, queues, databases, gateways, and external services. The castle may appear through magic, but the architect remains responsible for deciding where it appears and what happens inside.

The Architect’s Questions: A Practical Serverless Decision Framework

When considering serverless, begin with what drives the work. If the answer is a discrete event, serverless deserves serious consideration. Then ask how long the work lasts, whether important state can live somewhere durable, and whether irregular demand makes elastic scaling useful.

Then look beyond the function. What systems will it call? What happens if one thousand copies execute at once? Can an event arrive twice? What happens after a timeout? Where does failed work go? How will an engineer reconstruct a request after every worker involved has disappeared?

These questions expose the architecture hidden behind the apparent simplicity of deploying a function. The function itself is usually the easy part. The difficult part is understanding the system created around it. One is a platform skill. The other is engineering judgment.

The Castle That Appears on Command: The Serverless Tradeoff

Serverless architecture offers one of cloud computing’s most unusual bargains. Engineers can deploy computation without maintaining a continuously visible execution fleet. The platform can provide capacity when events arrive, expand it when demand rises, and allow much of it to disappear when the work ends. For the right workload, that model can reduce idle infrastructure, absorb unpredictable traffic, and encourage systems whose computation is replaceable and whose state is deliberately durable.

Every advantage has a corresponding responsibility. Temporary workers require intentional state management. Elastic compute requires protection for dependencies that cannot scale as quickly. Event delivery requires idempotency and deliberate retry behavior. Managed infrastructure requires understanding provider contracts. Temporary execution requires strong observability.

Serverless therefore does not eliminate architecture. It makes certain decisions harder to postpone because hidden state, unsafe retries, uncontrolled concurrency, and weak observability reveal themselves quickly when workers are temporary. The apparent simplicity of a function is valuable only when the system surrounding that function has been designed with equal care.

The finest fortress is sometimes the one that exists only when it is needed. The wisdom lies in recognizing when that is true, rather than demanding that every fortress disappear.

This week’s theme in The Kingdom in the Clouds is Building Above the Clouds. Containers taught us how to package the castle. Kubernetes taught us how to coordinate many castles. Cloud infrastructure taught us that owning the stones is not the same as controlling the kingdom. Serverless architecture now shows that even the castle’s permanent existence can become optional.

On Friday, the journey continues with Roads Through the Sky: Connecting Cloud-Native Services. Once computation can appear anywhere in the kingdom, the next problem becomes unavoidable. Those distant services still need reliable ways to find one another, exchange information, and survive the roads between them.