Architecture Weekly #126 - 8th May 2023
Welcome to the new week!
I’m writing to you from sunny Athens; I was talking last week at Devoxx Greece. I was joking that the organisers intentionally selected my talk as one of the closing sessions to mildly give a hint that it’s fine to go home. Why?
GDPR is not a sexy thing for us, devs. We like to have clean code, but clean data, not so much. Data governance practices are boring us. And that’s a big mistake and one of the reasons why our approach to privacy had to be regulated.
With Event Sourcing, it gets even funnier, as people commonly believe that we cannot delete any data. So applying GDPR sounds impossible. Yet, there are always strategies to deal with that, and that’s what I explained during my talk.
As you probably were not there, I gathered some notes/resources after my talk and the recording of my webinar with the previous version of this talk. Grab it here: https://event-driven.io/en/gdpr/.
Some claim that changing the database in the project is a myth. Maybe it was some years ago, but now, it's happening much more often.
Emerging cloud providers and managed services made running more "exotic" solutions more accessible. And that's great, as we can select a data model that best fits our business use case.
I wrote yesterday about the General strategy for migrating relational data to document-based.
What would you add to that?
The loudest news this week was brought by an Amazon Prime article:
Of course, the noise was made by well-known drama initiators and their terrible takes. It’s quite funny and intriguing that this well-described and justified created such noise that the event AWS CTO had to speak up:
Monolith, Microservices, and Serverless are architecture styles that can be used correctly and wrongly. What’s more, they can be used together, so we can have some parts of the system that require cutting latency on communication etc., as a monolith, but others used less often as serverless.
Moreover, different phases of a project may require different architectural styles. When we’re bootstrapping and don’t have a stable income stream, we may want to select the serverless approach to quickly iterate and reduce the costs by paying for used resources instead of reserving more that we need to want to spend.
We may change our decisions when we learn more about our domain and tech stack. Learning the usage characteristics gives us a chance for proper optimisation and resource utilisation.
We make the most important decisions when we’re the most stupid. That’s why it’s important to do proper risk management. We’re too often too afraid of our decisions. We should optimise for an evolutionary approach.
And that’s precisely what the Amazon Prime team did. They didn’t even switch to the monolith; they just grouped some serverless functions into the single deployment unit (container).
It’s a great case study on making and revising decisions, not the microservices vs monoliths. So you can hide your forks if you have them already in your hands.
Read also my article in which I explain How (not) to cut microservices.
The other important topic is leaked information from Google about their current market situation. They’re saying that their castle has no moat…
…and neither does OpenAI.
That’s interesting, as they seem to realise that closed models will always be better than open models. So that they (together with Open AI) may create the market but don’t benefit from it.
The financial results of Open AI seem to confirm that:
Open AI did a cowboy product release, ignoring all the privacy aspects; Google followed that approach by not having an answer and narrative to beat the created buzz. They have already lost some of the biggest talents:
Even usually toned MIT wrote that OpenAI’s hunger for data is coming back to bite it. Both Google and Microsoft seem to be trying to run as fast as they can, hoping they won’t hit the wall in the end. Still, Google seems to be cautious and afraid of the potential hard ending.
Fun times!
I must mention privacy again, as Wired did great journalism getting back to the famous Solar Winds breach.
It’s a must-read, as it’s a thorough follow-up checking the investigation stage. Rarely do journalists do that. Usually, they make noise and never get back to it.
I’m also curious if our industry has learned anything from this case. I’m afraid that we did not.
Learning from past mistakes is also a basis for refactoring. Planning to do one? See those two resources to get you started:
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
The Jim Rutt Show - Dave Snowden on Managing Complexity in Times of Crisis
Michelle Ufford - Whoops, the numbers are wrong! Scaling data quality @ Netflix
Sara Pellegrini, Milan Savić - The aggregate is dead. Long live the aggregate!
DevOps
Databases
Oskar Dudycz - General strategy for migrating relational data to document-based
S. Sarkar, N. Dayan, M. Athanassoulis - The LSM Design Space and its Read Optimizations
Frontend
Linux
.NET
Jeremy D. Miller - Twisting PostgreSQL into a Document Db and Event Store
Microsoft - ASP.NET Core Route Tooling Enhancements in .NET 8
Node.js
Tools
Coding Life
Management
Security
Industry
Dylan Patel - Google "We Have No Moat, And Neither Does OpenAI"
Yahoo - OpenAI Is Losing a Flabbergasting Amount of Money on ChatGPT
ArsTechnica - Warning of AI’s danger, pioneer Geoffrey Hinton quits Google to speak freely