2019-01-21-WebArch--OOP.pdf

A presentation about modularity, architecture and organization patterns, applied to the development of large web apps

Transcript

1. Architecting Large Web Apps Stefan Tilkov
 stefan.tilkov@innoq.com
 @stilkov
2. What is “large“?
3. Scaling Dimensions Logic Load written in
 a day depends on
 German tax law a dozen
 users half
 of the
 planet Netflix Twitter Insurance
 Policy Management Facebook Amazon Random CMS
4. Pick the best car:
5. Architecture & Organization Modularization Frontend Strategies
6. Architecture & Organization
7. Conway’s Law: Organization → Architecture “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”
 – M.E. Conway
8. Antipatterns
9. Antipattern: Conference-driven Architecture
10. Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder Platform Person
11. Antipattern: Half-hearted Modularization Dev Ops
12. Antipattern: Solution Centrism Stakeholder Stakeholder Stakeholder Solution
13. Antipattern: Uncreative Chaos
14. Antipattern: Authoritarian Regime
15. Patterns
16. Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops
17. Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops
18. Pattern: Evolutionary Architecture
19. Pattern: Regulated Market
20. Pattern: Marketing-based Governance
21. Sizing Patterns
22. Example: Product Detail Page • Core product data • Prose description • Images • Reviews • Related content Orchestration →μSOA
23. Pattern: μSOA (Microservice-SOA) • Small, self-hosted • Communicating synchronously • Cascaded/streaming • Containerized Description: As seen on: • Netflix • Twitter • Gilt
24. Pattern: μSOA (Microservice-SOA) • Close collaboration – common goal • Need for resilience/stability patterns for invocations • High cost of coordination (versioning, compatibility, …) • High infrastructure demand • Often combined with parallel/streaming approach • Well suited to environments with extreme scalability requirements Consequences:
25. Example: Logistics Application • Order management • Shipping • Route planning • Invoicing Frontend →DDDD Event Bus/Infrastructure
26. Pattern: DDDD (Distributed Domain-driven Design) • Small, self-hosted • Bounded contexts • Redundant data/CQRS • Business events • Containerized Description: As seen on: • (undisclosed)
27. Pattern: DDDD (Distributed Domain-driven Design) • Loose coupling between context • Acknowledges separate evolution of contexts • Asynchronicity increases stability • Well-suited for to support parallel development Consequences:
28. That UI thing? Easy!
29. Assumption
30. Reality
31. Example: E-Commerce Site • Register & maintain account • Browse catalog • See product details • Checkout • Track status →SCS
32. Pattern: SCS (Self-contained Systems) • Self-contained, autonomous • Including UI + DB • Possibly composed of smaller microservices Description: As seen on: • Amazon • Groupon • Otto.de • https://scs-architecture.org
33. Pattern: SCS (Self-contained Systems) • Larger, independent systems,
 including data + UI (if present) • Able to autonomously serve requests • Light-weight integration, ideally via front-end • No extra infrastructure needed • Well suited if goal is decoupling of development teams Consequences:
34. The final sizing pattern …
35. Benefits of Monoliths • Highly cohesive, tightly integrated, single unit of deployment • Standard application with internal modularity • No artificially introduced distribution • Single unit of development and evolution • Easy to refactor • Homogeneous technical choices • Ideally suited for single small team
36. We love monoliths –
 so let’s build a lot of them!
37. Frontend Architecture
38. “Really remote” vs. “almost local” μS μS μS μS μS μS Inside DC;
 Latency: μs Frontend Typically Internet;
 Latency: ms
39. “Backend for Frontend” μS μS μS μS μS μS BFF Frontend http://samnewman.io/patterns/architectural/bff/
40. Multiple BFFs for different clients μS μS μS μS μS μS BFF Frontend BFF Frontend BFF Frontend Imagine more arrows here
41. Multiple channels – facing every user Browse product Pick recommendation Buy Check status Comment
42. Users expect a seamless experience across channels
 – everything accessible, everywhere.
43. Build services that actually do something Process Flow Presentation Domain Logic Data JDBC in disguise Useful and specific Re- usable and low- level
44. Assumption: Services matter most (a.k.a. “SOAs Original Sin”) UIs matter more.
45. μS μS μS μS μS Frontend μS Frontend + services in a backend architect’s mind μS μS μS μS μS Frontend μS Frontend + services in the real world
46. Redundancy with Multiple BFFs μS μS μS μS μS μS Frontend A Frontend B Frontend C
47. Ideal world UI componentization μS μS μS μS μS μS FE μS μS FE Not all μS need a UI “Vertical”
 Responsibilit
48. SCS: Self-contained Systems http:/ /scs-architecture.org
49. Backend Platform More than one platform μS μS μS μS μS μS Frontend Platform FE μS μS FE
50. Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App Frontend, we’ve got frontends Frontend Hybrid
51. Web UI Integration: Links System 1 System 2
52. Web UI Integration: Redirection System 1 System 2
53. Web UI Integration: Transclusion System 1 System 2
54. Web UI Integration: Web Components System 1 Component
55. How to get away with “just” the Web • Mobile first • Responsive design • Progressive enhancement • Shared assets • Pull vs. push • Sacrifice (some) efficiency Small frontends, loosely coupled
56. Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App What about other approaches? Frontend Hybrid ✔ ✔ ✔ ?
57. Native frontends resemble server monoliths Goals: • As few assumptions as possible • No implementation dependencies • Small interface surface • Based on standards • Parallel development • Independent deployment • Autonomous operations Constraint: • Only internal modularization Solution (sort of): • Organizational structure • Platform interfaces • Release trains • Discipline
58. Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App What about other “modern” web apps? Frontend Hybrid ✔ ✔ ✔ (✔) ?
59. Assumption: JS-centric web apps can
 be as good as native apps They shouldn’t be as bad!
60. “Web service”1) • Use HTTP as transport • Ignore verbs • Ignores URIs • Expose single “endpoint” • Fails to embrace the Web 1) in the SOAP/WSDL sense “Web app”2) > Uses browser as runtime > Ignores forward, back, refresh > Does not support linking > Exposes monolithic “app” > Fails to embrace the browser 2) built as a careless SPA
61. HTML & Hypermedia • In REST, servers expose a hypermedia format • Option 1: Just use HTML • Option 2: Just invent your own JSON-based, incomplete clone • Clients need to be RESTful, too • Option 1: Use the browser • Option 2: Invent your own, JS-based, buggy, incomplete implementation
62. $('.multiselect', context).each(function() {
 $(this).multiselect({
 selectedList: 2,
 checkAllText: "Alle",
 uncheckAllText: "Keinen"
 }).multiselectfilter({label:"",
 width:"200px"});
 }); <div class="filter-column">
 <label for="project">Project</label>
 <select class="multiselect" id="project"
 name="project" size="5" multiple>
 <option>DISCOVER</option>
 <option>IMPROVE</option>
 <option >MAGENTA</option>
 <option>ROCA</option>
 <option>ROCKET</option>
 </select>
 </div>
63. Why choose a monolith if you don’t have to? Any sufficiently complicated JavaScript client application contains an ad hoc, informally- specified, bug-ridden, slow implementation of half a browser. (Me, with apologies to Phillip Greenspun)
64. ROCA: Resource-oriented Client Architecture http:/ /roca-style.org
65. If you’re a fan of single page apps,
 at least build more than one • Don’t reinvent browser integration features • Accept some inefficiency • Trade-off for framework independence • Avoid modularity à la Java EE, OSGi etc.
66. Maintaining Consistency
67. Challenges & Cross-cutting Concerns Single sign-on End-to-end testing Visual consistency Re-use Skill transfer
68. Visual Components • Design System • Style guide • Pattern library http://styleguides.io
69. Style Guide Challenges • Possible centralization & resulting bottlenecks • (Semi-)manual workflow • Copy/paste & resulting redundancy & overhead
70. Recommendations
71. 1. Know where your problems are
72. 2. Beware of the monolith …
73. 3. … unless it makes sense
74. 4. Create evolvable structures
75. 5. Embrace the Web
76. Christian Albrecht christian.albrecht@innoq.com Phone: +49 171 5514847 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 Ludwigstr. 180E 63067 Offenbach Germany Phone: +49 2173 3366-0 Kreuzstraße 16
 80331 München Germany Phone: +49 2173 3366-0 @stilkov That’s all I have.
 Thanks for listening! Questions? Stefan Tilkov @stilkov
 stefan.tilkov@innoq.com
 Phone: +49 170 471 2625
77. www.innoq.com OFFICES Monheim Berlin Offenbach Munich Hamburg Zurich FACTS ~150 employees Privately owned Vendor-independent SERVICES Strategy & technology consulting Digital business models Software architecture & development Digital platforms & infrastructures Knowledge transfer, coaching & trainings CLIENTS Finance Telecommunications Logistics E-commerce Fortune 500 SMBs Startups