View this email in your browser

Dear Architect,

Welcome back to our weekly issue!

This week we have in our spotlight an article on sacrificial architecture. This type of architecture might have a purpose when built but you quickly realise that is not sustainable for the long term, however in the meanwhile you gained enough domain knowledge for rebuilding the project in a better and more suitable way.

As architects we should be aware of how the organisation structure impacts our designs, Organise for Complexity is not a tech book but it has many great insights for understanding how to deal with complexity. A bestseller that is useful to learn how to scale an organisation decentralising decision making for achieving your business goals.

We then have two articles on distributed systems design patterns such as Saga and Strangler patterns. Both patterns are extremely helpful when we deal, or we aim to microservices architecture.

Finally, a case study about how GitLab and Gemnasium teams re-architected their systems after Gemnasium acquisition. I like these kinds of articles where the thought process enhanced the narrative.

Enjoy the read and see you next week!


Software Architecture

Sacrificial architecture: Learning from abandoned systems

Being a software architect is all about balance, about the tradeoffs between different features, technologies, and patterns. One of the tough decisions you and your team may face as you scale is deciding between keeping your current codebase and rebuilding on a new architecture. 
Organization structure

Organize for Complexity

Don’t we all ask ourselves questions like:
How can my organization deal with growing complexity?
How can we become more capable of adapting to new circumstances?
How can we overcome existing barriers to performance, innovation and growth?

Design Patterns

Saga Orchestration for Microservices Using the Outbox Pattern

When moving to microservices, one of the first things to realize is that individual services don’t exist in isolation. While the goal is to create loosely coupled, independent services with as little interaction as possible, chances are high that one service needs a particular data set owned by another service, or that multiple services need to act in concert to achieve a consistent outcome of an operation in the domain of our business.

Design Patterns

The Strangler Fig Migration Pattern

Almost all the successful microservice stories have started with a monolith that grew too big and was broken up.
Almost all the cases I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
Case Study

The process: Rearchitecting after acquisition

When one software company is acquired by another, it’s a safe (if not guaranteed) bet that the acquired business will be incorporated into its new parent company in some way. But what many don’t consider is that the acquired company’s source code may also have to be rebuilt to some degree. When GitLab acquired my former company, Gemnasium, in January 2018, we faced precisely this task.

Thanks for reading Dear Architects 🙏

If you have any suggestions to make this newsletter better, just drop us an email!

Have a great rest of the week 😉

Opinions are my own

We just need a few minutes of your time to make Dear Architects even better
Sure! Let me share what I think about Dear Architects!
Copyright © 2021 deararchitects, All rights reserved.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp