Architecture Weekly #187 - 8th July 2024
Welcome to the new week!
Let’s start with: Thank you! Thank you for being an active reader and member of the Architecture Weekly community. We just passed the 6000 subscribers milestone and over 150 paid community members. That’s a lot!
I’m happy about it, as preparing Architecture Weekly every week takes a lot of effort and energy. Just grouping and summarising the read content is a day of work. Not even speaking about research, reading time etc.
I'd like to reevaluate the current format. I'd like to make it more engaging for you and sustainable for me.
I'd be grateful if you could spend a short time passing me your feedback. As a gratitude, after filling out the survey, I'll pass you the link for a paid subscription month trial.
Thanks to that, you'll get access to all recordings of past webinars (see them all here).
I’ve been running this newsletter for 187 editions in a row, even during Christmas and other times. However, for the next two weeks, I’m planning to take time off. It should give me some space to recharge and regroup. But don’t worry; I’ll be back on the 29th with the 188th edition! I hope that it’ll also give you the time to catch up with the past editions and materials that are there, or best, get some rest and recharge with your family and friends! We should not follow Ebenezer Scrooge's example.
Last Friday, I decided to have some fun and do something new and creative.
I gave a practical answer to the question: Consistency or Flexibility? And the answer was: Why not both?
Wouldn’t having MongoDB's flexible schema and PostgreSQL consistency be great? MongoDB is a decent database, but it can cause headaches with its eventual consistency handling. I have written about this on my blog a few times in the past.
Don’t get me wrong, eventual consistency is fine. We need to learn to live with that, still… Undeniably, having strong consistency, read your own writes guarantees, transactions is great. Especially for business logic.
What’s Pongo?
It’s a MongoDB-compliant wrapper on top of Postgres. You call mongo-like API and get strong consistency from PostgreSQL! All of that is in TypeScript and Node.js, see:
Sounds familiar? Yet, it’s a similar concept to Marten or, more correctly, to AWS DocumentDB (see here or there, they seem to be using Mongo syntactic sugar on top of AuroraDB with Postgres).
What’s interesting is that I got to the HackerNews front page with Pongo. And what’s even cooler is that the feedback was mostly positive! Not too bad for a few days old project!
Check also an interesting case study on the topic of moving from MongoDB to PostgreSQL:
Changing direction and technical strategy is difficult (thank you, Cpt. Obvious!) We already had a loud discussion on the AWS Prime Video article. They explained why and how they moved from serverless towards a more monolithic approach (although still distributed).
Some were saying that Serverless is dead. For me, it was a great study on how to enable and switch strategies as you gain more insights into the business domain and usage characteristics. It’s good to pivot, regroup, and adjust—that’s being agile and flexible.
So, is serverless dead? It’s not. It’s mature. We already know the good, the bad, and the ugly parts of that.
Today, I’m bringing you a few great case studies on how, when and why to move towards serverless. I like that they are nuanced and not black and white. Read more:
Sindhu Pillai, Gregor Hohpe - Refactoring to Serverless: From Application to Automation
Yan Cui - I’m sorry, but the way you adopt serverless is wrong
Sheen Brisals - The Set Piece Strategy: Tackling Complexity in Serverless Applications
Should we serverless all the things? No. Should we monolith all the things? Also, no, the same for microservices. It’s best to find the drivers based on your use case. Check also a nice story from the engineer working with microservices and still enjoying it:
Staying with the change, Google moved their Google Sheets engine calculations from JavaScript to WebAssembly. Is it a year of WebAssembly on the desktop? Not yet, but it’s also getting its path for valid use cases like the one Google explained. Read more:
If you have enough of positive takes, then check the following:
I do not fully agree that OpenTelemetry is a flop, but I agree that we should have a better discussion on how to tackle it and the expected use cases. I agree that we still have vendor issue that are trying to push their vision and overselling OpenTelemetry.
Yet, I believe that we’d be in a much worse phase if we didn’t have such agreement between them. I think that’s a positive story and rare in our industry to get such wide standard. Still, it’s good that we have finally the voices beyond the hype train. That means that OpenTelemetry is getting back the production usage experience and lessons learned. I’m sure we’ll see more of that soon.
If I don’t agree that OpenTelemetry is a flop, then I predict that Generative AI will be such. And I have some backing for that claim.
Goldman Sachs and Sequoia send their reports on the AI:
Both reports are not negative, but you can read between the lines that they’re sceptical of the overall success of Generative AI.
GS Head of Global Equity Research Jim Covello goes a step further, arguing that to earn an adequate return on the ~$1tn estimated cost of developing and running AI technology, it must be able to solve complex problems, which, he says, it isn’t built to do. He points out that truly life-changing inventions like the internet enabled low-cost solutions to disrupt high-cost solutions even in its infancy, unlike costly AI tech today. And he’s skeptical that AI’s costs will ever decline enough to make automating a large share of tasks affordable given the high starting point as well as the complexity of building critical inputs—like GPU chips—which may prevent competition. He’s also doubtful that AI will boost the valuation of companies that use the tech, as any efficiency gains would likely be competed away, and the path to actually boosting revenues is unclear, in his view. And he questions whether models trained on historical data will ever be able to replicate humans’ most valuable capabilities.
Some are more optimistic, but predictions are still positive on the growth but negative on the big growth. So, keeping in mind the amount of money invested, we can conclude that what we see now is a bubble. This can grow into a proper business model, but it will require to find it, as what we have now is not such yet.
See also:
Yeah… I think that Generative AI will stay with us but in a different shape than we expect now. And probably, LLMs will be just a first wave. We’ll see if also the last one.
And two summer links to end it with a smile.
Last week, I wrote about proper regex usage. This time, I have something better for you: Regex crossword! If you solve it, don’t forget to pass me that news!
LLMS, BitCoins and all that jazz. Cool, but the reality is that Japan finally got rid of floppies!
Check also other links. Don’t forget to fill out a survey:
It’ll be short, I promise!
See you on the 29th!
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
Michał Kosmulski - Ten Years and Counting: My Affair with Microservices
Google web.dev blog - Why Google Sheets ported its calculation worker from JavaScript to WasmGC
Sindhu Pillai, Gregor Hohpe - Refactoring to Serverless: From Application to Automation
Yan Cui - I’m sorry, but the way you adopt serverless is wrong
Sheen Brisals - The Set Piece Strategy: Tackling Complexity in Serverless Applications
Matt Wynne - The Iceberg Model: towards unraveling our patriarchal legacy
Databases
Testing
.NET
Oren Eini - Cloned Dictionary vs. Immutable Dictionary vs. Frozen Dictionary in high traffic systems
NDepend Blog - Readonly, Immutable, and Frozen Collections in .NET
Andrew Lock - Exploring the generated code: List and fallback cases