Wait, what? Our microservices have actual human users?

Presented at MicroXchg 2016 Berlin

Transcript

1. Wait, what? Our microservices
 have actual human users? Stefan Tilkov, innoQ @stilkov microXchg Berlin
 5 February, 2016
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?
3. Assumption: Orchestration is cheap No.
4. “Really remote” vs. “almost local” μS μS μS μS μS μS Inside DC;
 Latency: μs Frontend Typically Internet;
 Latency: ms
5. “Backend for Frontend” μS μS μS μS μS μS BFF Frontend http://samnewman.io/patterns/architectural/bff/
6. Assumption: Channels matter Not as much as you think
7. Multiple BFFs for different clients μS μS μS μS μS μS BFF Frontend BFF Frontend BFF Frontend Imagine more arrows here
8. Multiple channels – facing every user Browse product Pick recommendation Buy Check status Comment
9. Users expect a seamless experience across channels
 – everything accessible, everywhere.
10. Build services that actually do something Process Flow Presentation Domain Logic Data JDBC in disguise Useful and specific Re-usable and low- level
11. Assumption: Services matter most (a.k.a. “SOAs Original Sin”) UIs matter more.
12. μ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
13. Redundancy with Multiple BFFs μS μS μS μS μS μS Frontend A Frontend B Frontend C
14. Ideal world UI componentization μS μS μS μS μS μS FE μS μS FE Not all μS need a UI “Vertical”
 Responsibility
15. Assumption: Frontend technology is an implementation detail Not at all.
16. Backend Platform More than one platform μS μS μS μS μS μS Frontend Platform FE μS μS FE
17. 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
18. 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
19. Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App Frontend, we’ve got frontends Frontend Hybrid
20. Web UI Integration: Links System 1 System 2
21. Web UI Integration: Redirection System 1 System 2
22. Web UI Integration: Transclusion System 1 System 2
23. Web UI Integration: Web Components? System 1 Component
24. 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
25. 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
26. 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
27. Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App What about other approaches? Frontend Hybrid ✔ ✔ ✔ ?
28. Assumption: Frontend monoliths are OK Sometimes.
29. 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
30. Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App What about other “modern” web apps? Frontend Hybrid ✔ ✔ ✔ (✔) ?
31. Assumption: JS-centric web apps can
 be as good as native apps They shouldn’t be as bad!
32. 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)
33. Don’t build one single page app > Don’t reinvent browser integration features > Accept some inefficiency > Trade-off for framework independence > Avoid modularity à la Java EE, OSGi etc. Disclaimer: Not a fan of SPAs (see https://medium.com/p/f08bb4ff9134
34. Summary
35. Few organizations are in the business of delivering APIs – UIs matter
36. Frontend monoliths are just as good, or bad, as backend monoliths
37. Nothing beats the browser with regards to modular frontend delivery
38. Stefan Tilkov
 stefan.tilkov@innoq.com
 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