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:

• Andreas Öhlund, David Boike - Using anti-requirements to find system boundaries

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.

• Barry O'Reilly - An Introduction to Residuality Theory

• Barry O'Reilly - Residuality Theory, random simulation, and attractor networks

  ---

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:

• Business Rule Group - The Business Rules Manifesto

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.

• Holly Cummins - Cloud Chaos & Microservices 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.

• David Rant - How Not to Use the DORA Metrics to Measure DevOps Performance

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.

• Jim Barton - Sidecars, eBPF and the Future of Service Mesh

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

• Oskar Dudycz - The Holy Graal syndrome

• Barry O'Reilly - Residuality Theory, random simulation, and attractor networks

• Andreas Öhlund, David Boike - Using anti-requirements to find system boundaries

• João Antunes - From domain events to infrastructure - thinking out loud about possible approaches I don’t hate

• Facundo Agriel - Magic Pocket: Dropbox’s Exabyte-Scale Blob Storage System

• Frank Leymann - Transactions in a Microservice World

• Business Rule Group - The Business Rules Manifesto

• Holly Cummins - Cloud Chaos & Microservices Mayhem

• Domenic Cassini - Why is Kafka not Ideal for Event Sourcing?

DevOps

• David Rant - How Not to Use the DORA Metrics to Measure DevOps Performance

• Jim Barton - Sidecars, eBPF and the Future of Service Mesh

• Eugene Khyst - Set up Nginx and Let’s Encrypt with Docker Compose in less than 3 minutes with a Docker Compose project

Database

• Zalando - Patroni - A template for PostgreSQL High Availability with Etcd, Consul, ZooKeeper, or Kubernetes

• Lokhesh Ujhoodha - Save time scavenging with EventStoreDB v22.10

Testing

• LastMinute.com - Impacts of contract tests in our microservice architecture

AI

• Phillip Carter - All the Hard Stuff Nobody Talks About when Building Products with LLMs

AWS

• James Eastham - Build Asynchronous API's using the Storage First Pattern & the AWS CDK

Azure

• Microsoft - Announcing Materialized Views for Azure Cosmos DB for NoSQL (Preview)

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

Node.js

• Turbo - Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turbopack and Turborepo.

Management

• Plane - Open-source, self-hosted project planning tool

Industry

• Harvard Business Review - Rethink What You “Know” About High-Achieving Women

• Jensen Huang - NVIDIA Keynote at COMPUTEX 2023

• Federal Trade Comission - FTC and DOJ Charge Amazon with Violating Children’s Privacy Law by Keeping Kids’ Alexa Voice Recordings Forever and Undermining Parents’ Deletion Requests