Architecture Weekly #158 - 18th December 2023

Dec 18, 2023

It seems that for the 3rd time, I got to the HackerNews page. I wrote a lighthearted take on how to find business events from the relational schema:

Hitchhiker's Guide To Moving From Relational Data To Events

Of course, the best way is to talk to business, but! I’ve been in such scenarios where not many people left who designed the original system. The knowledge is tribal, and you not only need to understand the business case from the product team but also check if they are right on how the system works. This article should help in dealing with such cases.

I also played a bit with a writing style; I hope you’ll have fun reading it (at least as good as I had by reading HN comments, which are always so much fun!).

Finding time to sit down and go through to-read least is never easy. Even if you have it filtered and organised, there are always other priorities to push back what we planned. Also, going through the reading without confronting other people’s thoughts is not optimal.

That’s why I came up with the idea of the Papers We Love meetups for Architecture Weekly paid subscribers. We’ll take one whitepaper or article and go with it together, reading it out loud and discussing it as we go.

I want to start with Sagas by Hector Garcia-Molina and Kenneth Salem. It’s a famous work that is foundational for managing distributed processes. We’ll read it together and discuss it on Wednesday.

Feel invited; see the details on the meeting page!

Intriguingly, the fact that we had whitepapers can prove that we’re an engineering or even scientific discipline, but are we? It’s an ongoing discussion; I think we’re more in the alchemy ages than other disciplines, but there are fair points on both sides. Some say we’re just discovering our patterns, procedures and best practices. Dave Farley, in his talk, explains how fast we’re iterating and what we can do about that:

Dave Farley - Engineering for Software

Some are even going further and are saying that we’re not engineers, “the real engineers are in different industries!”. Hillel Wayne did a nice check for that a few years ago and returned to this recently. He interviewed engineers from other industries and talked with them about their best practices. Check that below:

Hillel Wayne - Is Software Engineering Real Engineering?

Not surprisingly, it appeared that the neighbourhood lawn is always greener.

Ah, we also have people trying to tell us that our discipline is an art or craft, but let’s leave those custodians in the IT museums.

We discussed a great article from Pierre Pureur on Architecture Decision Records lessons learned, today I’d like to mention his latest article on architecture pitfalls:

Pierre Pureur - 12 Software Architecture Pitfalls and How to Avoid Them

Pierre highlighted following issues:

Don’t let one person make or influence all the decisions. Instead, have appropriate team members participate in making decisions.
Don’t let reuse goals dictate bad decisions. Instead, reuse only when it makes sense.
Don’t get rid of people with experience working through architectural challenges. Instead, retain them and retrain them if necessary.
Don’t let business decisions dictate your architecture. Instead, make decisions to meet well-defined QARs.
Don’t compromise quality to deliver faster. Instead, manage your Technical Debt at a level that keeps your architecture viable.
Don’t delay delivery (and feedback) to perfect your architecture. Instead, design your architecture using the best information you have and use feedback to improve it.
Don’t let functional requirements drive the architecture. Instead, ensure that it is driven by realistic QARs.
Don’t copy someone else’s successful architecture. Instead, design your architecture using your own QARs.
Don’t outsource your decisions to vendors and consultants. Instead, make sure that you retain control over your architecture.
Don’t over-generalize the architecture. Instead, design for your QARs and only your QARs.
Don’t build the architecture in one go. Instead, build and test it in small increments to reduce risk and waste.

I agree with all of them. My only issue with this list seems to be missing 12 points. But maybe that’s also a lesson that numbers in architecture are not always important; the McKinsey report proved that unintentionally.

EDA Summit is an online conference that gathers people doing EDA in many various ways. Not all proposed advices are sound, but by checking the line-up and content, you can get a decent spectrum of the state of EDA. Recently, they published talks from this year’s edition. You can check all of them for free:

EDA Summit - 2023 Summit Sessions

Martin Kleppmann is one of my favourite people in IT, and his book Designing Data-Intensive Applications is one of the best IT books I’ve read. Ever. That’s why it’s always nice to know more about his take on the future. Check more:

Martin Kleppmann, Jesse Anderson - Designing A Data-Intensive Future: Expert Talk

Some people say that AI is the future. I hope that the future won’t look like Dropbox AI. They were recently caught up by potentially sharing your content with OpenAI. And we already know that OpenAI cares as much about privacy and regulations as I do about Clean Architecture.

Jokes aside, it’s a total flop. We have already learned in cloud adoption that Lift & Shift never works. If we just blindly apply that, without consideration, we can get a worse environment than we had. Now, many companies are trying to apply the same strategy to AI. They try to prove to investors, “Hey, we do AI!”. But if they’re doing as DropBox did, they should start investing in intelligence and then go for an artificial one.

Check also for great coverage on the next case of prompt injection. And think about that before adding AI tools to your product. They can be a great extension, but we shouldn’t rush to add them, stampeding security and privacy issues.

PromptArmor, Kai Greshake - Data exfiltration from Writer.com with indirect prompt injection

A good move by the company came recently, Docker, both TestContainers creators, AtomicJar.

TechCrunch - Docker acquires AtomicJar, a testing startup that raised $25M in January

Docker wasn’t well known for making wise business decisions so far. They changed our industry but didn’t benefit from it enough. Cloud providers did from them. Still, Docker decided to focus on developer experience around containerisation, which sounded like getting back to the niche and slowly collapsing, yet!

This acquisition sounds like a great match. As you know, I’m not a huge fan of TestContainers, but I see potential in them. If they continue the expansion and add more synergy, that can create a good potential for building more useful tooling for developers.

Another company that seems to be in a mess is Hashicorp. I covered in past editions the backslash around licence change, OpenTofu, etc. Now, the creator stepped away. The creator from whose surname was the name of the company made. Mitchell Hashimoto shared publicly the letter he sent to the employees:

Hashicorp - Mitchell reflects as he departs HashiCorp

It shouldn’t be THAT surprising, as he already stepped out from being CEO in 2016 and departed the leadership team and board of directors in 2021. Of course, he’d like to “take on new, different challenges”, and he’s “ready to dabble in new areas”. Plus, his first child was born recently. So, not all have to leave like in OpenAI. And that’s good.

I’m keeping my fingers crossed for Mitchell Hashimoto, as he indeed made a huge impact on our industry with his tools. I think that the company in the state it is wasn’t as he envisioned it. I hope he’ll continue to build tools for us in the future, and spending time with his child is the most important. I know something about it.

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 Weekly

Architecture Weekly #158 - 18th December 2023

Architecture

DevOps

Databases

Frontend

Testing

AI

JVM

.NET

Rust

Coding Life

Industry

Security

Trivia

Discussion about this post