Sustainable Architecture

Architects are used to being able to rely on a common technical basis for their systems, but it usually takes only a few successful versions for a system to turn into a hard-to-change, monolithic, annoying mess: Homogeneity, valued in the beginning, turns into a liability. In this talk, we’ll look at concepts for turning a single system into a system of systems, and discuss the architectural und organizational challenges that arise. We’ll also highlight how these ideas are definitely compatible, but possibly not identical to what’s currently being discussed as “microservices” in the community.

Transcript

1. {Nano|Micro|Mini}-Services? Modularization for Sustainable Systems Stefan Tilkov | innoQ stefan.tilkov@innoq.com @stilkov Tuesday 26 August 14
2. 1. Reviewing architectures Tuesday 26 August 14
3. Generic Architecture Review Results Building features takes too long Technical debt is well-known and not addressed Deployment is way too complicated and slow Replacement would be way too expensive Scalability has reached its limit Architectural quality has degraded “-ility” problems abound Tuesday 26 August 14
4. Any architecture’s quality is directly proportional to the number of bottlenecks limiting its evolution, development, and operations Tuesday 26 August 14
5. «Insert Obligatory Conway Reference Here» Tuesday 26 August 14
6. Conway’s Law “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.” – M.E. Conway Organization ˠ Architecture Tuesday 26 August 14
7. Reversal 1 Any particular architecture approach constraints organizational options – i.e. makes some organizational models simple and others hard to implement. Organization ˡ Architecture Tuesday 26 August 14
8. Reversal 2 Choosing a particular architecture can be a means of optimizing for a desired organizational structure. Organization ˡ Architecture Tuesday 26 August 14
9. 2. System boundaries Tuesday 26 August 14
10. Modularization Legacy System New System New System Tuesday 26 August 14
11. New System Consolidation Legacy System Legacy System Tuesday 26 August 14
12. New System Legacy System Modernization Tuesday 26 August 14
13. New System Greenfield Project scope Tuesday 26 August 14
14. 1 Project = 1 System? Tuesday 26 August 14
15. 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 Tuesday 26 August 14
16. Separate, runnable process Accessible via standard ports & protocols Shared-nothing model Horizontal scaling Fast startup & recovery App characteristics Tuesday 26 August 14
17. http://12factor.net Tuesday 26 August 14
18. Microservice Characteristics small each running in its own process lightweight communicating mechanisms (often HTTP) built around business capabilities independently deployable mininum of centralized management may be written in different programming languages may use different data storage technologies http://martinfowler.com/articles/microservices.html Tuesday 26 August 14
19. “Sizing things” is one of the hardest architectural tasks Tuesday 26 August 14
20. 3. Cutting things up … Tuesday 26 August 14
21. Macro (technical) architecture Domain architecture Tuesday 26 August 14
22. JRuby C# Scala Groovy Java Clojure Tuesday 26 August 14
23. RDBMS NoSQL K/V RDBMS RDBMS/DWH NoSQL DocDB Tuesday 26 August 14
24. RDBMS NoSQL K/V RDBMS RDBMS/DWH NoSQL DocDB Micro architecture Tuesday 26 August 14
25. Persistence Logic UI Module A Module B Module C Tuesday 26 August 14
26. System A Persistence Logic UI System B Persistence Logic UI System C Persistence Logic UI Tuesday 26 August 14
27. Afraid of chaos? Tuesday 26 August 14
28. 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 Tuesday 26 August 14
29. 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 Tuesday 26 August 14
30. Initial goals Simplicity Speed Easy development Maximum productivity Tuesday 26 August 14
31. Long-term goals Stability Scalability Maintainability Decoupling Tuesday 26 August 14
32. 4. … putting pieces together Tuesday 26 August 14
33. Service Interface Service Interface Client Logic Tuesday 26 August 14
34. Service Interface Service Interface Client Logic Tuesday 26 August 14
35. Service Interface Service Interface Client Logic Tuesday 26 August 14
36. Service Interface Service Interface Client Logic Orchestration Tuesday 26 August 14
37. Business Logic Business Logic Presentation Logic Tuesday 26 August 14
38. Business Logic Business Logic Presentation Logic Presentation Logic Tuesday 26 August 14
39. Self-Contained System (SCS) Tuesday 26 August 14
40. SCS Characteristics Autonomous web application Owned by one team No sync remote calls Service API optional Includes data and logic No shared UI No or pull-based code sharing only Tuesday 26 August 14
41. Web-native front-end integration Tuesday 26 August 14
42. Browser HTML Page Backend 1 UI 1 UI 2 Server-side integration Backend 2 Frontend Server Examples: ESI-Caches SSI Portal Server Tuesday 26 August 14
43. Browser HTML Page Backend 1 UI 1 UI 2 Client-side integration Backend 2 Examples: AJAX Proprietary Frameworks Tuesday 26 August 14
44. Browser HTML Page 1 Links Backend 1 Backend 2 Asset Server HTML Page 2 CSS <<creates>> <<creates>> Tuesday 26 August 14
45. Development Deployment Storage Backend call Edge integration Server-side integration options ESI Homegrown (Portal server) Build tools Chef, Puppet, … Asset pipeline Git/SVN submodules Gems Maven artifacts DB replication Feeds RPC REST RMI WS-* Tuesday 26 August 14
46. Link Replaced link Client-side integration options Client call Magical integration concept Unobtrusive JS ROCA-style oEmbed SPA-style JS Widgets Tuesday 26 August 14
47. Single Sign-On Tuesday 26 August 14
48. Backend 1 Backend 2 Auth-Provider Browser Login Credentials Ticket Validation Request + Ticket Request + Ticket Algorithmic Validation Tuesday 26 August 14
49. 5. Questions Tuesday 26 August 14
50. Microservice? SCS ≡ Tuesday 26 August 14
51. Microservice? SCS Ὂ Tuesday 26 August 14
52. Microservice? SCS 1 * Tuesday 26 August 14
53. Microservice? SCS * Tuesday 26 August 14
54. Microservice? SCS * Tuesday 26 August 14
55. Explicitly design system boundaries Modularize into independent, self-contained systems Separate micro and macro architectures Be aware of changing quality goals Strike a balance between control and decentralization Summary Tuesday 26 August 14
56. 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 Tuesday 26 August 14