Forwarded this email? Subscribe here for more

Architecture Weekly #150 - 16th October 2023

Oskar Dudycz

Oct 23

READ IN APP

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Welcome to the new week, and what a week: 150th!

Yes, it’s the 150th edition of Architecture Weekly! Who knew that it’ll last so long? Definitely not me. I’m thinking about running some Q&A Live on YouTube. If that’s something interesting for you and you have questions for me, please drop me a note!

And thank you for being here!

Speaking about a live webinar, don’t miss this week’s webinar (Wednesday 25th, 6 PM CEST) with Mateusz Jendza on Why Verified Credentials is the Future of Digital Identity!

I think that sovereignty, privacy and security will be one of the leitmotifs of our system design, so it’s worth keeping an eye on it to understand our options. Click here to see all the details.

I just wrote an article that some may find surprising that's coming from me. I wrote a defence of the Object-Relational Mappers. I'm happy I didn't have to use ORMs in my last projects, but...

I'm fed up with takes: "ORMs are bad". They are just like we made them and are as good as our usage is aligned with their capabilities. When struggling with ORM, we should get back to the drawing board and think if it's not a design or organisational issue.

Don't hate the player; hate the game. And read more in:

Oskar Dudycz - In the defence of Object-Relational Mappers

Read also an article by Jeremy D. Miller; he explains the patterns behind Marten. It’s an excellent showcase of how you should perform your storage tools features understanding.

Jeremy D. Miller - Important Patterns Lurking in Your Persistence Tooling

Engineering at Meta released an intriguing article on the under-spoken topic: dead feature removal. In one of my last regular projects, we realised that the feature that’s eating around 80% (or more) of our cloud bill was almost unused by our customers. That was a shameful finding, but at least we already had the capabilities to gather those metrics. That’s not the case for most of the companies.

On the scale of Facebook, unused features can cost a lot, not only in the infrastructure but also in understanding maintenance. It’s critical to know what’s used, whether the feature reached its goals and define the proper strategy for sunsetting features, code or even whole products.

Facebook came with a Systematic Code and Asset Removal Framework. It assists engineers in safely and efficiently deprecating products via an internal tool. It’s a grey matter and whiteboard tool and has automation built around it to reduce the impact on other features. Read more in:

Engineering at Meta - Automating product deprecation

This is the first post out of three; I’ll keep you posted on them, as removing orphan features is essential to building products efficiently.

Another interesting case study came from GitHub; they explained how to use OpenTelemetry to understand Git bottlenecks at scale. It’s a story based on Microsoft migration to Git that started in 2017. It’s a really meaty article. We usually see takes on what’s OTel, how Observability is important, yadda, yadda, but this shows real-world struggles and how the investigation was practically made. Read more in:

GitHub - Measuring Git performance with OpenTelemetry

I thought I knew PostgreSQL superpowers pretty well, but I’m still getting surprised. I just found out that you can use Postgres for caching by using the Unlogged table. Such a table won’t be hitting Write-Ahead Log won’t be replicated, so practically, it’s ephemeral. That sets up options for using it as a cache. I haven’t played yet with that, but I definitely will do more investigation. as if used wisely, it can open many options if you’re already using Postgres:

You can also read the take on using Postgres as Queue, although that’s not probably what I’d recommend as the default choice. We should use the right tools for the job, but it is also worth knowing the limits of the tools we use:

Adriano Caloiaro - Choose Postgres queue technology

I wrote in August on the licence change made by HashiCorp to their products, including Terraform. That created outrage about the lack of the Open Source Spirit that triggered forking and setting up the OpenTofu project.

I still believe setting up proper licencing is necessary for Open Source projects. I also don’t see how OpenTofu should succeed for now, as they’d need to get bigger investments from, e.g. big cloud providers, or they will face the same issues as HashiCorp. And I don’t see an incentive for Cloud Providers to support tools they don’t control, which can smoother cross-cloud development.

Still, looking takes from HashiCorp CTO:

The Stack - HashiCorp CEO predicts OSS-free Silicon Valley unless the open source model evolves

I see the potential for failure, as they seem desperate and/or don’t have a clear understanding of how OSS works and the state of the industry. It’d be better if he didn’t assign his issues to the whole. Read in Linux Foundation response:

Linus Foundation - How open source foundations protect the licensing integrity of open source projects

Running OSS and making a living out of it is hard. I know it too much on my own. Yet, the basis for that is understanding that it has to be thought of as a product, plus being transparent to users and ourselves. See also intriguing talks about that from Evan Czaplicki:

Not to end up with the sad conclusion, see the impressive history of ASCII Art in Amiga. As I still have my over 25-year-old Amiga 500, I was amused by that!

Heikki Lotvonen - Amiga ASCII art

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.