This document discusses microservices and compares them to monolithic applications and SOA. Some key points: - Microservices decompose an application into independently deployable components that communicate over well-defined interfaces. This improves scalability, velocity, and resilience compared to monoliths. - While conceptually similar to SOA, microservices differ in their lighter implementation using REST, JSON, and a focus on smart endpoints and dumb pipes rather than ESBs. - Adopting microservices brings gains in velocity, scalability, availability, and optimization but also increases complexity at the macro level and requires better architects. - Transitioning from a monolith to microservices follows the "Play-Doh

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