Microservices Minus the Hype

Few topics in software architecture discussions yield as much heat as that of microservices. Monolithic applications have dominated the landscape for years, and a large number of monoliths run a great many critical processes used to this day. More recently, companies with requirements for rapid release cycles and key "ilities" (maintainability, scalability, reliability, flexibility, extensibility) have chosen another approach, deploying functionality in more granular, API-driven modules: microservices.

In this session, the presenter strips away the hype and speaks frankly of the upsides & downsides of adopting a microservices architecture and why, with certain exceptions, the pros far outweigh the cons. Topics include Domain Driven Design & bounded contexts, increasing quality & velocity, scaling, portability, & more. Patterns and architectural enablers will be presented and discussed.

Gain a better understanding of how and why to max out on microservices.

NOTE: This presentation is accompanied by live-coding of working microservices. For more information, please contact the author.

Transcript

1. Microservices Minus the Hype Mark Heckler Principal Technologist/Developer Advocate mark@thehecklers.org mheckler@pivotal.io @mkheck
2. Who am I? • Author • Speaker • Architect & Developer • Java Champion • Survivor of many monoliths • Seeker of a better way
3. Fighting the next war, not the last one We make decisions based upon the best data available at that point in time...but the world doesn't just stop The best possible decisions at any given point in time aren't evergreen As the technological landscape shifts, better decisions come into view Trust that best decisions were made Learn from the past, apply to the present to build the future
4. What is the goal? Velocity
5. Considerations
6. Monoliths Shared logic Shared data Non-granular Platform/language attachment High coupling, low cohesion Failure of part == failure of whole
7. Microservices Independent logic Independent data Granular, scalable Polyglot “Plus” High cohesion, low coupling Failures are isolated+managed
8. Isn’t this just warmed-over SOA?
9. No
10. SOA vs. microservices Conceptually similar Implementation draws clear distinction
11. –Martin Fowler, “Microservices and SOA” “…the microservice style is very similar to what some advocates of SOA have been in favor of. The problem, however, is that SOA means too many different things, and that most of the time that we come across something called ‘SOA’ it’s significantly different to the style we’re describing here, usually due to a focus on ESBs used to integrate monolithic applications.”
12. “The Great Debate: Microservices vs SOA” “Microservices is an evolution of SOA concepts that can provide additional benefits to adopting organizations. The benefit of Microservices over ‘traditional’ SOA is speed and agility for making changes, and the ability to make changes with less overall cost and less impact on the existing infrastructure. Microservices involves a different approach, as well as some different uses of technology.”
13. SOA MACROservices Heavier: SOAP + XML More coupled ceremony Dumb endpoints, smart pipes Orchestrated Much more difficult to scale
14. Microservices More focused Lighter: REST, XML, or JSON Low ceremony, low coupling Smart endpoints, dumb pipes Choreographed Built to scale
15. All about that (Enterprise Service) Bus Monitor and control routing of message exchange between services Resolve contention between communicating service components Control deployment and versioning of services Marshal use of redundant services Cater to commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service
16. Thoughts on implementations
17. Standards-based vs. Standards-limited
18. Decouple to reduce integration pains & timeframes
19. Heavy constraints slow velocity
20. Risk profile of adopting microservices
21. Microservice architecture gains Velocity Scalability Availability Optimization Independence Reduced complexity*
22. Microservice architecture losses Greater complexity (macro level) Better architects needed* Single data repository for organization Change. Seriously. Greater complexity…it bears repeating
23. The Play-DohTM Principle Applies Microservices
24. The Play-DohTM Principle Applies Monolith
25. The Play-DohTM Principle It's always easier to combine small, self-contained code or data than it is to decouple code or to parse data.
26. How to start Can’t just unplug the monolith(s) & go greenfield Build interfaces Choose volatile functionality Leverage patterns, components, & tooling
27. Microservices patterns & components Spring Boot Spring Cloud
28. Microservices patterns & components Operational Component Netflix/Spring Cloud OSS Centralized Configuration Spring Cloud Config Service Registry/Discovery Netflix Eureka (+) Circuit Breaker Netflix Hystrix Load Balancer Netflix Ribbon Intelligent Router Netflix Zuul Asynchronous Messaging Spring Cloud Stream Distributed Tracing Spring Cloud Sleuth Security/OAuth2 Spring Cloud Security and much, much more
29. Platform
30. Platform Cloud services Containerization "Day 2" ops Mission focused, ops enabling, developer liberating
31. –Marc Andreessen “In my view, because the companies that do can then innovate much more quickly than the companies that don’t.” Why are microservices and cloud-native technology important for every business to adopt (and not just startups)?
32. Let’s do this