System design: Microservice - 10 Tips for failing badly at Microservices by David Schmitz

Here is the link. 

Microservices are just a bunch hip new framework plus some AngularJS frontend or React, right? So, if you want to make sure that you absolutely and definitely fail at your Microservice project, then watch this talk and learn how. Using real world experience from multiple green field and brown field projects, I can show you: - how to ignore the mandatory organizational impact - how to focus on the code only without any regard towards ops and testing - continuous deployment is for losers. Real projects use their meat cloud for delivery - jumping onto every new and untested framework is a must - Event Sourcing and CQRS are both free lunches. So, you can add complexity without any real need - ...and more If you mind my tips, then surely you will fail at Microservices and your boss will never again try to move away from your beloved vintage monolith. David Schmitz Pricinpal architect at Senacor Technologies with a history of + 13 years of working in various projects using a bunch of different stacks and environments. Current focus is on migrating architectures and organizations, such that our customers can cope with the challenges of the digital age.

10) Tooling - Prefer one well-established tech stack. Too many tools often result in unintended complexity across the board.

9) Data Ownership - Prefer separate databases or schemas for each micro-service to keep clear table ownership. 8) Event Sourcing - Research whether you actually need it and design carefully. 7) Coupling - Beware dependency versions and shared libraries (especially in-house ones). Microservices are often more coupled than we realize. 6) Automation - Use CI/CD and automate your processes. Keep in mind that everything "hand-crafted" complicates your infrastructure. 5) Failure - Design for failure. It's a distributed, networked environment. And, again, avoid making a highly coupled microservice monolith monstrosity that fails simultaneously . 4) FE Responsibilities - Have clear responsibilities. Associate certain frontend pages with certain APIs so that you know what microservice is responsible when something fails. 3) Tooling - Having a few well-defined tools is a virtue; but, remain open to clearly better tools. Let teams use what works best on their project. 2) Design - Model your services around the company's domain and make sure management is aware of the high-level architecture. 1) Communication - Communication between teams is a must. Have someone that understands how everything works together and what different teams are responsible for.