Breaking The Monolith

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 | @stilkov | innoQ
2. © 2012 innoQ Deutschland GmbH Boxes & Lines Wild Handwaving
3. © 2012 innoQ Deutschland GmbH Enterprisey Stu
4. © 2012 innoQ Deutschland GmbH Today’s Topic: Systems
5. © 2012 innoQ Deutschland GmbH System boundaries
6. © 2012 innoQ Deutschland GmbH What’s a system?
7. © 2012 innoQ Deutschland GmbH Task: Draw a high-level architecture diagram!
8. © 2012 innoQ Deutschland GmbH UI Logic Persistence
9. © 2012 innoQ Deutschland GmbH
10. © 2012 innoQ Deutschland GmbH Product Admin OrderMgmt Catalog Inventory Mgmt Data Export Billing
11. © 2012 innoQ Deutschland GmbH Modules Components Subsystems Libraries Classes …
12. © 2012 innoQ Deutschland GmbH How do we come up with system boundaries?
13. © 2012 innoQ Deutschland GmbH New System Legacy System Modernization Project scope
14. © 2012 innoQ Deutschland GmbH New System Consolidation Project scope Legacy System Legacy System
15. © 2012 innoQ Deutschland GmbH Modularization Project scope Legacy System New System New System
16. © 2012 innoQ Deutschland GmbH 1 Project = 1 System?
17. © 2012 innoQ Deutschland GmbH Modularization & Size Size Modularization 1-50 LOC single le 50-500 LOC few les, few functions 500-1000 LOC Library, class hierarchy 1000-2000 LOC Framework + application >2000 LOC multiple applications
18. © 2012 innoQ Deutschland GmbH System characteristics Separate (redundant) persistence Internal, separate logic Domain models & implementation strategies Separate UI Separate development & evolution Autonomous operations Limited interaction with other systems
19. © 2012 innoQ Deutschland GmbH Micro vs. Macro architecture
20. © 2012 innoQ Deutschland GmbH
21. © 2012 innoQ Deutschland GmbH Macro (technical) architecture Domain architecture
22. © 2012 innoQ Deutschland GmbH JRuby C# Scala Groovy Java Clojure
23. © 2012 innoQ Deutschland GmbH RDBMS NoSQL K/V RDBMS RDBMS/ DWH NoSQL DocDB
24. © 2012 innoQ Deutschland GmbH RDBMS NoSQL K/V RDBMS RDBMS/ DWH NoSQL DocDB Micro architecture
25. © 2012 innoQ Deutschland GmbH Afraid of chaos?
26. © 2012 innoQ Deutschland GmbH 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 (Deployment, Operations)
27. © 2012 innoQ Deutschland GmbH 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
28. © 2012 innoQ Deutschland GmbH t Simplicity Homogeneity Cohesion Decoupling Modularity (Support for) Heterogeneity Autonomy Main objectives over time Ease of development
29. © 2012 innoQ Deutschland GmbH Separate systems, loosely coupled?
30. © 2012 innoQ Deutschland GmbH Data Replication Backend Integration Frontend Integration Integration options Data Logic UI Data Logic UI
31. © 2011 innoQ Deutschland GmbH Data integration
32. © 2011 innoQ Deutschland GmbH Data replication
33. © 2011 innoQ Deutschland GmbH Or: Why data redundancy is good for you
34. © 2012 innoQ Deutschland GmbH Process Call Stack Assumed Success Probability: 99.9%
35. © 2012 innoQ Deutschland GmbH Distributed Call Stack Assumed Success Probability: 99.6% 98%? 90%?
36. © 2011 innoQ Deutschland GmbH <Customer Change> Order Management GET Customer XYZ Submit Order Orders Customer Management Customers Customers Event notification
37. © 2011 innoQ Deutschland GmbH A C B
38. © 2012 innoQ Deutschland GmbH Frontend integration
39. © 2012 innoQ Deutschland GmbH Frontend integration Data Logic UI Data Logic UI
40. © 2012 innoQ Deutschland GmbH Frontend integration UI Data Logic Data Logic UI
41. © 2012 innoQ Deutschland GmbH Browser HTML Page Backend 1 UI 1 Frontend Server UI 2 Server-side integration Backend 2 Examples: ESI-Caches SSI Portal Server
42. © 2012 innoQ Deutschland GmbH Browser HTML Page Backend 1 UI 1 UI 2 Client-side integration Backend 2 Examples: AJAX Proprietary Frameworks
43. © 2012 innoQ Deutschland GmbH Browser HTML Page 1 Links Backend 1 Backend 2 Asset Server HTML Page 2 CSS <<creates>> <<creates>>
44. © 2012 innoQ Deutschland GmbH Single Sign-On
45. © 2012 innoQ Deutschland GmbH SSO Backend 1 Backend 2 Auth-Provider Browser Login Credentials Ticket Validation Request + Ticket Request + Ticket Algorithmic Validation
46. © 2012 innoQ Deutschland GmbH Summary
47. © 2012 innoQ Deutschland GmbH 1. Think about the systems that make up your system 2. Separate micro and macro architectures 3. Address UI integration and SSO Summary
48. © 2012 innoQ Deutschland GmbH Thanks! Q&A innoQ Deutschland GmbH http://www.innoq.com Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH info@innoq.com Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116
49. © 2012 innoQ Deutschland GmbH Backup
50. © 2012 innoQ Deutschland GmbH Bounded Context Customer/Supplier Conformist Anticorruption Layer Open Host Service Published Language Shared Kernel Separate Ways Strategic DDD
51. © 2012 innoQ Deutschland GmbH CQRS (Command Query Responsibility Segregation) Logic Persistence Write-UI Read-UI
52. © 2012 innoQ Deutschland GmbH CQRS (Command Query Responsibility Segregation) Write-UI Logic (Tx) Persistence Read-UI Persistence Event Handling