The shift from monolithic architectures to microservices marked a historic inflection point in the evolution of cloud applications. When AWS Lambda arrived a few years later, it pushed this transformation even further by giving us a way to build extremely small, atomic services. A single request could now trigger a self-contained function that scaled independently, executed quickly, and required no infrastructure management. This simplicity changed how many teams approached software design.
Small transactional workloads became the new norm. The more we decomposed logic into granular functions, the more we gained: near-infinite scalability, cost efficiency, and an explosion of database services designed for serverless elasticity. Lambda freed developers from boilerplate infrastructure concerns and encouraged architectures where business logic lived in short, sharp bursts of execution.
Yet this victory came with a thorny side effect: orchestration complexity.
Once functions became tiny building blocks, connecting them grew harder. A single business process often required chaining together many functions, coordinating state transitions, handling retries, ensuring idempotency, and managing failure states across distributed components. In other words, reducing the complexity inside each function multiplied the complexity between functions.
For a while, AWS Step Functions emerged as the default answer. State machines offered a visual and declarative way to stitch Lambdas into workflows. It worked—up to a point. As real-world systems grew larger and more dynamic, developers ran into friction. State definitions became verbose, onboarding new engineers was difficult, and costs could rise quickly. Amazon itself acknowledged this challenge when Prime Video publicly described moving away from Step Functions due to cost and operational overhead.
AWS responded with improvements like Express Workflows, designed to reduce cost and increase throughput for high-frequency orchestrations. This softened some of the pain, but not the core tension: workflows were either too rigid or too expensive for many scenarios involving large-scale, fine-grained functional decomposition.
Now AWS is introducing Durable Function for Lambda, a fresh attempt to tackle the orchestration puzzle. The idea is simple but powerful: let developers write orchestrations in code, using familiar programming constructs, and let AWS handle state persistence, progress tracking, and retries behind the scenes. It is an effort to eliminate the complexity without abandoning the advantages of serverless decomposition.
The ambition here is bold. If durable orchestrators can become easy to adopt, cost-efficient, and flexible enough for a wide range of business processes, they might unlock the long-promised vision of cloud applications running almost entirely on Lambda—where containers become the exception, not the rule.
My current take is cautiously optimistic. Durable Function is a move in the right direction, but we are still a few years away from seeing an orchestration model that fully matches the maturity, ergonomics, and predictability required for large-scale, Lambda-only architectures. Serverless compute is no longer the challenge; distributed workflow management is. The platform that solves orchestration cleanly, seamlessly, and affordably will define the next era of cloud-native development.
Durable Function may be one more step toward that future—perhaps a meaningful one—but the journey isn’t over yet.
Top comments (0)