Avoid the microservice fallacy

put your domain back into the mighty monolith

Transcript

1. Avoid the microservice fallacy put your domain back into the mighty monolith
2. Please support our sponsors #dddbne
3. Fill out your feedback • To go into the draw for prizes, please remember to complete your feedback at: • http://www.dddbrisbane.com/fee dback • No feedback = No Prizes! #dddbne
4. Avoid the microservice fallacy put your domain back into the mighty monolith
5. Avoid the microservice fallacy put your domain back into the mighty majestic monolith
6. Hi, I’m Jakob • Danish immigrant • Father of 3 • Brewer • Rookie surfer • Pragmatist • Curious kind-a-guy • Consultant at Readify • @hgaard • https://blog.hgaard.dk
7. Why are we here? • You have a feeling microservices might be a bit hyped and you are curious and want to hear more • You think microservices are awesome and should be used everywhere (and you are here to heckle)
8. What are microservices “Service-Oriented Architecture (SOA) is a very broad term and practically meaningless. Microservices is a subset of SOA with the value being that it allows us to put a label on this useful subset of SOA terminology” Martin Fowler
9. What are microservices “Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services should be fine-grained and the protocols should be lightweight” Wikipedia
10. Microservice promises • Forces you to improve modularity • Enables parallelized development • Scales on a module level • Improves time to delivery • Makes you get your product to market faster
12. All we need to do then is to... “sprinkle a bit of DevOps on top”
15. Over-emphasizing benefits • Microservices are distributed computing • Distributed computing is hard • 1st rule of distributed computing
16. Fallacies of distributed computing • The network is reliable • Latency is zero • Bandwidth is infinite • The network is secure • Topology doesn't change • There is one administrator • Transport cost is zero • The network is homogeneous
17. The microservice premium • Fault tolerance • Dealing with eventual consistency • Multiple deployment pipelines • Elaborate monitoring
18. Docker will solve this for us • Yes • It lowers the operational cost of running microservices • But • It does not solve fault tolerance or eventual consistency
19. “If you can't build a Monolith, what makes you think you can build distributed microservices” Simon Brown
20. • You are not Google, Facebook or Netflix • Don't solve their problems • Chances are that you will never gain the benefits of microservices
21. What are you trying to solve? • Scaling vs availability • Breaking system into (the right) components • Independent deployment • Test components independently • It fits your existing organizational silos
22. Apply a broader perspective • The DRY obsession • This leads to premature generalization
25. “Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.” Alan Perlis
26. We are a hype industry "The hype is driving people to lose focus of what really matters: Customer.” Duncan Bradford
27. We are problem solvers
28. Put your domain back into the Majestic Monolith
29. Monolith or microservice first • Fowler vs Tilkov • Think hard about the costs related to operating a microservice environment • Microservices might enable you to move faster
31. The Majestic Monolith • An integrated system that collapses as many unnecessary conceptual models as possible • Encourages the campsite rule • Create a culture that reflects that • Run small teams
32. Brown field projects • Safest decision you can make is to solve the business problem first • Your system will never be done • Refactor to Monolith • Once you have a coherent monolith it will be easier to discover its actual components
33. Identify what your system is
34. Write test on system edges • And refactor like a boss • Understand and appreciate that these tests help specify your domain
35. Insist that no service boundary should be left behind • Collapses as many unnecessary conceptual models as possible • Question any attempt of generalization • Rule of 3 • Avoid any internal service boundary like the plague
36. Apply all the good principles that are prerequisites for microservices • Apply the discipline required to operate a microservice • Break your domain into well defined components • Mature deployment pipeline • Apply elaborate monitoring
37. “Simplicity is prerequisite for reliability.” Edsgar W. Dijkstra
38. • Understand that your prime goal is to deliver business value • Microservices are probably more expensive than you think – be sure you want to pay the price • Microservices require a lot of discipline – instead adopt this discipline in your monolith • Know the problem you are solving – don't let potential problems dictate your solution
39. So should I use microservices? “It depends…”
40. “probably not”