Understanding the importance of events and consequences 2 – Understanding Event-Driven Architecture

But this is the saner half of the event tree that led to this event. The other half is even more interesting:

• I was on that train because I went to sign a job contract.
• I got the offer for that job because I made a post about having all 11 Google Cloud certifications on the Google forums, and the company that I currently work for just happened to notice.
• I made that post exclusively because I got all 11 of those certifications. I got the last one on the day before I left for Sweden. Had I only gotten 10, I wouldn’t have made it.
• I got those certifications largely as a sort of reinforcement of the knowledge that I wanted to deliver with this book.
• I got the offer for this book from my publisher after applying for it based on the link that I found in one of their other books, which was a Google Cloud examination book.

So, in a roundabout way, writing this book helped me secure the job I have today, and it eventually led to me finding more Nepalese people in Uppsala. If you couldn’t be bothered with all of that, let me show it to you visually:

Figure 8.2 – The events that drove a part of my life

The events in our lives lead to the most extraordinary circumstances, and this was just one of the events that came about from this whole saga. Several other remarkable things happened through all of this that made me realize that the true consequences of our actions are truly unpredictable and yet, most of the time, a lot better or at least more exciting than anything we could have possibly planned.

Self-indulgent? Probably. But that is the magic of DevOps. Conforming to tight structures and solid preconceived notions leads to fear and stunts growth. They hide and overshadow opportunities that spontaneity brings. There is no room to find, discover, and fail. Yes, fail, because in something so tightly packed as a monolith, failure can be disastrous. In something loosely coupled, failure is simply a growth opportunity. You can move pieces in and out and iterate to your best possible version. You may look at my story and say that a lot of it is luck and coincidence – for example, in finding the exact person I needed on the train or just happening to have my forum post viewed – but luck is simply an amalgamation of one’s sustained attempts. People sometimes get lucky once or twice, but people who are not afraid to fail and who go with the flow are found to be lucky a lot more. God hates a coward.

So, switching gears to something a little less philosophical, loosely coupled architecture is a sort of framework you can use to achieve this kind of meaningful event-based system in your workload. This entire passage was initially supposed to be the next section before it took a life of its own (spontaneity, amirite?). So, let’s dive into the actual nitty-gritty now and see what we can find.