Serverless Six Years Later: Architecture, Testing and Tradeoffs

At YOW! 2022, Erwin van der Koogh looks back on six years of serverless development, including his startup and his work on Cloudflare’s developer platform. He invites the audience to challenge his conclusions.

His personal definition of serverless emphasizes running code in response to events, usage-based billing and scaling without managing servers. He acknowledges that others may draw the boundaries differently and that real services have limits and billing details.

A typical execution receives and validates an event, may fetch additional data, makes a decision and saves or sends the result. He says the value is often in how this step connects to the rest of a system.

He calls a function a business step rather than treating it as a generic reusable function. Shared logic can still live in libraries; events, configuration and destinations define how a deployed step participates in a workflow.

An audience member asks about loose coupling. Van der Koogh clarifies that a function need not directly call every consumer: publishing to a bus can let other services subscribe independently.

For a serverless-first application, he first considers existing managed services, then serverless code, and uses a container where necessary. HTTP requests and other events naturally lead toward an event-driven design.

He describes small modules that each process a narrow event and estimates that many of his functions are roughly 50–150 lines. The small size is an observation about his codebase, not a universal design rule.

He says his acquired startup continued operating without his daily attention. This is an anecdote about a specific system and does not mean serverless applications require no monitoring or maintenance.

His preferred way to add a feature is often to subscribe a new handler to an existing event rather than modify the producer. For example, a signup event can trigger a new email workflow.

An audience member challenges the assumption that adding code cannot disrupt an ecosystem. New subscribers can still introduce shared-resource, ordering, security or downstream effects; the speaker’s reduced-blast-radius claim depends on the design.

When replacing behavior, he prefers adding and verifying the replacement before switching over. The aim is to make change incremental and reduce the risk of altering an existing path all at once.

On testing, he says he wrote unit tests for reusable logic but generally tested serverless functions through events and their integrations. His provocative “no unit tests” phrasing describes his practice, not a general testing standard.

He also describes testing in production with versions and feature flags, limiting unfinished changes to the developer or selected internal test accounts. He distinguishes this from exposing untested changes to all customers.

The startup had no staging environment; he says the team tried to make production testing safe through isolation, monitoring and observability. An audience member asks how to avoid contaminating production data, and he explains the use of disposable internal accounts.

He clarifies that developers tested locally before production. Another question identifies a real failure mode: a bug in a feature flag can expose a change to unintended customers. He says his team kept its routing rules simple but does not eliminate that risk.

Asked about peer review, he says the small startup did not require it for every change and explicitly does not recommend that choice for everyone. Team size, consequences and organizational context matter.

A participant questions whether these practices scale. Van der Koogh distinguishes his small startup from Cloudflare, where he says teams use unit tests, production testing and staging environments for larger systems.

The audience asks whether delaying safeguards can create a difficult retrofit. He says teams should respond as complexity grows and preserve reversibility, citing infrastructure templates that could have helped his startup add staging.

For safety-critical systems, he argues that controlled production rollout can detect issues that staging misses. That does not replace the validation, isolation and independent safeguards required by a particular safety-critical context.

Managed platforms move some operational responsibility to the provider, but an outage can leave the application team dependent on the provider’s recovery. Operational simplicity therefore comes with a dependency tradeoff.

He argues that the largest financial benefit may be freeing people to work on product differentiation rather than maintaining infrastructure. Lower cloud bills are possible but are not his main point.

Usage-based billing can make individual operations easier to cost and support pricing decisions. Actual spend need not grow linearly with revenue: traffic, retries, storage, egress and pricing can vary independently.

Looking ahead, he predicts closer integration of serverless and software-as-a-service platforms, with configurable business workflows exposed through APIs and webhooks. He gives Shopify as an example of a higher-level business platform.