Chris Richardson

I'm moving away from Twitter/X. See chrisrichardson.net/about.html for details about where to find me.

Message brokers aren't designed to efficiently transport large messages: you should send a message containing a pointer/URL instead. Twitter is the same. Attempting to express a complex idea in a tweet is likely to fail. It's best to share a link to a longer post.

Avoid chains of synchronous calls in a microservice architecture : Self-contained service pattern bit.ly/2pyzHrt

Books about high-performance software delivery - DevOps Handbook + Team Topologies + Accelerate + Microservices Patterns bit.ly/2QSZqoi

Just remember: there is not such thing as a microservice. The microservice architecture is an architectural style that structures an application (a.k.a. system) as a set of loosely coupled services.

What's a (micro)service - part 1? bit.ly/2ScrFN9

The essence of applying the Microservice architecture pattern is defining the service architecture: identifying the services, defining their responsibilities, their APIs and their collaborations (with other services).

Periodic reminder: Just because they are called MICROservices it does not mean that you should define lots of little services.

There are many definitions of DevOps but my primary resource is the DevOps Handbook by @jezhumble @RealGeneKim @botchagalupe @patrickdebois bit.ly/2QSZqoi

Managing data consistency in a microservice architecture using Sagas part 2 - coordinating sagas using choreography or orchestration bit.ly/2KiOb6F

Just a reminder: picking the appropriate architecture for your application is a best practice. microservices.io/patterns/index… changelog.com/posts/monolith…

Monolith First is generally good advice. But it's not universally applicable. Sometimes it might make sense to start with microservices. To understand why, let's analyze the trade-offs using dark energy and dark matter.

One of the defining characteristics of the microservice architecture is that services are independently deployable. But there's more to this definition than simply packaging a service as a WAR or executable JAR that can be built and deployed independently of other services.

One of the most interesting things I've read this year was the research paper by @AdamTornhill that described how organizations waste up to 42% of their time due to technical debt. It's extremely valuable to see a study that quantified the consequences of technical debt.

The core idea of the success triangle is that the rapid, frequent, reliable and sustainable delivery of software requires three elements: DevOps, Team Topologies, and an architecture that enables them.

I'd propose no-prefix services: no microservice, no macro, no mini. Just a service. microservices.io/patterns/decom…

One of my favorite presentations is my #QConPlus 2021: talk: Takeout burritos and minimizing design-time coupling in a microservice architecture. Creating the presentation was challenging. I felt hungry whenever I looked at the pictures, especially in the AM.

Documenting a service using the microservice canvas bit.ly/2tIa06m

Oh dear: According to Gartner 70% of the IT market is focusing on DevOps and another study found that 88% of organizations have adopted agile, but only 26% of organizations have broadly adopted test automation.

Key lessons: 1. Be very, very careful when using shared libraries that contains 'unstable business rules' in a microservice architecture. 2. More generally ensure your services encapsulate change rather than having changes regularly impact multiple services 1/n

Microservice architecture adoption anti-pattern - Microservices as the goal bit.ly/2Db1jqG