Architecture Weekly #165 - 5th February 2024
Welcome to the new week!
Did you start your Event Sourcing journey but are unsure if it'll work on production? Or maybe you're there already and want to check how you can enhance it? I have something for you!
Domain-Driven Design Europe pre-conference workshop that I'll be giving this May. I plan to gather all my knowledge on this topic and synthesise it for you! I got it through my projects, working on Marten and EventStoreDB and helping others through my consultancy. It'll be an intensive but educational and fun experience (at least that's the goal!).
Check the details, and feel free to ask if you have any questions or concerns:
If you're still in the early phases, that's fine; I'm also doing closed workshops and consultancy. Check:
They should show how other folks liked it.
One of the reasons I included the DevOps and Process in the workshop's title is that I believe it’s essential to running software on production. Modelling and working on design are essential. We should not skip that, expecting design to emerge. Doing a healthy portion of design upfront is just cheaper, yet we should not forget to evaluate our assumptions and ideas. Building the right process and synergy between coding and operations is even more important. We also need to have the tools to do it.
The platform approach is pictured as the go-to solution for now. I have mixed feelings about it; too often, I see that core or ops teams rebranded to the platform team just weaponised with new tools. The platform approach can be really helpful in reducing the cognitive load, but it also doesn’t come with a price, and it’s not easy to achieve.
Charity Majors outlined the following pitfalls in her talk:
Running Too Much Software.
Writing Too Much Software.
Not Letting Product Teams Own Their Own Reliability.
Not Giving Engineers Enough Tooling to Understand Their Code as Well as Operate It
Being Confused About Who Your Customer Is.
Not Running Your Team Like a Product Team.
Not Paying Enough Attention to Cost and Spend as Part of Architecture and Planning
Not Constantly Looking for Ways to Deprecate, Delete, and Shed Responsibilities
Watch all in:
And I agree with all of that; I’d add to that Conway’s Law, which is inevitable. You cannot beat Conway’s Law like you cannot beat the gravity law. That’s also a topic of a great talk by Avraham Poupko:
Ok, but getting back to operations. There are things that are just not easy; one of them is multi-region support. If you do it wrongly, your costs will skyrocket, your latency will be terrible and your brain will hurt.
Alex Strachan wrote a nice overview of multi-region architectures:
Interestingly, his first point is the same as Charity Majors in her talk: “Know Your Customer”. I can second that, without knowing customers, it is extremely hard to define the data governance practices as: isolation, consistency and replication needs.
One of the important (but dangerous) tools to make such systems work and available is caching. Our systems need to work without it, but thanks to the proper caching strategy, we can enhance user experience and decrease the solution costs (of course, that can go both ways). A nice case study on it was presented by RevenueCat. Read more:
Once we have that, we must also take care of the proper communication strategy to make the data flow smoothly. Check the case study by Lastminute.com on how they design the RabbitMQ messaging strategy:
And if you’re searching for communication standards, CloudEvents just reached CNCF graduation. That means that it reached the final maturity level criteria. CloudEvents is a specification for the metadata/header for events. It was started by Microsoft and mostly adopted in Azure for now.
I’d consider it in the cross-module communication. For inner module communication, this may be overkill. Still, it’s worth taking inspiration and checking if it matches your needs. Although it’s still surprising for me why they’re CloudEvents instead of CloudMessages, well… Read more:
See also a nice material on pitfalls to avoid when building Event-Driven systems. It’s a nice set of advice around data governance:
Two weeks ago, I presented a great article by Ryan Shriver on his approach to Software Architecture Modernisation with DDD. Now, I’m even more than happy to say they took a step forward and published all of them as Miro board templates!
I think that’s a must-have thing to check and play with; I’m planning to do it soon. That’s also a great spirit of sharing knowledge with the community. Kudos to them!
Btw. it’s a good time to remind the C4 template by IcePanel in case you missed it:
Last but not least, Cloudflare shared its story on the last Thanksgiving Okta breach and its impact on Cloudflare. They wrote:
Even though we understand the operational impact of the incident to be extremely limited, we took this incident very seriously because a threat actor had used stolen credentials to get access to our Atlassian server and accessed some documentation and a limited amount of source code. Based on our collaboration with colleagues in the industry and government, we believe that this attack was performed by a nation state attacker with the goal of obtaining persistent and widespread access to Cloudflare’s global network.
Read the full coverage:
It was yet another issue caused by Okta. Cloudflare was infected, but they claim that it didn’t target their customers, listing more details.
Below are the Indications of Compromise (IOCs) that we saw from this threat actor. We are publishing them so that other organizations, and especially those that may have been impacted by the Okta breach, can search their logs to confirm the same threat actor did not access their systems.
Funnily, we still didn’t get even comparable threat analysis from Okta besides the blank statements. It's a terrible sign for a company that aims to care about security.
Check also other links!
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.