Pro Yearly is on sale from $80 to $50! »

Sustainable Architecture

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.

Afd6dc452bc20f8f06612d4792bb8be3?s=128

Stefan Tilkov

August 25, 2014
Tweet

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