microservices pattern language – live blogging from spring days

Microservice s Pattern Language
Speaker: Chris Richardson – @crichardson
See list of all blog posts from conference

Modern software development:moving fast and not breaking things!
Do this with DevOps, Continuous Deployment/Delivery and small autonomous teams


  • Not an anti-pattern because it makes sense at one point
  • Can deploy frequently at the beginning
  • Then it grows. Quickly
  • Then ball of mud
  • Get stuck with obsolete tech stack that used when started project


  • Architectural styles
  • set of services
  • loosely coupled
  • organized around business capabilities
  • tackle complexity through modularization
  • Improved scalability is secondary (“monoliths can scale quite well”)
  • Each service has own private data store/schema (doesn’t need own database)


  • Once agree on APIs cn develop with less communication and integration
  • Easier to understand develop/test
  • Less potential for jar hell
  • Start up time faster which imporves MTTR (mean time to recover)
  • Know who owns each service – with monolith, everyone is responsible so nobody really is
  • Can fail safely with new technology because only affects one service

Downside – Complexity

  • Now have messaging/remote calls
  • Deal with timeouts and partial failures – circuit breaker pattern
  • Multiple databases and transaction management – need series of local transactions
  • Queries more complicated – can’t just join with SQL. Need to call multiple APIs or replicate data
  • Need a lot of automation; a lot of production applications /services
  • New feature needs multiple services to be deployed in right order

Your monolith will grow forever and never get better. Automation makes microservices better. But need some automation as pre-req for successful microservices

Pattern language

  • To solve architectural problems
  • See patterns on microservices.io
  • Chris writing a book on the topic – currently available through Manning Early Access Program (MEAP)
  • Example of a pattern for dealing with querying data from multiple sources: CQRS – command query responsibility segregation – see CQRS pattern on web
  • Chris is still creating new patterns so remember to check back on the site

Overall, I like that more of the presentation was about microservices than the patterns themselves. It shows why this is important and gives the background to read the patterns. I like the patterns he chose to show.

Leave a Reply

Your email address will not be published.