Architecture Weekly #146 - 25th September 2023
Architecture Weekly #146 - 25th September 2023
Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Welcome to the new week!
People fear the wrong state in the event streams while not being afraid of traditional storage. And here's the deal: both may be broken the same way. The difference is that we may not even notice that it's broken in the traditional storage.
We'll see that in Event Sourcing because we have tools for that. Event streams, if modelled correctly, can give us explicit details on the current state, why it is like that, and how we got here.
In my latest article, I expanded using the hotel housekeeping schedule adjustments as an axis for dealing with the change in Event Sourcing. Change is always hard; I understand that. Not knowing about the bad case can be more blissful than knowing the hard truth.
Still, if we don't want to ignore the facts and create proactive systems, then having a clear view is a big benefit that shouldn't be seen as a challenge. Read more:
I'm delighted that Derek Comartin is doing the hard work for me so often. In the last few days, I was asked by 3 different people about the Listen to yourself "pattern". It's great that I could link Derek's video and just say ditto:
Listen to Yourself is one of those "patterns" that came right from the tooling limitations to work around them and get so popular that they started to be called a pattern. From my perspective, it's mostly anti-pattern as the real usage is limited. It introduces the consistency difficulties that could be handled using the right solutions, like the Outbox pattern or not treating the queue as a database.
I think that it's mostly valid for scenarios where you need to accept incoming commands and then process them later. Such a scenario could be useful for peeks in traffic like BlackFriday order processing, as queues (e.g. SQS, SNS) can usually be autoscaled horizontally easier than databases.
One small difference from the video is that I believe that ES subscriptions are not necessarily implementations of Listen To Yourself; I think that they're more Outbox built into event stores.
How do you deal with consistency and handling business workflows properly, then? Yves Reyhnout provided a great answer for that:
You rarely see blog articles that show breakthroughs and trigger such in the readers. I was searching independently for the essence of the modelling and explaining how to model asynchronous/distributed processes and straightforwardly implement them. You can see that in:
Yet, what Yves provided is a condensed and actionable explanation. Rarely are patterns prescriptive. I’d compare the importance and the impact similar to Jérémie Chassaing's Decider.
It’s a must-read for anyone interested in Event-Driven Architecture.
One of the conclusions from the previously mentioned articles is that aligning your architecture with the business problem is critical. We see emergent approaches like team topologies and platform engineering. I’m not so gullible to hope that all companies will understand the impact of Conway’s Law and the need to reduce cognitive load. Still, I hope those approaches will be expanded enough to impact our industry more.
We’re not Business and IT anymore; now, IT is a Business.
Ryan Shriver did an intriguing case study on how you can align your cloud architecture with business:
Of course, I’m not a huge fan of the buzzwords like Domain-Driven Cloud. They sound cheesy, but you probably need a catchy term to promote the approach.
Still, the article is good. It explains and presents a good framework for how to start your architecture design. It promotes the approach by starting with a logical split based on the business domain, then breaking it down into bounded contexts (modules), thinking about the expected workloads and aligning that with cloud technologies.
This article also aligns well with articles I linked in past editions:
Gregor Hohpe - Cloud Automation à la DDD: From stringly typed to affordances
Uber - Introducing Domain-Oriented Microservice Architecture
It’s important to remember that the cleanness of the approach is not an end goal. The end goal is to deliver software that fulfils business requirements and does that correctly. We should not make rotten compromises around performance just because we want clean code or architecture. Those terms are blank and can be interpreted in numerous ways.
Our solutions need to be user-friendly but also machine-friendly.
Read more on how to build proper solutions, focusing on the approach's performance and correctness.
One of the things that we’re missing in our industry is accountability. We’re too focused on measuring the metrics instead of focusing on the outcome and being accountable for it. Aaron Stannard took the try to describe that challenge:
He broke down accountability into three groups:
Accountable to customers or potentially other external stakeholders, like investors. (…)
Accountable to team - this is the middle management-tier responsibility. (…)
Accountable for individual performance - this is individual contributor responsibility. (…)
These accountabilities compound on top of each other - high-level executives are still accountable to the team AND still accountable for their own performance.
I think that we should realise that we’re all accountable to someone, and delivering a proper solution is a joint effort of all parts. Of course, building the right process that enables good from people is essential, but we should also not forget to make them accountable.
I wrote about that in On the importance of setting boundaries in team management.
Read also an interesting interview with Ron DeVera, ex-Twitter (or ex-X…) Staff Engineer. He shares his lessons learned on how to influence the outcome, dealing with difficult coworkers and managing up:
Check also other links!
Oskar
p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!
p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.
Architecture
Oskar Dudycz - Oops I did it again, or how to update past data in Event Sourcing
Ryan Shriver - Domain-Driven Cloud: Aligning Your Cloud Architecture to Your Business Model
Derek Comartin - Alternative to the Outbox Pattern? Not so fast
Mark Schwartz - Everyone is Busy: Who Has Time to Transform?
DevOps
JavaScript
AI
Java
.NET
Jeremy D. Miller - Wolverine Expands its Multi-Tenancy Story to HTTP
Michal Strehovsky - Reverse engineering natively-compiled .NET apps
Rust
Coding Life
Management
Industry
The Street - Salesforce CEO takes another bold stand on remote work
ArsTechnica - Linux gives up on 6-year LTS kernels, says they’re too much work
phoronix - The Maintainer Of The NVIDIA Open-Source "Nouveau" Linux Kernel Driver Resigns