Architecture Weekly #177 - 29nd April 2024
Architecture Weekly #177 - 29nd April 2024
Welcome to the new week!
The time is running out, but a few spaces are still left! This May is a decent month to learn event sourcing and event-driven architecture through workshops, but why May?
I’ll be giving pre-conference workshops on my favourite conferences:
Techorama - 6th of May - Practical Introduction to Event Sourcing,
DDD Europe - 27th-29th of May - Production-Grade Event Sourcing: Modelling, DevOps, Process.
I aim to provide you with collaborative workshops where you can gain certainty if what you designed for prod will work and you won't have nasty surprises. The Techorama one should get you up to speed and help you understand foundations. The DDD Europe one will be an intensive three-day workshop, but I think we'll have fun. I want to pass you a condensed dose of experience I gathered throughout my career. It’s also a rare chance, as I’m not giving public workshops often.
Also, I decided to give each attendee a half-year subscription to Architecture Weekly. If you join, you'll get access to over 20 hours of recordings, which should be a decent follow-up. See the full list of them.
Feel free to ask if you have any questions or concerns about those workshops. I’m happy to answer and clarify! You can also check the recommendations from attendees of my past workshops.
Testcontainers became a popular way of setting up dependencies for integration testing. They're not ideal, as configuring them to run your tests efficiently is not as trivial as it's glossed; I explained that in "A simple way to configure the integration tests pipeline". Still, undeniably, it can speed up the initial ramp-up phase and, if used wisely, can be a decent way to handle common testing dependencies.
Testcontainers already provide the default configurations for tools like PostgreSQL, Kafka, MongoDB, etc. Yet sometimes, you need to use something a bit less mainstream, such as Event Store, as your event store. How do you do it?
I explained that in my latest article:
Four weeks ago, we discussed the license change in Redis that triggered the creation of a fork called Valkey and a compatible clone called Garnet. We also discussed a similar issue with Terraform and OpenTofu a few times, even two weeks ago. Today, we got some new context to it:
Yeah, IBM just bought HashiCorp. Now, the question is if the license change was part of doing due diligence before the merge. And if leaving the company by creator Mitchell Hashimoto was related or if the merger was a consequence of that.
Yet, let’s drop that part and look more broadly at the cases where we’re trying to build an alternative solution by using the existing environment but reshaping the common conventions.
Another example of it can be the new TypeScript framework called Effect TS:
It tries to bring the functional model to the TypeScript world. So, there are no exceptions but results, no side-effects, composition, etc. It’s not that revolutionary, as React already provided some of that on Frontend and kinda succeeding by changing the landscape and the way people code in JavaScript and TypeScript. Will that be the case for the Effect TS?
The article by Maxime Chevalier can be a good addition to those discussions:
She wrote:
(...) What I’ve concluded, based on experience, is that positioning your project as an alternative implementation of something is a losing proposition. It doesn’t matter how smart you are. It doesn’t matter how hard you work. The problem is, when you build an alternative implementation, you’ve made yourself subject to the whims of the canonical implementation. They have control over the direction of the project, and all you can do is try to keep up. In the case of JITted implementations of traditionally interpreted languages, there’s a bit of a weird dynamic, because it’s much faster to implement new features in an interpreter. The implementers of the canonical implementation may see you as competition they are trying to outrun. You may be stuck trying to ice skate uphill. (...)
And that’s also my prediction. You’re either strong enough to impact the whole environment and reshape how people do stuff, or you’ll lose.
The chances of Valkey and Garnet being Redis replacements are pretty high. The solution is stable, and the standardisation is being built around the open fork. Big vendors have already invested a lot in having Redis as their cloud solution.
For OpenTofu, the situation is still uncertain. HashiCorp still has patents; they can shape the narrative. Getting IBM into the game, in my opinion, doesn’t change the picture, as the most important if big cloud providers will feel the benefit of having Terraform as their standards, and for now, they don’t seem to be interested, as they invest a lot with their own Infrastructure as Code tools like AWS CloudFormation, AWS CDK, Microsoft Bicep, etc.
Going back to the Effect TS, they either need to go the React way, which will impact how applications are being built, or be a niche project. My bet is that the latter will happen.
The same can be said for hybrid development, where you're using the Strangler Fig pattern. If your legacy is still developed and you're building a "hybrid" solution, then you need to be quick to strangle the old implementation, or it will strangle the new one.
And I think those considerations are an example of how we should analyse and look for both micro and macro trends in the tech community to make better decisions on our systems design.
Last week, I wrote about Google workers being arrested and then fired for protesting against Google’s military contract. I believe that “No politics in work” is usually a sign of the bigger issues and rotting company culture. Of course, when we’re working, we should focus on our job, but in the end, we’re humans and spend most of our daytime at work. It’s unavoidable that social stuff will impact our work. Good organisations can balance that. And if they can’t then such policies are a usual sign that they are also not doing great in other places, a panic mode.
Daniel D. McKinnon interestingly compared the Product Management between Meta and Google:
The summary is:
Meta and Google are both phenomenal technology companies where great PMs can thrive. If you are looking for convexity and growth at the expense of stress and pressure, Meta is probably a better fit. If you would like to prioritize work-life balance, stability, and job security, Google could be a great place for you.
The article is filled with interesting insights like:
When I pitched a new project to a Google VP, he responded, “This is great, but I want you to remember that our number-one goal is supporting our existing search business. I would rather do nothing than risk harming that.” This interaction encapsulates how Google thinks about change, which is likely correct from the perspective of Google shareholders but potentially not appealing to prospective product managers.
Interestingly, there’s hot news on HackerNews that Google fired their Python team:
Is it a sign of doing nothing rather than risking? Or a next sign of the panic mode button?
Check also the talk by Dan North on how to bake a change:
And a short article from Jared Turner on why we should limit the Work in Progress:
Last but not least, check the insightful article on the contrarian view on the-latest-the-greatest security tool: passkeys:
As always, we cannot have only good things. There’s no free lunch.
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
DevOps
Databases
Testing
Frontend
Azure
Java
.NET
Jimmy Bogard - Tales from the .NET Migration Trenches - Authentication
Aaron Stannard - Akka.NET, ASP.NET Core, Hosted Services, and Dependency Injection
Patrick Smacchia - Will Visual Studio Be Migrated to .NET Core and Become Multi-Platform?