Jul 24

Welcome to the new week!

I took July as a break from commercial work and bigger engagements. I decided to keep sending the newsletter and post new articles, as I wanted to keep consistency. Yet, we didn’t have any webinars this month, but we’ll have two in August!

On the 2nd of August, together with Jeremy D. Miller, we’ll try to show how to reduce boilerplate in your .NET applications.

We’ll take the simple Event Sourcing application I showed on NDC Oslo:

And try to make it even simpler by using Wolverine. It’ll be a live pair programming, where we’ll discuss the assumptions behind Wolverine and how it helps to keep things simple. Some of that Jeremy mentioned in his latest article:

Jeremy D. Miller - A-Frame Architecture with Wolverine

I think non-.NET devs will find something interesting about it, as we’ll focus on the architecture aspects using Wolverine and Marten as examples. Join the paid subscribers community to join us live!

As mentioned, I’m continuing my blog-each-week streak. This time I published a small tip on setting up global variables in .NET tests with XUnit. That can be helpful if you're doing API integration tests for an application using Marten.

I also included a small rant on .NET testing frameworks. Psst, they’re not great.

Oskar Dudycz - How to set global setting for XUnit tests

OK, enough about .NET. And Now for Something Completely Different.

Shopify bragged about the browser plugin they use to show how much the meeting costs the company. Some people took it as a healthy idea to cut the meetings that should have been an email. My take on that was different…

CNN Bussiness - ‘Time is money’: Shopify calculator shows how much unnecessary meetings really cost the company

I think that’s a mark more about organisation rather than meetings. The quality of meetings (or rather the lack of it) is one of the most visible signs of the company's issues, but rarely the root cause.

I have also been in projects where I spent 6-7h in meetings, so I’m not trying to downplay how they can degrade work experience, but the usual issues were elsewhere.

The most important is to agree that it’s OK to skip meetings and ensure you won’t miss anything. I wrote more tips on how to run meetings effectively on my blog.

And life is funny, as a few days later, I found such an article on yet another cost optimisation at Shopify:

The Deep Dive - Shopify Employee Breaks NDA To Reveal Firm Quietly Replacing Laid Off Workers With AI

There’s a difference between doing cost-savings and just being cheap.

How to tackle the organisation issues? Read more in a decent case study on how Xapo Bank approached its organisation change.

A. Streets, K. Dziublinski, A. Harmel-Law - Decentralizing the Practice of Architecture at Xapo Bank

They were always remote-first but changed the business model from a Bitcoin service provider to an online bank. It’s an interesting story on how to get alignment between your business needs, product and engineering strategy.

Not surprisingly, introducing the proper team topology and focusing on the business domain helped. Yet, that’s only possible when you’re passed your market validation and know what you’re doing and what you want to be doing.

Check an article explaining why we should not set up a permanent Platform Team.

Aleix Morgadas - Interim Platform Team

I also think that, by definition, such teams should be made for the particular cause of enabling other teams to focus on their work. By definition, they should be treated as interim until they fulfil the specific goal. And this goal should enable other teams. Of course, they may be kept longer, but we should always reevaluate if the current constellation we designed in the past still applies.

Such process evolution and enabling autonomous teams to share standard practices is the main idea of the DevOps movement. I mentioned already that the practices in the companies skewed perception of this idea. DevOps is not rebranded Ops teams using newer tools. It’s a set of practices and approaches to dealing with socio-engineering systems. Those practices should not be considered as novel but as commodities. Is that really the case?

Check the annual InfoQ report about the DevOps Trends:

InfoQ - DevOps and Cloud InfoQ Trends Report – July 2023

There are interesting quotes:

In the accompanying cloud and DevOps trends podcast discussion, the participants address the state of cloud innovation and DevOps. They agree that cloud innovation has slowed down, moving from "revolution" to "evolution".

Also:

As for DevOps, it is still alive but has reached a stage of stagnancy in some organizations. The concept of DevOps, which aims to provide access and autonomy to create business value, is still alive, but the implementation has faced challenges. The panelists mentioned their interest in Value Stream management to unlock DevOps’s flow and value realization.

Quite an enigmatic sentence, aye? Still, you can read between the lines that companies realised that just applying CI/CD tooling or Kubernetes is not enough to say that you built the proper development process.

The public cloud vendors have evolved from their original goal of providing on-demand access to scalable resources to focus more on offering managed services. This evolution has made cloud computing more ubiquitous. However, technology is changing rapidly around existing services, new business requirements are being discovered, and new challenges are emerging. Teams must balance adopting and updating technology stacks while continually delivering business value

So as always, cloud providers made monetisation out of it but then realised that they had achieved feature ubiquity. So they invested more in creating managed services to lock customers. Which, of course, didn’t help all the companies to deliver business value.

Watch also a nice talk by Andrew Clay Shafer debunking some of that:

Andrew Clay Shafer - More Buzzwords Won't Help: The Long History of DevOps Failures

InfoQ report also notices the emergence of WebAssembly as the new hope for a “write once, run anywhere" solution. Yes, also on the backend. That’s also an area that I’m looking for and planning to invest more time in. See nice presentation explaining this technology:

Edoardo Vacchi - WebAssembly from the inside out

LinkedIn released a new article explaining how moving from the JSON serialisation to Protobuf changed and improved the spread of their services.

LinkedIn - LinkedIn Integrates Protocol Buffers With Rest.li for Improved Microservices Performance

And that can be some information that we should consider, but what’s staggering for me when I looked at the article, and Rest.li is that I don’t see how it applies the REST principles. In my opinion, it’s more CRUD.li than Rest.li…

Based on the modelling tips I found in the documentation, it promotes a narrowed view using common verbs (GET, PUT, POST, DELETE). It is missing the main idea, so hyperlinks.

Don’t be like LinkedIn, be like Asbjørn Ulsberg and try to understand REST principles if you claim you’re using it.

Asbjørn Ulsberg - The REST And Then Some

Sad news came about Kevin Mitnick died last week. His life was filled with controversy. He was sentenced to change sides and became a security expert. Read more:

The Washington Post - Kevin Mitnick, hacker and fugitive turned security consultant, dies at 59

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.