Serverless is a position on the map: Wardley Maps before the architecture diagram

Raphael Moura | Aug 5, 2026 min read
Serverless is a position on the map: Wardley Maps before the architecture diagram

The meeting is always the same. Someone proposes Lambda for the new service and the room splits into two characters. The evangelist has watched functions solve everything and wants the whole system serverless by the end of the quarter. The traumatized one carries a bill nobody forgot or a cold start that showed up in an incident review, and has decided never again. Both have scars, both speak with conviction, and neither can explain why this specific component should or should not run managed. The decision goes to whoever defended their opinion with the most energy, and the architecture diagram comes afterwards, to justify what the room already decided.

I have sat on both sides of that table. I spent years at a serverless consultancy, designing the backend of a global hospitality platform and setting standards for an airline’s engineering squads, the environment where the default answer is a function. Before that, I worked on the modernization of the largest bank in Latin America building streaming pipelines with Kafka and Spark, the environment where Lambda was not even on the agenda. I watched excellent teams get it wrong in both directions, and always for the same reason: they were debating technology when the decision was about position.

That is the thesis of this article: serverless is a position decision. A component that has already evolved into commodity belongs to the managed service; a component that is still your competitive differentiator calls for your own code, portable, even when it runs on top of serverless; and the real cost of lock-in grows in exactly the wrong direction of the map, from the generic components toward your core. The instrument that makes that position visible is the Wardley Map, and I will use it the only way I respect: by drawing a real system, until what remains is a reading rule you can take into your next meeting.

The map, drawn on a real system

You learn mapping by drawing, so I will draw a system you have already seen on this blog: the ticket sale from the space-based architecture article, two million people fighting for fifty thousand tickets at ten in the morning.

The drawing starts at the top, and at the top goes the user need, never an AWS service: buy a ticket the second sales open. The value chain descends from it, each component supporting the one above. The purchase journey needs fair admission when two million arrive at once, payment, identity, a sales API. The API needs the rule that decides who gets a ticket without letting fifty thousand become fifty thousand and one. And the rule needs compute to run on, an in-memory space to absorb the peak, a buffer to drain the events, a persistence layer so the rest of the business can see what was sold. The deeper down the chain, the less visible to the user. And the invisible depths are where the Lambda fight usually happens.

The horizontal axis is what turns the drawing into an instrument. Each component is positioned by its stage of evolution: genesis while the thing is being invented, custom-built while you build it because nothing ready exists, product when you rent it from someone, commodity when it became utility and nobody competes on doing it better anymore. Position the ticket system’s components on that axis and the map tells a story the architecture diagram hides. Compute, API, queue, key-value database, identity: all of it crossed the commodity border years ago. The waiting room and the in-memory space are products, you rent Queue-it or switch on ElastiCache. And below the journey, a single component of the invisible machinery is left on the left side: the allocation rule, with the atomic decrement and the write coalescing I detailed in the other article. It sits in custom-built because it does not exist off the shelf, and it does not exist off the shelf because it is your sale surviving the peak. It is your differentiator.

The map of the ticket system: user need at the top, value chain descending, each component positioned by its stage of evolution. In the invisible machinery, a single component lives on the left side, and it is the one that differentiates the system.

The map of the ticket system: user need at the top, value chain descending, each component positioned by its stage of evolution. In the invisible machinery, a single component lives on the left side, and it is the one that differentiates the system.

Simon Wardley created the technique in 2005 by mapping his own company, Fotango, the Canon subsidiary he ran, and the map said compute was sliding toward commodity. He bet the business on it: Zimki, built in 2005 and opened to the public the following year, charged network, storage and compute per function, working serverless roughly eight years before Lambda existed. Canon switched the product off on Christmas Eve 2007, and the map stayed right anyway. That is all the theory you need here: the full book is open for when you want the whole doctrine, but the instrument exists for one thing, seeing where each component is heading before the market announces it.

The reading rule

The map becomes a decision through a rule of three zones, and that rule is what I want you to take from this text. Right side of the map, consume managed without guilt. Middle, rent behind a thin adapter. Left side, build; and if you build on top of serverless, keep the core portable.

Consuming without guilt means giving a component the attention its position deserves, none extra. Lambda, SQS, DynamoDB and Cognito enter the system the way electricity enters your building, an analogy carrying an asterisk that comes due two sections from now: you size it, configure it and move on to the problem that pays your salary. A team that spends three sprints comparing function runtimes is investing its best engineering in the quadrant where no choice produces competitive advantage. The map shows this for free: the horizontal distance between the allocation rule and everything else is the distance between what deserves debate and what deserves configuration.

The middle asks for one extra care. A product still changes owner, price and vendor, so your contract with it goes through an interface of yours, thin on purpose. The in-memory space is ElastiCache today and may be something else next year; the waiting room is Queue-it today and Cloudflare tomorrow. A thin adapter is a door the vendor can leave through, without the ambition of the heavyweight abstraction layer that tries to hide the vendor entirely.

And the left side is where the inversion the evangelist never makes lives. The allocation rule can and should run on Lambda, the space-based article is built entirely on that. Running on serverless was never the problem. The problem is letting that rule dissolve into the platform: spread across twenty functions, glued to the event format, with the business flow inside the orchestrator. Your differentiator now lives inside a company that is not yours. Portable core means the rule lives in a module of yours, testable with no AWS in the room, and the handler is an adapter that invokes it. AWS itself recommends hexagonal architecture for Lambda in its prescriptive guidance, which says a lot about who is paying attention.

I reread two articles I published here with the map in hand, and both were position decisions without the drawing. The question that closes the space-based one, does your peak concentrate on a single key?, is a question about the seam between two zones: DynamoDB is commodity and delivers what it promised, one thousand writes per second per partition, but when the peak concentrates on a single item, a slice of the problem you thought you had bought crosses the border back to your side of the map, and you inherit the space-based principle whether you want it or not. And the distributed monolith from the DDD article is what happens when a team slices the system by resource type instead of slicing by position: three hundred Lambdas where core and commodity live mixed together, nobody knowing which boundary defends what. Both texts were applying the ruler without showing the instrument. This one shows it.

The same chain with the reading rule on top: build the differentiator keeping the core portable, rent products behind a thin adapter, consume commodity without guilt. The dashed line is the seam where the hot-key question lives.

The same chain with the reading rule on top: build the differentiator keeping the core portable, rent products behind a thin adapter, consume commodity without guilt. The dashed line is the seam where the hot-key question lives.

Where the map lies: the lock-in gradient

The map has a blind spot for the naive reader, and it sits right where the discussion heats up: the right-hand column suggests an interchangeability the platform does not deliver. Real utility works like electricity, you switch providers without rewiring the building. Serverless is utility in its consumption model, pay per use, scale with demand, invisible capacity. At the interface, it is proprietary. The plug is standard; the socket comes from a single manufacturer. Wardley himself knew this back in 2008: commodity standardises to a de facto, and interchangeability is an outcome you have to engineer, with second sourcing and open implementations. In cloud, nobody engineered it. His book concedes the point in one line of the “A smorgasbord of the slightly useful” chapter: there is no interoperable, competitive market between providers; what exists, in his words, is “one continent (Amazon), some substantial islands and then a lot of small atolls most of which are sinking fast into the sea”.

The most honest example is Step Functions. The Amazon States Language has a public spec, and even so a flow written in it only truly executes inside AWS: the rare alternative runtime, ManageIQ’s Floe, implements the language, but the value of Step Functions was always in the managed integrations with the rest of the platform, and those do not come along. The same reasoning applies to data: single-table design is excellent engineering and only makes sense on DynamoDB. None of this is an accusation; a good platform integrates deep, and deep integration couples. The question that matters is a different one: where lock-in gets expensive.

Gregor Hohpe dismantled the binary version of this war a while ago: for him, lock-in is switching cost against unique utility, a continuous dial rather than an on-off switch, and accepting lock-in on a component is a legitimate decision when the return compensates. What the map adds to his argument is the spatial dimension. On the commodity side, proprietary costs little: the SQS-to-Lambda wiring, the IAM policies, the deploy pipeline. Migrating that is a few weeks of tedious work, with no business risk, because nothing there distinguishes your company from the competition. Proprietary invading your left side is another conversation. Business flow inside a state machine, an allocation rule expressed in ASL, a core shaped by the database’s data model: when that needs to leave, what leaves with it is the reason the company exists, and the team spends months rewriting what differentiates the business instead of rewiring infrastructure. The gradient fits in one sentence: the further left the component, the more expensive the proprietary inside it.

The lock-in gradient: proprietary coupling costs little in commodity and a lot in custom. The lock-in war, on both sides, treats this curve as if it were flat.

The lock-in gradient: proprietary coupling costs little in commodity and a lot in custom. The lock-in war, on both sides, treats this curve as if it were flat.

When the map does not help

Four limits, so the instrument does not become a religion.

First: position on the axis is drawn opinion. Two competent people will place the same component in different stages, and the axis has no calibrated ruler. That is fine. The map’s value is in the conversation it forces, with everyone pointing at the same drawing, and a wrong placement shows up fast once it is on the wall. What the map will never be is measurement.

Second: a team in love with a tool turns the map into the agenda. If one whiteboard hour produced no build, rent or consume decision, you were not mapping, you were drawing. The map is the means; the sourcing decision is the end.

Third: a small system does not pay for the ceremony. For three people building an MVP, the reading rule applied from memory is enough: managed for everything that is not the differentiator, and the differentiator in a module that does not know AWS exists. The formal drawing enters when the decision involves more people than fit in one conversation.

And fourth, the limit that matters most: the map tells you whether a component goes serverless; it does not tell you how. Position and load shape are orthogonal questions. The hot key from the space-based article appears on no axis of a Wardley Map: DynamoDB occupies the same spot on the drawing with a distributed peak or a concentrated one, and the decision to absorb the decrement in memory comes from the shape of the load, from measuring, from the load test concentrated on a single key. Position decides sourcing. Load decides design. Answer both with the same instrument and you will get at least one of them wrong.

Closing

The evangelist and the traumatized one from the opening were debating the wrong tool for the wrong question. Serverless is a position decision: the map makes the position visible, and the reading rule converts position into sourcing, right side consumes, middle rents behind a thin adapter, left side builds portable, with lock-in charging in proportion to how far the proprietary invades the left. All of it fits in one whiteboard hour before the next architecture diagram.

The concrete step: on your next serverless-or-not decision, get the team together for one hour before any diagram. User need at the top, value chain descending, each component placed on the evolution axis, reading rule applied out loud, component by component. I put together a one-page canvas with the protocol, made to print and scribble on; if you prefer digital, OnlineWardleyMaps draws the map from text. And let the commitment be on record: my next architecture articles open with the map of the decision, before the diagram of the solution. One map in particular has been bothering me for months, the map of the agentic stack, with half its components sliding from custom to commodity faster than teams are noticing. It opens the next text.

References