CONCEPT Cited by 1 source
Incremental delivery (over big-bang rewrites)¶
Definition¶
Incremental delivery is the posture of shipping architectural change as a sequence of small, observable, reversible steps — each of which delivers some customer-visible value — rather than staging a big-bang cutover. Coupled with a long-term blueprint, not a replacement for one.
Marc Olson's framing (EBS, 2024)¶
We chose to approach the problem, not as a big monolithic change, but as a series of incremental improvements over time. This allowed us to deliver customer value sooner, and course correct as we learned more about changing customer workloads.
And on blueprints:
The blueprint that we laid out in 2013 ended up looking nothing like what EBS looks like today, but it gave us a direction to start moving toward.
The key property: every intermediate state must itself be a valid production system. This is only possible if you built for non-disruptive change (see patterns/nondisruptive-migration) from the start.
Why it wins at EBS scale¶
- Workload assumptions drift. Committing to a 2013 blueprint as-specified would have locked out the custom-SSD move. The blueprint was a direction, not a contract.
- Observable steps let you course-correct. If a change doesn't deliver, unwind and try another.
- Customer-perceived value arrives along the way. Provisioned IOPS in 2012, SSD-retrofit-staged writes in 2013, Nitro offload gradually — every step shipped to real workloads.
- Risk is bounded. A bad change has a small blast radius; a bad big-bang cutover does not.
Related¶
- concepts/simplicity-vs-velocity — the tension incremental delivery navigates: every simplification is an improvement on a not-simple-enough prior launch.
- patterns/nondisruptive-migration — the mechanism that makes incremental delivery feasible at EBS's scale.
- patterns/hot-swap-retrofit — a concrete incremental-delivery case: SSDs taped into existing servers, no cutover.
Seen in¶
- sources/2024-08-22-allthingsdistributed-continuous-reinvention-block-storage-at-aws — the post's "Set long term goals, but don't be afraid to improve incrementally" section makes this the central engineering lesson.