IT Architecture : All your micro-services are wrong PERIOD! by Dwight Matthys

Discover the counterintuitive truth about microservices: they're not always the solution. Explore the benefits and pitfalls of monoliths, bounded contexts, and considering the whole system in this thought-provoking talk.

Key takeaways
  • Microservices are not always the right solution, and sometimes monoliths are better.
  • Process boundaries and data should be consistent and together, not separated.
  • Many organizations mistakenly separate process and data, leading to complexity and inconsistencies.
  • Bounded contexts and business capabilities are crucial to understanding true autonomy.
  • Error handling and testing are important but often neglected in microservices architecture.
  • Developing microservices without considering the whole system can lead to chaos and failure.
  • Even with microservices, you still need to think about error handling, testing, and debugging.
  • Sometimes it’s better to have a smaller monolith than multiple microservices that don’t communicate well.
  • The industry’s push to microservices may have been driven by a false promise of flexibility and scalability.
  • There is no single “right” way to design a system, and each situation requires its own approach.
  • Don’t just blindly adopt a technology or architecture without considering its true implications.
  • Processes should be designed to work together, not separated and controlled by different teams.
  • Technical implementation is not enough; you need to consider the human and business aspects of a system as well.