What do you think?
Rate this book
Versioning in an Event Sourced System
Why Version?
Have you ever done a big bang release? You schedule a maintenance window, carefully take down the system, release the new software, and… pray. I will never do a big bang release again. What scares me is not what happens if the release does not work, but what happens if it does not work and yet still appears to.
Most developers, even those working through big bang releases, have dealt with the versioning of software before. For example, they write SQL migration scripts to convert the old schema to the new one. But have you ever written SQL migration scripts to convert from the new schema with data added to it back to the old schema without losing information? What happens if, later, you get a catastrophic failure on the new release?
On teams I have worked with in the past, you got your choice: the fireman helmet or the cowboy hat. In other words, the fireman helmet means if you are working on a production issue, people know not bother you unless they have something material to your issue. I highly recommend this, as at least you get to keep a smile on your face while you are working live in production. To be fair, who wouldn’t want to wear a fireman helmet at work?
In modern systems, however, this is not acceptable. The days of maintenance windows and big bang releases are over. Instead, we now focus on releasing parts of software, and often end up wanting to run multiple versions of software side by side. We can no longer update every consumer when a producer is released. We are forced to deal with versioning issues. We are forced to deal with 24/7/365 operations.
There are many forces pushing us in this direction. We could talk about the move towards SOA/MicroServices, Continuous Deployment, core ideas from the business side, lossed opportunities and reputational risk.
Many of the strategies discussed apply to messaging systems in general. Event Sourced systems also face these kinds of versioning issues in a unique way, as they represent an append-only model. A projection, for instance, needs to be able to read an event that was written two years ago, even though use-cases may have changed.
What happens when you have mistakenly written an event in production? If we are to say an event is immutable and the model is append-only, many complications arise.
Over the years, I have met many developers who run into issues dealing with versioning, particularly in Event Sourced systems. This seems odd to me. As we will discuss, Event Sourced systems are in fact easier to version than structural data in most instances, as long as you know the patterns for how to version, where they apply, and the trade-offs between the options.
Have you ever done a big bang release? You schedule a maintenance window, carefully take down the system, release the new software, and… pray. I will never do a big bang release again. What scares me is not what happens if the release does not work, but what happens if it does not work and yet still appears to.
Most developers, even those working through big bang releases, have dealt with the versioning of software before. For example, they write SQL migration scripts to convert the old schema to the new one. But have you ever written SQL migration scripts to convert from the new schema with data added to it back to the old schema without losing information? What happens if, later, you get a catastrophic failure on the new release?
On teams I have worked with in the past, you got your choice: the fireman helmet or the cowboy hat. In other words, the fireman helmet means if you are working on a production issue, people know not bother you unless they have something material to your issue. I highly recommend this, as at least you get to keep a smile on your face while you are working live in production. To be fair, who wouldn’t want to wear a fireman helmet at work?
In modern systems, however, this is not acceptable. The days of maintenance windows and big bang releases are over. Instead, we now focus on releasing parts of software, and often end up wanting to run multiple versions of software side by side. We can no longer update every consumer when a producer is released. We are forced to deal with versioning issues. We are forced to deal with 24/7/365 operations.
There are many forces pushing us in this direction. We could talk about the move towards SOA/MicroServices, Continuous Deployment, core ideas from the business side, lossed opportunities and reputational risk.
Many of the strategies discussed apply to messaging systems in general. Event Sourced systems also face these kinds of versioning issues in a unique way, as they represent an append-only model. A projection, for instance, needs to be able to read an event that was written two years ago, even though use-cases may have changed.
What happens when you have mistakenly written an event in production? If we are to say an event is immutable and the model is append-only, many complications arise.
Over the years, I have met many developers who run into issues dealing with versioning, particularly in Event Sourced systems. This seems odd to me. As we will discuss, Event Sourced systems are in fact easier to version than structural data in most instances, as long as you know the patterns for how to version, where they apply, and the trade-offs between the options.
100 pages, ebook
Published April 5, 2017
7 people are currently reading
235 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 5 of 5 reviews
Read
April 13, 2017Disclaimer: this review is based on early version of the book (~70%). All the chapters are already in place, but book needs a lot of polishing (e.g. pictures & drawings are either temps or missing).
When I've found out that Greg Young is writing a book on event sourcing, I knew I'd have to read it. Not because I'm any kind of his fanboy (yes, he has some) or because there are so few (any?) books on the topic. I was hooked up by the idea of the book that doesn't just cover ES, but focuses on arguably it's most interesting, most challenging & most risky part - evolution within time AKA versioning. Many people got the idea of what ES is & how to start doing it, but very few have enough long-term practical experience with ES to give good insights on how to deal properly with the changes that will inevitably happen.
OK, back to the book then.
First, this is NOT a book for people who have no clue what ES is. It feels more like Greg has written a book for his "acolytes" who'd like to deepen the knowledge of the topic. He jumps straight into the topic, doesn't provide many clarifications or sidenotes, etc. I absolutely adored that, but some may feel a bit lost (maybe the situation will improve for them once illustrations are in place).
Second, book is not bound to any technology (/platform), including Greg's EventStore. All the examples (not that many, TBH) should be easily comprehensible (syntax-wise) for anyone with programming experience.
Third, parts I've found especially "tasty" were dedicated to: event immutability, event compensation, strictness/weakness of event schemas, patterns of event stream transformations & event sourced process managers - these all are VERY PRACTICAL topics that I've encountered in that form or another (under various names) in my past, so I was very curious regarding author's thoughts on these topics.
To summarize: book is already good, but it can be even better after final polish is made. I won't risk any star-rating yet (~70% means that G. Young can easily turn whole thing upside down once or twice yet :>), but I don't regret spending money on it (even if it's just ~100 pages).
When I've found out that Greg Young is writing a book on event sourcing, I knew I'd have to read it. Not because I'm any kind of his fanboy (yes, he has some) or because there are so few (any?) books on the topic. I was hooked up by the idea of the book that doesn't just cover ES, but focuses on arguably it's most interesting, most challenging & most risky part - evolution within time AKA versioning. Many people got the idea of what ES is & how to start doing it, but very few have enough long-term practical experience with ES to give good insights on how to deal properly with the changes that will inevitably happen.
OK, back to the book then.
First, this is NOT a book for people who have no clue what ES is. It feels more like Greg has written a book for his "acolytes" who'd like to deepen the knowledge of the topic. He jumps straight into the topic, doesn't provide many clarifications or sidenotes, etc. I absolutely adored that, but some may feel a bit lost (maybe the situation will improve for them once illustrations are in place).
Second, book is not bound to any technology (/platform), including Greg's EventStore. All the examples (not that many, TBH) should be easily comprehensible (syntax-wise) for anyone with programming experience.
Third, parts I've found especially "tasty" were dedicated to: event immutability, event compensation, strictness/weakness of event schemas, patterns of event stream transformations & event sourced process managers - these all are VERY PRACTICAL topics that I've encountered in that form or another (under various names) in my past, so I was very curious regarding author's thoughts on these topics.
To summarize: book is already good, but it can be even better after final polish is made. I won't risk any star-rating yet (~70% means that G. Young can easily turn whole thing upside down once or twice yet :>), but I don't regret spending money on it (even if it's just ~100 pages).
Read
March 2, 2018The echo chamber has decided that this is the 2nd book you should read on the topic of event sourcing and I agree. I'm still unsure what the first should be.
November 14, 2019
Pretty deep/advanced book on the problem of versioning events in the event-sourced system (and couple of related subjects/areas). It's a bit rough around the edges (feels like it was not completely finished) and it's more theoretical, rather than practical (you will be hard-pressed to find almost any source code there), but given the lack of material for this area of software architecture I won't hold it against it.
August 1, 2020
Not finished but it seems that it has almost the whole planned content. The book is full of well-described patterns with theirs pros and cons.
June 26, 2020
Greg Young explains various ways of versioning events. His expertise on the subject gave me quite a few new insights. I can recommend it for everyone building or looking to build an event sourced system.
Displaying 1 - 5 of 5 reviews