Architecture Weekly #125 - 1st May 2023
Welcome to the new week!
Good fences make good neighbours. The quote comes from Robert Frost's poem but applies neatly to software design.
DDD tells us about bounded contexts and how they're essential. EventStorming promises to help in distinguishing that. But the result is usually glimmering when we try to do those exercises on our own. Proper modularisation requires experience, practice and also proper techniques. Some may call them patterns, but they're not prescriptive, so I prefer to call them heuristics.
You can spend much time doing your modelling katas, but the best is to mix them with learning from the others that went that way. As with Karate Kid, we need to start with painting fences to be able to understand that.
On the last Architecture Weekly webinar, Radek Maziarka took the Master Miyagi role and showed us some of his modularisation heuristics. I loved the idea of distilling the most important questions that our system needs to answer and finding which events bring the data to answer them. That simple technique helps us to verify if all of those events are in the same module and, f we really have a single source of truth. Watch the recording below!
Webinar #9 - Radek Maziarka - Modularization with Event Storming Process Level
Watch now (98 min) | This time we had a special guest: Radek Maziarka. He explained to us Modularization with Event Storming Process Level. Radek showed intriguing and actionable heuristics on how to get from the sticky notes to the modular design. He showed ways how to crunch and challenge the initial assumptions
Event-Driven projections are a great way to build read models interpreting data from events in multiple ways. Projection logic is predictable so that the same set of events will generate the same results. In theory, that means we're safe to run unit tests to verify them. But the real-life is not so easy.
We could write projections so that they’re always upserting the whole data. It could work in many cases, but if we want to make them performant and optimised, then we should benefit from the end storage capabilities.
For instance, MongoDB provides a neat API for atomic partial updates. Why wouldn’t we benefit from them? Yet, we also need to embrace that not all databases are giving us the guarantee that we’ll immediately read our writes (e.g. MongoDB doesn’t).
Moreover, event-driven tools give us an at-least-once delivery guarantee, meaning we might be processing events multiple times. How to test that? I wrote about that in the latest article.
Testing is not only ensuring that our application doesn’t have bugs. For me, it’s only one of the aspects. The other is understanding how our software works. By looking at tests, we should be able to understand our application. So it’s a form of documentation and characterisation. Read more in the great Michael Feathers article:
Our systems have become too complex to understand all tiny bits of the behaviour; we need to make them observable to investigate it when needed. That should also be reflected in our tests. Check more in:
The biggest issue we observed last week was a Google Cloud Incident. Yes, with the capital I. We expect resiliency from our cloud. Thus, we’re investing in making our systems distributed. The basis for that is cloud regions and availability zones. We select cloud regions to have servers close to our users. But inside them, we also distribute the locations into availability zones (AZ) to minimise the accident's impact. Incidents like lack of electricity, flood, fire etc. That’s why the AZs should be kept in the distance, e.g. 50-100km.
If we have redundancy and deploy our services into three availability zones, then we’d expect they won’t go down together. And that would happen if they were really distributed also in the distance. That’s not truth for Google Cloud. All the availability zones in Paris appeared to be located in the same location, just isolated by the network configuration. And then they became flooded…
Intriguingly enough, the previous accident of the smaller OVH Cloud also happened in France. Many people used that to motivate moving to bigger Cloud Providers, as that won’t happen for them. Yup…
Read more:
Thoughtworks released the latest, 28th Technology Radar. Of course, it’s all about generative AI. It’s not that surprising and not surprising that the previous radars didn’t predict that… Still, it’s a good source of information about the software trends. Especially correct on the things about the stuff that are becoming obsolete.
Speaking of which, check the report around the API trends; it seems that GraphQL is getting out of fashion. Or in other words, its usage is maturing, which doesn’t have to be a bad sign for it.
The next week I’ll be giving a talk at Devoxx Greece on how to deal with privacy and GDPR in Event-Sourced systems. Even though it’s all about the proper data governance practices and not a new thing, even the police is surprised to find out when companies are playing by the rules:
Check also other links!
Cheers
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
DataCenterDynamics - OVHcloud's data center fire: One year on, what do we know?
WunderGraph - Is GraphQL dying? 2023 Trend Analysis of REST, GraphQL, OpenAPI, SOAP, gRPC and tRPC
Prequel - SQL Maxis: Why We Ditched RabbitMQ And Replaced It With A Postgres Queue
Gregor Hohpe - Programming without a stack trace: When abstractions become illusions
Valerii Udonov - Domain-Driven Design: building the Right thing Right
InfoQ - EventMesh Serverless Platform Promoted to Apache Top-Level Project
Databases
Turso - Turso is an edge-hosted, distributed database based on libSQL
libSQL - a fork of SQLite that is both Open Source, and Open Contributions.
Frontend
Testing
AI
.NET
Microsoft - Secure your .NET cloud apps with rootless Linux Containers
Luce Carter - Zero to Document Hero - Intro to MongoDB and .NET