Microservices for Mortals
18 likes11,254 views
The document discusses microservices as a response to evolving software architecture, emphasizing their role in business agility and the challenges compared to traditional monolithic systems. It outlines the struggles in transitioning from monoliths to microservices, including data strategy, communication patterns, and organizational alignment with software architecture. Additionally, the text critiques misconceptions and vendor-driven hype surrounding microservices, urging careful consideration and education on the topic.
Microservices for Mortals
- 2. • Fellow at Luminis • Background in all things Java since 1995 • Java Champion, JavaOne Rockstar Speaker, and a Duke’s Choice Award Winner • Involved in architecting and implementing dozens of large scale systems over the past 20 years or so • Book author for O’Reilly, speaker at many conferences About me
- 5. Pick a side…
- 8. What if I’m allergic to Italian food? Can I still do Microservices?
- 9. Where did it come from? • People have been doing AJAX, NoSQL, SOA, etc before they even got a name • Microservices style architectures are a response to adjust software architecture to an ever-evolving spectrum. It addresses Business Agility through technology: • Usage of cloud-based infrastructure and services • DevOps • The need to scale up the number of people/teams • Client-side revolution both in technologies and devices
- 11. Microservices are like SOA, but only the good parts
- 12. What happened to SOA? • SOA quickly turned into the rape victim of a vendor infested lock-in massacre, excessively complicating all good advice into giant overpriced hairballs sold as fake middleware, ESBs, and appliances.
- 16. Which pill do you take?
- 17. blue pill world • Blissful ignorance • Hey, since everyone and their mother seems to be tweeting about this microservices thing, it must be cool, right? • Heck, even Martin Fowler is blogging about it. Now it’s definitely mainstream • Dude, it’s on the freakin’ Technology Radar! • Btw, this seems to be a killer way to introduce Node.js to my customer, yeah!
- 18. Which pill do you take?
- 19. red pill world • Painful truth of reality • Where do we defy the laws of (IT) physics? • This thing is about distributed computing which after all these years is still very hard to do! • This thing is about asynchronous programming models, which are hard to grasp • It has a number of other gotcha’s which I will go into…
- 20. There is no spoon • Forget synchronous programming models • Forget a single Enterprise Domain Model • Forget ACID transactions • Forget Relational Integrity
- 21. Welcome to red pill world
- 24. About Monoliths • The word ‘monolith’ has a negative connotation • Not all non-microservices apps are bad applications • What do you call an application that everyone wants to interface with but was not designed to do?
- 26. When monoliths are bad • But… such systems can end up as monoliths with all the negative connotations to it as they: • Start to build up massive technical debt • Become hard to change without breaking stuff • QA and test cycles take lots of time (expensive) • When heavy internal coupling starts to take over control of the application • Become married to the underlying technical stack
- 27. Monolith to Microservices approach • As was recently suggested by Martin Fowler, et al. the Monolith-First approach is a way of “strangling off services from a monolithic application”. • This makes great theory, but is pretty hard to do in practice • Often times building blocks on the inside of an application are not suitable as building blocks outside of an application
- 28. Monolith to Microservices Struggles • Initial Investment • Data Strategy • Synchronous vs Asynchronous • Conway’s Law • Re-use Traps • Dealing with Failure
- 29. Initial Investment • So-called “Outer Architecture” • Service Discovery • Logging • Metrics and Analytics • DevOps process in-place • Solid CI/CD practices • Impact on testing strategy
- 30. Data Strategy
- 31. Data Strategy • Don’t have multiple microservices share the same database model and perform updates on it • this results in unwanted coupling • Separate at least read/write access if you must • Better: separate data stores for each service
- 32. Data Strategy • Q: What if I have common data? • A: Either perform a call to another service or just copy the data • Q: How do I deal with referential integrity? • A: Move it up in the application layer
- 33. Synchronous vs Asynchronous • Within the monolith, most communication will be synchronous • Your interfaces have been designed with synchronous, in-process, interactions in mind • May be chatty (fine-grained) • Rethinking interaction patterns is essential • Rethink the communication protocol as well
- 34. Service Communication • Standardize on a common communication protocol • Oftentimes people choose REST, but there are others • protobuf, thrift, zeromq, mqtt, … • Is REST fast enough to do massive fan-out? • Maybe have two: synchronous and asynchronous
- 35. Avoid re-use traps • Q: What is the best strategy for reusing common functionality between microservices? • A: Copy it in the beginning of the project if you must. Never look back. Microservices are designed to be TOTALLY independent of each other, remember?
- 37. Conway’s Law So here is the obligatory reference to Conway’s Law: “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" —M. Conway 1968
- 38. What it actually means • Make sure the organization is compatible with the software architecture • If your (microservices) architecture does not reflect the way your organization is structured, don’t even bother going that way! • It also means that your team should be cross- functional. Everyone you need to build, maintain and get it into production must be part of the team
- 39. This is hard!
- 45. Design for Failure • Dependent services may be unavailable or too slow to respond • Minimize human intervention • failure happens all the time, so it shouldn’t be a big deal • fail rather sooner than later (prevent cascading) • Horizontal clustering to the rescue (multiple services) • Resilience Patterns to the rescue • CircuitBreaker, Bulkhead, Caching, Retry, Messaging, etc • This is complicated stuff. It is not just about throwing Hystrix or some other library in
- 46. Some take-aways • The essence of Microservices is about structuring systems differently • It’s about Modularity • It’s about Separation of Concerns • It’s about Single Responsibility Principle • It addresses Business Agility through technology • Those are not bad things!
- 47. However… • Everything comes at a price • Aligning the architecture to the organization is surprisingly hard • It is not just a matter of throwing in a couple of frameworks, you have to think things through thoroughly before going this direction
- 48. In the end… • Keep on educating yourself as more war stories see the light of day • Don’t just listen to one vendor’s version of the story, all they care about is locking you in • Have a rational thought process trump the hype, however difficult that is - think for yourself rather than following just the latest blogs and technologies
- 49. And one more thing… • We are not all Netflix or Amazon • Just like we’re not all Twitter and Facebook with the Big Data and Web Scale hypes… • not all of us have billions of calls floating around at any given day • if you pretend you are, you will have all their infrastructural problems to deal with for free and even at a minor scale they are just as hard