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

Slide 1

Slide 1 text

Architecting Large Web Apps Stefan Tilkov  stefan.tilkov@innoq.com  @stilkov

Slide 2

Slide 2 text

What is “large“?

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Pick the best car:

Slide 5

Slide 5 text

Architecture & Organization Modularization Frontend Strategies

Slide 6

Slide 6 text

Architecture & Organization

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Antipatterns

Slide 9

Slide 9 text

Antipattern: Conference-driven Architecture

Slide 10

Slide 10 text

Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder Platform Person

Slide 11

Slide 11 text

Antipattern: Half-hearted Modularization Dev Ops

Slide 12

Slide 12 text

Antipattern: Solution Centrism Stakeholder Stakeholder Stakeholder Solution

Slide 13

Slide 13 text

Antipattern: Uncreative Chaos

Slide 14

Slide 14 text

Antipattern: Authoritarian Regime

Slide 15

Slide 15 text

Patterns

Slide 16

Slide 16 text

Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops

Slide 17

Slide 17 text

Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops

Slide 18

Slide 18 text

Pattern: Evolutionary Architecture

Slide 19

Slide 19 text

Pattern: Regulated Market

Slide 20

Slide 20 text

Pattern: Marketing-based Governance

Slide 21

Slide 21 text

Sizing Patterns

Slide 22

Slide 22 text

Example: Product Detail Page • Core product data • Prose description • Images • Reviews • Related content Orchestration →μSOA

Slide 23

Slide 23 text

Pattern: μSOA (Microservice-SOA) • Small, self-hosted • Communicating synchronously • Cascaded/streaming • Containerized Description: As seen on: • Netflix • Twitter • Gilt

Slide 24

Slide 24 text

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:

Slide 25

Slide 25 text

Example: Logistics Application • Order management • Shipping • Route planning • Invoicing Frontend →DDDD Event Bus/Infrastructure

Slide 26

Slide 26 text

Pattern: DDDD (Distributed Domain-driven Design) • Small, self-hosted • Bounded contexts • Redundant data/CQRS • Business events • Containerized Description: As seen on: • (undisclosed)

Slide 27

Slide 27 text

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:

Slide 28

Slide 28 text

That UI thing? Easy!

Slide 29

Slide 29 text

Assumption

Slide 30

Slide 30 text

Reality

Slide 31

Slide 31 text

Example: E-Commerce Site • Register & maintain account • Browse catalog • See product details • Checkout • Track status →SCS

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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:

Slide 34

Slide 34 text

The final sizing pattern …

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

We love monoliths –  so let’s build a lot of them!

Slide 37

Slide 37 text

Frontend Architecture

Slide 38

Slide 38 text

“Really remote” vs. “almost local” μS μS μS μS μS μS Inside DC;  Latency: μs Frontend Typically Internet;  Latency: ms

Slide 39

Slide 39 text

“Backend for Frontend” μS μS μS μS μS μS BFF Frontend http://samnewman.io/patterns/architectural/bff/

Slide 40

Slide 40 text

Multiple BFFs for different clients μS μS μS μS μS μS BFF Frontend BFF Frontend BFF Frontend Imagine more arrows here

Slide 41

Slide 41 text

Multiple channels – facing every user Browse product Pick recommendation Buy Check status Comment

Slide 42

Slide 42 text

Users expect a seamless experience across channels  – everything accessible, everywhere.

Slide 43

Slide 43 text

Build services that actually do something Process Flow Presentation Domain Logic Data JDBC in disguise Useful and specific Re- usable and low- level

Slide 44

Slide 44 text

Assumption: Services matter most (a.k.a. “SOAs Original Sin”) UIs matter more.

Slide 45

Slide 45 text

μ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

Slide 46

Slide 46 text

Redundancy with Multiple BFFs μS μS μS μS μS μS Frontend A Frontend B Frontend C

Slide 47

Slide 47 text

Ideal world UI componentization μS μS μS μS μS μS FE μS μS FE Not all μS need a UI “Vertical”  Responsibilit

Slide 48

Slide 48 text

SCS: Self-contained Systems http:/ /scs-architecture.org

Slide 49

Slide 49 text

Backend Platform More than one platform μS μS μS μS μS μS Frontend Platform FE μS μS FE

Slide 50

Slide 50 text

Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App Frontend, we’ve got frontends Frontend Hybrid

Slide 51

Slide 51 text

Web UI Integration: Links System 1 System 2

Slide 52

Slide 52 text

Web UI Integration: Redirection System 1 System 2

Slide 53

Slide 53 text

Web UI Integration: Transclusion System 1 System 2

Slide 54

Slide 54 text

Web UI Integration: Web Components System 1 Component

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App What about other approaches? Frontend Hybrid ✔ ✔ ✔ ?

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App What about other “modern” web apps? Frontend Hybrid ✔ ✔ ✔ (✔) ?

Slide 59

Slide 59 text

Assumption: JS-centric web apps can  be as good as native apps They shouldn’t be as bad!

Slide 60

Slide 60 text

“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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

$('.multiselect', context).each(function() {  $(this).multiselect({  selectedList: 2,  checkAllText: "Alle",  uncheckAllText: "Keinen"  }).multiselectfilter({label:"",  width:"200px"});  });

  Project    DISCOVER  IMPROVE  MAGENTA  ROCA  ROCKET   

Slide 63

Slide 63 text

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)

Slide 64

Slide 64 text

ROCA: Resource-oriented Client Architecture http:/ /roca-style.org

Slide 65

Slide 65 text

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.

Slide 66

Slide 66 text

Maintaining Consistency

Slide 67

Slide 67 text

Challenges & Cross-cutting Concerns Single sign-on End-to-end testing Visual consistency Re-use Skill transfer

Slide 68

Slide 68 text

Visual Components • Design System • Style guide • Pattern library http://styleguides.io

Slide 69

Slide 69 text

Style Guide Challenges • Possible centralization & resulting bottlenecks • (Semi-)manual workflow • Copy/paste & resulting redundancy & overhead

Slide 70

Slide 70 text

Recommendations

Slide 71

Slide 71 text

1. Know where your problems are

Slide 72

Slide 72 text

2. Beware of the monolith …

Slide 73

Slide 73 text

3. … unless it makes sense

Slide 74

Slide 74 text

4. Create evolvable structures

Slide 75

Slide 75 text

5. Embrace the Web

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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