Services THE REAL VALUE OF MICROSERVICES Simon Martinelli, 72 Services LLC @simas_ch

ABOUT ME @simas_ch 2 2000 1995 Java COBOL 2009 2007 2012 2011 JSR-352 Batch 2013 JSR-354 Money /Currency

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

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

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

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

ARE THEY REALLY THE SAME? 7

MODULARITY AND DISTRIBUTION 8 Distribution Modularity Modular monolith Monolithic big ball of mud Distributed big ball of mud Microservices

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

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

DISTRUBUTION AND COMMUNICATION First Law of Distributed Object Design: Don't distribute your objects - Martin Fowler 11 Synchronous Asynchronous Event based

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

HOW TO BREAK THE MONOLITH? A Real World Example 13

SYSTEM ISSUES • Cyclic dependencies • No component structure • Meaningless names 14

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

DEFINE BOUNDED CONTEXTS 16 Monitoring Analytics Testing Device Alarm Update Device KPI Profile Job Device Measure- ment

TARGET SYSTEMS ARCHITECTURE 17 Local Server Device(s) Monitor Message Bridge Remote Server Monitor Analytics Testing Message Broker Message Broker

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

DECOUPLING THROUGH MESSAGING • Messaging enables modularity • Messaging enforces independence • Events not Request/Response 19 Monitor Analytics Testing Message Broker Device(s)

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

Thank You 72 Services LLC Moosentli 7, 3235 Erlach Switzerland +41 32 544 8888 info@72.services 72.services