Software Architecture: thoughts and quotes

Collection of “thoughts” and quotes I’ve found interesting about Software Architecture, collected from videos or articles.

I’m using a pretty “loose” definition of “Software Architecture” on this collection, so it has a bit of everything. If the content grows, I might consider splitting it up.

On Microservices

Avoiding Microservice Megadisasters by Jimmy Bogard talks about how on a Microservice Architecture, when you do a service call, the service should be able to answer your request without the need of an additional service call of its own.

It also talks about the assumption that replicating data is wrong. It gives an example on how data replication allowed to get rid of service calls inside a service meant to provide search functionalities.

Conversations by Ian Cooper talks about how services “converse” amongst each other to fulfill a request. It goes through the main distinction between “Choreography” and “Orchestration”:

• On “Chreography” each service knows what to do as response to events.
• On “Orchestration” there is an “orchestrator” leading the flow.

Further reading: Avoiding the Entity Service by Michael Nygard.

On Deployments

Choosing The Right Deployment Strategy¹ by Viktor Farcic concludes with the following recommendations:

• Choose the “Recreate” strategy when working with legacy applications that are stateful without replication.
• Choose the “Rolling update” strategy with cloud-native applications which cannot use canary deployments.
• Choose the “Canary” strategy when you need the additional control when to roll forward and when to roll back.
• Choose the “Serverless” strategy when you need excellent scaling capabilities or when the application is not in constant use.

On Observability

Cultivating Production Excellence by Liz Fong-Jones talks about key elements to achieve production excellence:

• Know when our systems are too broken: systems are always failing, we need to define what’s acceptable through good SLOs.
• Be able to debug our systems: support debugging our systems in production through good observability.
• Cross-team collaboration: work with other teams, rotate the on-call, share knowledge through documentation.
• Eliminate (unnecessary) complexity: address risks that threathen the SLO.

A nice quote around observability I liked was: “Our services must be observable. Our systems have to be able to explain themselves to us and answer our questions using the telemetry they’re already exporting, rather than us having to create new code in order to understand our services”.