Architecture Weekly #85 - 25th July 2022

Jul 25

Welcome to the new week!

I recently wrote on Twitter that almost everything is possible in the IT world. You can workaround in many ways. You can find a name for a hack and call it a design pattern. You can find people that are doing the same. Yet... Just because you can, doesn’t mean that you have to.

Many people are so focused on proving their idea can be done that they forget to ask themselves such questions. Then they're fighting with accidental complexity and creating seriously-looking but highly fragile and overcomplicated solutions.

It’s essential to be careful those days. Companies are paying those days dev advocates (wink, wink), evangelists, and dev-rels. That general trend is helpful, as you’re getting a lot of content for free on how to use a specific tool. However, there’s a challenge. The content is targeted at the current users or potential “prospects”. The aim is to explain how to use a specific tool or why you should use it. Too often, it lacks the information about the needed “whys” to make decisions. It’s advocating, not educating. Check Martin Fowler’s article; he explains the difference clearly.

Martin Fowler - Advocate, educator, and authorial stance

Some companies are franker, some less. For instance, when I worked at Event Store, we decided to provide a Beginner’s Guide to Event Sourcing. It was tempting to provide something that will explain it using the specifics of EventStoreDB implementation details, yet, we dropped this idea, as there are too many bad takes that we wanted to make it right. I’m glad that my friend Anton also decided to provide his take on this:

Anton Stöckl - Event Sourcing: Why Kafka is not suitable as an Event Store

I also wrote an article on that, gave a talk, and did a meme. My general take is that it’s harmful when some people push Kafka everywhere. Harmful for the community, as it’s hijacking terminology and skewing it. Most importantly, it’s harmful to the Kafka users, as they’re misled and usually learn too late that they’re not in the place they hoped to be.

Beware of the technical jargon and half-truths; think for yourself and question authorities. If you want to go down the rabbit hole, and see what I mean, check this Twitter thread.

Have a read of also article explaining the differences between event streaming and queuing/messaging solutions on the Kafka example:

David Boike - Let's talk about Kafka

The other common belief is that Cloud is something that should never have issues as the regular servers have. Remember that under each cloud, there is a bare metal somewhere. Don’t believe it? Check:

The Register - Google, Oracle cloud servers wilt in UK heatwave, take down websites

I wrote last week's article explaining how class composition and proper typing can help to model your business process in code. I explained how the Decider pattern could help you by using the latest Java language feature as examples. I encourage you to have a look, even if you’re not a Java dev. It shows the thought process and should also apply to other languages:

Oskar Dudycz - How to effectively compose your business logic

If you want to learn something new, I found three free courses/books for you:

Karan Pratap Singh - Go Course

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 Red Cross, the Ukraine humanitarian organisation. You may also consider joining Tech for Ukraine initiative.