Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Wait, What!? Our Microservices Have Actual Human Users?

Wait, What!? Our Microservices Have Actual Human Users?

Presented at Dublin Microservices Meetup

Stefan Tilkov

May 25, 2016
Tweet

More Decks by Stefan Tilkov

Other Decks in Technology

Transcript

  1. Wait, what? Our microservices

    have actual human users?
    Stefan Tilkov, innoQ
    @stilkov

    View Slide

  2. μS μS
    μS
    μS μS
    μS
    Frontend
    So you want to do microservices …
    What is this thing?
    What is this line?
    Is it the same as
    this one?
    Where does it run?

    View Slide

  3. Challenging Assumptions

    View Slide

  4. Assumption:
    Orchestration is cheap
    No.

    View Slide

  5. “Really remote” vs. “almost local”
    μS μS
    μS
    μS μS
    μS
    Inside DC;

    Latency: μs
    Frontend Typically Internet;

    Latency: ms

    View Slide

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

    View Slide

  7. Assumption:
    Channels matter
    Not as much
    as you think

    View Slide

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

    View Slide

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

    View Slide

  10. Users expect a seamless
    experience across channels

    – everything accessible,
    everywhere.

    View Slide

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

    View Slide

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

    View Slide

  13. μ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

    View Slide

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

    View Slide

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

    Responsibility

    View Slide

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

    View Slide

  17. Assumption:
    Frontend technology is an
    implementation detail
    Not at all.

    View Slide

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

    View Slide

  19. Microservices backend platform goals
    > As few assumptions as possible
    > No implementation dependencies
    > Small interface surface
    > Based on standards
    > Parallel development
    > Independent deployment
    > Autonomous operations
    Backend Platform

    View Slide

  20. What’s the frontend platform analogy?
    > As few assumptions as possible
    > No implementation dependencies
    > Small interface surface
    > Based on standards
    > Parallel development
    > Independent deployment
    > Autonomous operations
    Backend Platform
    Frontend Platform

    View Slide

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

    View Slide

  22. Web UI Integration: Links
    System 1 System 2

    View Slide

  23. Web UI Integration: Redirection
    System 1 System 2

    View Slide

  24. Web UI Integration: Transclusion
    System 1 System 2

    View Slide

  25. Web UI Integration: Web Components?
    System 1 Component

    View Slide

  26. The browser as a platform
    > Independent applications
    > Loosely coupled
    > Separately deployable
    > Based on standard platform
    > Updated on the fly
    > Any device
    Backend Platform
    Frontend Platform

    View Slide

  27. 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

    View Slide

  28. Simple two-step secret to improving the performance of any website,
    according to Maciej Ceglowski (@baconmeteor):
    “1. Make sure that the most important

    elements of the page download and

    render first.
    2. Stop there.”
    http://idlewords.com/talks/website_obesity.htm

    View Slide

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

    ✔ ✔
    ?

    View Slide

  30. Assumption:
    Frontend monoliths are OK
    Sometimes.

    View Slide

  31. 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

    View Slide

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

    ✔ ✔
    (✔)
    ?

    View Slide

  33. Assumption:
    JS-centric web apps can

    be as good as native apps
    They shouldn’t be as bad!

    View Slide

  34. “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

    View Slide

  35. The web-native way of distributing logic
    Process Flow
    Presentation
    Domain Logic
    Data
    Server
    Client > Rendering, layout, styling

    on an unknown client
    > Logic & state machine on server
    > Client user-agent extensible via

    code on demand

    View Slide

  36. 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

    View Slide

  37. $('.multiselect', context).each(function() {

    $(this).multiselect({

    selectedList: 2,

    checkAllText: "Alle",

    uncheckAllText: "Keinen"

    }).multiselectfilter({label:"",

    width:"200px"});

    });

    Project

    name="project" size="5" multiple>

    DISCOVER

    IMPROVE

    MAGENTA

    ROCA

    ROCKET



    View Slide

  38. 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)

    View Slide

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

    View Slide

  40. Disclaimer: Not a fan of SPAs (see https://medium.com/p/f08bb4ff9134
    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.

    View Slide

  41. Summary

    View Slide

  42. Few organizations are in the
    business of delivering APIs
    – UIs matter

    View Slide

  43. Frontend monoliths are
    just as good, or bad,
    as backend monoliths

    View Slide

  44. Nothing beats the browser
    with regards to modular
    frontend delivery

    View Slide

  45. Stefan Tilkov

    [email protected]
    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
    Ludwigstr. 180E
    63067 Offenbach
    Germany
    Phone: +49 2173 3366-0
    Kreuzstraße 16

    80331 München
    Germany
    Phone: +49 2173 3366-0
    Thank you.
    Questions?

    Comments?
    @stilkov
    Image credit: The Noun Project

    Marek Polakovic, Arthur Shlain, Karthick Nagarajan

    View Slide