The Real Value of Microservices

Transcript

1. Services THE REAL VALUE OF MICROSERVICES Simon Martinelli, 72 Services LLC @simas_ch
2. ABOUT ME @simas_ch 2 2000 1995 Java COBOL 2009 2007 2012 2011 JSR-352 Batch 2013 JSR-354 Money /Currency
3. 1972 The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules. On the criteria to be used in decomposing systems into modules - David L. Parnas Published in Communications of the ACM Volume 15 Issue 12, Dec. 1972 3
4. IT’S ALL ABOUT MODULARITY Module A self-contained component of a system, often interchangeable, which has a well-defined interface to the other components. Source: https://en.wiktionary.org/wiki/module 4
5. DOES THE SIZE MATTER? • The term MICRO is misleading • Scope matters • Bounded Contexts • Design for Maintenance • 3 to 10 developers per Microservice during project development • But how many developers will maintain the system? 5
6. WHAT ABOUT SERVICES? • Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation • Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services • Service • Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data) • Is self-contained • May be composed of other services • Is a black box to consumers of the service 6 Source: http://www.opengroup.org/soa/source-book/soa/p1.htm
7. ARE THEY REALLY THE SAME? 7
8. MODULARITY AND DISTRIBUTION 8 Distribution Modularity Modular monolith Monolithic big ball of mud Distributed big ball of mud Microservices
9. DISTRIBUTED BIG BALL OF MUD If you can't build a modular monolith, what makes you think microservices are the answer? - Simon Brown 9 Customer Order Catalog
10. BEWARE OF THE N+1 SELECT PROBLEM • Use Case: Select orders of customers • 1 request to get all customers • n requests to get customers orders 10 Customer Order Client 1 1 … n
11. DISTRUBUTION AND COMMUNICATION First Law of Distributed Object Design: Don't distribute your objects - Martin Fowler 11 Synchronous Asynchronous Event based
12. SUBSYSTEMS (AKA GARTNERS MINISERVICES) 12 Backend A Database A Database B Backend D Database D Frontend A Frontend B Frontend C Backend B Backend C Self-contained System Monolithic frontend Integration Database
13. HOW TO BREAK THE MONOLITH? A Real World Example 13
14. SYSTEM ISSUES • Cyclic dependencies • No component structure • Meaningless names 14
15. 3 STEP REFACTORING • Step 1: Define target architecture • Define bounded contexts • Introduce pattern language • Separate infrastructure code from business code • Step 2: Move existing code to newly defined subsystems • Step 3 (optional): Distribute the subsystems 15
16. DEFINE BOUNDED CONTEXTS 16 Monitoring Analytics Testing Device Alarm Update Device KPI Profile Job Device Measure- ment
17. TARGET SYSTEMS ARCHITECTURE 17 Local Server Device(s) Monitor Message Bridge Remote Server Monitor Analytics Testing Message Broker Message Broker
18. MIGRATION SCENARIO (AKA STRANGLER PATTERN) 18 Backend Database Frontend Monolith Backend Database Frontend Step 1 Database Frontend Step 2..n Backend 1 Database 1 Backend Frontend 1 Backend n Database n Backend 1 Database 1 Subsystems Frontend n https://en.wikipedia.org/wiki/Strangler_fig
19. DECOUPLING THROUGH MESSAGING • Messaging enables modularity • Messaging enforces independence • Events not Request/Response 19 Monitor Analytics Testing Message Broker Device(s)
20. THE REAL VALUES • A microservices architecture leads to modularity • Developers are forced to follow the structure • It’s easier to replace a subsystem instead of the whole system in the future 20
21. Thank You 72 Services LLC Moosentli 7, 3235 Erlach Switzerland +41 32 544 8888 info@72.services 72.services