Architecture Weekly #130 - 5th June 2023
Architecture Weekly #130 - 5th June 2023
Welcome to the new week!
Last Monday, we had a webinar for paid subscribers of Architecture Weekly, discussing Postgres Superpowers in Practice.
You can watch it too and learn using the Fleet Management example of how Postgre can help to deliver faster business value. Almost two hours of practical knowledge and hands-on experience!
Real-world examples are always crucial as part of providing design. I wrote already longer on the risk of ignoring risks. Thinking about what can go wrong and finding potential remediations is essential. That can help us to find the unknowns and challenge the initial assumptions.
Andreas Öhlund and David Boike presented an intriguing technique of using anti-requirements. They wrote:
Anti-requirements are deceptively simple: you create some fake requirement concerning two attributes and present it to business stakeholders. “If the product has more than 20 characters in its name,” you say to them, “then its price must be at least $20.”
(…)
Without anti-requirements, teasing out these details can be tricky. Since business domain experts tend to think of this stuff as obvious, which makes them unlikely to volunteer this information. They’re generally surprised that developers don’t know it already. That makes it our job as developers and architects to dig for it.
Read more in:
I like that idea, as I also observed in my projects that essential business knowledge is often not passed to us by the business. And it’s not that they want to or ignore it, just it’s so common for them that they assume it’s the same for us. Which too often is not.
Still, finding unknowns is just the homework that we should do. The real challenges are unknown unknowns. Our world is so complex that finding all the challenges is impossible. Based on our gut feeling is too big a risk and one of the reasons for failure.
I had the big pleasure of watching live the talk by Barry O'Reilly, where he explained his Residuality Thory. It’s a result of his scientific research and his experience as an architect. It’s based on the chaos theory but made actionable for us, mere humans.
Check his research and a bit older recording; we don’t have a lot of new thrilling ideas like that. It’s a must known about unknowns.
We should be careful not to overcomplicate our design and focus on delivering something good enough. I wrote about the Holy Graal syndrome, which in my opinion, is one of the fallacies and the reasons why we overcomplicate design. You don’t know it? Then read more in:
Getting back to business rules, do you know there’s a Business Rules Manifesto and a standard for business rules? Yes, it is. The page looks quite nineties, and the text looks a bit formal, but there are a lot of interesting and actionable points there. Check:
Getting back to the chaos, check talk by Holly Cummins, showing her lessons learned on running Microservices on the scale. All backed with personal experience on the staff that can go wrong, what we’ll have to deal with and how to survive the mayhem.
Staying on the practical level, check the recording of Stefan Pölz webinar where he’s showing the mutation testing using C# as an example. Per Wikipedia:
Mutation testing (or mutation analysis or program mutation) is used to design new software tests and evaluate the quality of existing software tests. Mutation testing involves modifying a program in small ways. Each mutated version is called a mutant and tests detect and reject mutants by causing the behaviour of the original version to differ from the mutant. This is called killing the mutant. Test suites are measured by the percentage of mutants that they kill.
Together with property testing it’s one of the automated ways to discover what our code is missing. This is super important, as our tests usually can only verify what we predicted. Yes, even if we have 100% test coverage.
Test coverage is one of those metrics that can give a hint but not always show the whole picture. The same can happen in glorified DevOps DORA Metrics. Check what can go wrong if we’re too focused on measurements.
On the DevOps part, see a nice walkthrough of the latest duel Service Mesh vs eBPF. So how to inject our common cross-cutting concerns into our system. As always, the stakes are complexity, performance and efficiency.
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
Barry O'Reilly - Residuality Theory, random simulation, and attractor networks
Andreas Öhlund, David Boike - Using anti-requirements to find system boundaries
Facundo Agriel - Magic Pocket: Dropbox’s Exabyte-Scale Blob Storage System
Domenic Cassisi - Why is Kafka not Ideal for Event Sourcing?
DevOps
Database
Testing
AI
AWS
Azure
Java
Shaun Smith - GraalVM Native Image — Faster, Smarter, Leaner
Harish Kumar - Easy Implementation of GDPR with Aspect Oriented Programming
.NET
Stefan Pölz - How To Test C# Unit Tests With Mutation Testing
Khalid Abuhakmeh - Introduction to ASP.NET Core Minimal APIs
Suminda Niroshan - Using .Net X509 Certificates to Sign Images and Documents (C# .Net)
Andres Lopes - Creating a simple real-time chat with .NET Core, ReactJS and SignalR