Architecture Weekly #175 - 15th April 2024
Oskar Dudycz
Software Architect & Consultant / Helping fellow humans build Event-Driven systems
Welcome to the new week with the latest #ArchitectureWeekly !
If you’re looking for a lightweight intro to Event Sourcing, check last week’s discussion with Maciej 'MJ' Jedrzejewski . On his podcast, we discussed the foundational stuff, busted some common myths and explained the facts. Watch it here:
Using an In-Memory message bus can be overkill, especially for command handling where we have only a single entry point (e.g. API endpoint). In such cases, I suggest having just explicit application code in the endpoint. That gives a proper developer experience. As you understand your dependencies, you can go to the definition of business logic. A command bus requires much more jumping around the codebase as you hide all dependencies and handling details.
If I have more than one entry point, e.g., event (as it always can/should have more than one recipient) or command that may come from messaging tooling and API, then the message bus is useful, as it allows me to build common middleware.
The downside of the message bus is that it can create another level of indirection, making it hard to understand where the handler is, what the impact of the change is, etc. Also, it doesn't give proper delivery guarantees unless we wrap the whole process in transactions, which can cause deadlocks and other types of complexity.
That's why I'm not using it everywhere, but where I need it. I evolved from the message bus all the things. But it still can be useful, especially for event publishing, where, by nature, you don't want to know how it'll be handled as an event producer.
Still, in-memory buses, if used wisely, it's a must-have in our systems, even as part of our infrastructure layer. I wrote how to build a simple one and also had some fun with TypeScript.
If you also want more Event-Driven (anti)patterns, check out this nice article from Barry O’Sullivan. He discusses in details how granular our events should be and how to find the sweet spot between completeness and focus on the process:
Let’s leave the event-driven world and focus on the two stories. The first is from Adele Goldberg on her thoughts about the legacy of the Smalltalk language and how it impacted our design.
The first article is a celebration of Smalltalk's 50th anniversary. Adele Goldberg helped create it alongside Alan Kay and Dan Ingalls at Xerox PARC. Smalltalk was a pioneer in object-oriented programming and graphical user interfaces, which are now common in software development. Goldberg discusses the original purpose of Smalltalk: to make a flexible, easy-to-use environment that could help users, especially beginners, understand and shape their world through programming. This environment was revolutionary because it allowed programmers to make changes and fix bugs while the program was running, a method now fundamental in software development.
Smalltalk's integrated development environment and its approach to programming, focusing on objects and message sending, influenced many modern programming languages and tools. Alan Key’s vision is not shown as the basis for the Actor Model and messaging. That was closer to his original intention behind “Object-Oriented Programming.” Also, Eric Evans, inventor of the Domain Driven Design, came from the Smalltalk community.
Goldberg explains nicely how Smalltalk's design greatly impacted developers' thinking about user interaction, program structure, and code readability—key aspects of modern software practices. Even though Smalltalk was beaten by other languages like C# and Java, it’s undeniable how much impact it made.
The other is about Harp McGovern and her story of building a microcomputer empire.
Lore Harp McGovern co-founded Vector Graphic from her home in California, turning it into a significant player in the early microcomputer market. She and her partner Carole Ely began making memory boards for the Altair 8800, quickly moving to produce their computers as business demands grew. This strategic shift allowed them to capture the burgeoning market of small and medium businesses that needed reliable computers for tasks like accounting and data management.
Vector Graphic succeeded by adapting to the fast-changing tech landscape, which demanded quick responses to new technological challenges and market needs. Harp McGovern recognized early the importance of transitioning to products that lead to more sophisticated business applications. Still, the entry of major companies like IBM with their own PC created a new competition threat.
Despite these challenges, Vector Graphic was able to keep up with the competition for some time. Harp McGovern also pioneered inclusive employee benefits and stock options, that are popular nowadays.
领英推荐
Lore Harp McGovern's role in founding Vector Graphic highlights a key time in tech history when the industry was just starting to take shape. She turned a small startup into a major player in the microcomputer market, breaking ground as one of the few female CEOs to take a company public in Silicon Valley. Her story shows women's challenges in getting recognized in tech, often overshadowed by their male counterparts.
It might be that history is written by winners, and IBM eventually won. Vector Graphic stuck too long with the CP/M operating system before switching to MS-DOS, which had become the industry standard partly because of its adoption by IBM. This delayed response to market shifts added to Vector’s struggles. That lead to the eventual bankruptcy.
It’s good to look back and analyse the history of the industry and how technologies and products compete. That’s a decent addition to our daily work and broader analysis. For that, check also the article from another pioneer:
And about the women's impact on the industry, see:
Interesting news came from the US federal court. They ruled that AWS must pay up to $525 million in damages to technology company Kove for infringing cloud storage patents.
If you didn't know Kove before, no worries, I also didn’t. Yet it seems that they claim that their solutions for scaling storage impacted the major cloud providers on some ground. Interesting is that it took 6 years to get the final verdict. Well, it's almost final, as AWS plans to battle for not paying it. Kove also sued Google a year ago for similar things. Fun times.
Speaking about storage, PostgreSQL announced that they support .NET natively. This means that you can use C# and F# to write stored procedures in PostgreSQL (I hope that at least not Visual Basic…).
To be honest, I’m skeptical about putting such a thing in PostgreSQL. To say mildly, I used .NET in MSSQL, which wasn’t a pleasure. Still, adding .NET to MSSQL strengthened .NET, as they found number of bugs because the environment was so different. I see that as some niche thing, I’d be much more keep to run WASM inside.
Getting back from the history lessons. When I started, giving you a VM with a preconfigured dev environment was popular. You couldn’t code unless you were using it. I hated it. Now, history repeats itself with cloud development environments. Discord wrote a follow-up on their journey.
Discord's move to cloud-based development environments using Coder shows a wider trend in tech towards centralized and standardized development processes. As companies grow, managing different development environments and keeping them consistent becomes really tough. Cloud environments help fix these issues by putting resources and settings in one place for all developers, no matter where they are.
When I see that, it makes me think that we have reached the phase when we again are not able to deal with the complexities of the configuration of our systems. So we try to centralise the knowledge; even around local development environment setup.
We’ve been there. In theory it may be a solution for the cause, if configured wisely it could cut the costs of hardware, but I think that the root cause is somewhere else. That our development practices and tooling are not accessible enough.
Check also all links at: https://www.architecture-weekly.com/p/architecture-weekly-175-15th-april
Cheers!
Oskar
Exited founder turned CEO-coach | Helping founders scale their companies without sacrificing themselves.
7 个月Sounds like a fascinating journey through tech history. So much to learn.