Breaking the Monolith

We'll question the initial architecture decisions in building large systems, and discuss how to approach design differently. Allow for diversity while maintaining integrity, and avoid falling into the trap of making technology choices with too much rigor.

In any system of significant size, the same problem occurs again and again: What starts out as a light-weight, modern, efficient development effort using the technology of the day – be it Java and Java EE or Spring, Microsoft .NET, Ruby on Rails or any other of the well-known development stacks – ends up as a hard to change, monolithic, maintenance-intensive behemoth that everybody wants to get away from. But what are the core reason for this recurring pattern? In this session, we will discuss how and why things always seem to end up this way, and what strategies we can use to avoid this from the start.

Transcript

1. Breaking the Monolith Stefan Tilkov | innoQ | @stilkov
2. Architecture
3. Task: Draw a high-level architecture diagram!
4. UI Logic Persistence
6. Product Admin OrderMgmt Catalog Inventory Mgmt Data Export Billing
7. Lots of things …
8. Modules Components Subsystems Libraries Classes …
9. … all in one system
10. How do we come up with system boundaries?
11. Modularization Legacy System New System New System
12. New System Consolidation Legacy System Legacy System
13. New System Legacy System Modernization Project scope
14. 1 Project = 1 System?
15. Deciding what makes up a system is an architectural decision
16. Size Modularization 1-50 LOC single file 50-500 LOC few files, few functions 500-1000 LOC Library, class hierarchy 1000-2000 LOC Framework + application >2000 LOC multiple applications
17. System characteristics Separate (redundant) persistence Internal, separate logic Domain models & implementation strategies Separate UI Separate development & evolution Limited interaction with other systems Autonomous deployment and operations
18. Think hard about how many systems you need to build
19. Separate, runnable process Accessible via standard ports & protocols Shared-nothing model Horizontal scaling Fast startup & recovery System characteristics
20. http://12factor.net/ http://dropwizard.codahale.com/ Dropwizard
21. The container model promoted by Java EE needs to die (and it will)
22. Micro vs. Macro architecture
24. Macro (technical) architecture Domain architecture
25. JRuby C# Scala Groovy Java Clojure
26. RDBMS NoSQL K/V RDBMS RDBMS/DWH NoSQL DocDB
27. RDBMS NoSQL K/V RDBMS RDBMS/DWH NoSQL DocDB Micro architecture
28. Be strict about your macro architecture rules, but allow for many degrees of freedom on the micro level
29. Afraid of chaos?
30. Necessary Rules & Guidelines Cross-system System-internal Responsibilities Programming languages UI integration Development tools Communication protocols Frameworks Data formats Process/Workflow control Redundant data Persistence BI interfaces Design patterns Logging, Monitoring Coding guidelines
31. t Domain Architecture 1.0 1.1 System-internal Rules 1.0 1.1 2.0 2.1 Cross-system Rules 1.0 1.1 1.2
32. t Simplicity Homogeneity Cohesion Decoupling Modularity (Support for) Heterogeneity Autonomy Main objectives over time Ease of development
33. Separate systems, loosely coupled?
34. Data Replication Backend Integration Frontend Integration Integration options Data Logic UI Data Logic UI
35. Frontend integration Data Logic UI Data Logic UI
36. Frontend integration Data Logic UI Data Logic UI
37. Browser HTML Page Backend 1 UI 1 UI 2 Server-side integration Backend 2 Frontend Server Examples: ESI-Caches SSI Portal Server
38. Browser HTML Page Backend 1 UI 1 UI 2 Client-side integration Backend 2 Examples: AJAX Proprietary Frameworks
39. Browser HTML Page 1 Links Backend 1 Backend 2 Asset Server HTML Page 2 CSS <<creates>> <<creates>>
40. Single Sign-On
41. Backend 1 Backend 2 Auth-Provider Browser Login Credentials Ticket Validation Request + Ticket Request + Ticket Algorithmic Validation
42. Organization
43. Cross-system Responsibilities UI integration Communication protocols Data formats Redundant data BI interfaces Logging, Monitoring Product Admin OrderMgmt Catalog Inventory Mgmt Data Export Billing Architecture Governance
44. Surprise: There is a justification for someone to take care of the overall architecture
45. Operations
46. System characteristics Separate (redundant) persistence Internal, separate logic Domain models & implementation strategies Separate UI Separate development & evolution Limited interaction with other systems Autonomous deployment and operations
47. Dev Ops
48. If systems are really separate, they need to be so from start to finish
49. Migration
50. Or: A step-by-step guide to a better future (that occasionally works)
51. Assumptions High business value Very high cost of change Very slow “time to market” Huge backlog of feature requests Problem awareness Strong management support
52. Close for change Enable integrateability (auth/auth, navigation) Create new system for new features Copy & isolate Integrate and/or replace part
53. Think about the systems that make up your system Separate micro and macro architectures Be aware of changing quality goals Strike a balance between control and decentralization Summary
54. Thank you! Questions? Comments? Stefan Tilkov, @stilkov stefan.tilkov@innoq.com http://www.innoq.com/blog/st/ Phone: +49 170 471 2625 innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Robert-Bosch-Straße 7 64293 Darmstadt Germany Phone: +49 2173 3366-0 Radlkoferstraße 2 D-81373 München Germany Telefon +49 (0) 89 741185-270