BT

"Wait, What!? Our Microservices Have Actual Human Users?" The Importance of UI Architecture

by Daniel Bryant on Feb 07, 2016 |

At the microXchg conference, held in Berlin, Germany, Stefan Tilkov presented “Wait, what!? Our microservices have actual human users?”. Tilkov proposed that current microservice discussions tend to be centered around backend topics, such as API styles, service lookups and scaling; and argued that it is of paramount importance to increase focus on how to structure what is arguably the most important part of a microservice application - the user interface (UI).

Tilkov, co-founder and principal consultant at innoQ, began the talk by examining the role of the frontend components within a microservice architecture, and presented the first of a series of assumptions, "orchestration is cheap". Although latency of communication within the backend of a microservices-based application may be measured in microseconds (e.g. intra-datacenter traffic), the typical latency of communication across the internet (e.g. client to application backend traffic) will be measured in milliseconds. This has caused developers to push orchestration and aggregation of data into the backend.

The ‘backend for frontend’ (BFF) pattern has recently gained popularity as an antidote for complicated orchestration on the frontend, but Tilkov suggested that the inherent properties of this pattern may not lead to the creation of an optimal implementation.

I don’t think [the backend for frontend pattern] is something that you want. I think this is something that happens to you, because you fix something that’s broken in the first place. Sometimes it’s a good choice and sometimes it’s a rational choice, but I don’t think this is a pattern we should follow.

Leading into the next assumption, ‘channels matter’, it was suggested that the BFF pattern is often implemented for each channel, such as web, tablet and native application, which can lead to the creation of many cross-service connections (and potentially fragile dependencies). Tilkov argued that channels may not matter, and instead users expect a "seamless experience across channel". Accordingly, building services that “actually do something” is a recommended practice. This also overcomes another assumption that was “SOAs original sin” - services matter most.

 

The fourth assumption presented was “frontend technology is an implementation detail”. This section of the talk began with the presentation of the typical backend goals of a microservice platform: no implementation dependencies, small interface surface, based on standard, independent deployment and autonomous operations. Tilkov asked the audience what the frontend platform analogy was, and argued that existing web-based technology such as links, redirection and transclusion, in combination with viewing the browser as a platform, met many of the goals presented for the backend.

 

The assumption that “frontend monoliths are OK” was argued as “sometimes valid”. Native frontends typically resemble server monoliths, with similar goals and constraints, and the techniques of organisation structure (“Conway’s law”), platform interfaces, release trains and discipline can be used to some degree to mitigate the common development and deployment problems.

The final assumption presented, “JS-centric web apps can be as good as native apps”, was countered with the response of “they shouldn’t be as bad!”. Tilkov asked the audience to question choosing the monolithic architectural approach if this isn’t required. With apologies to Phillip Greenspun, Tilkov presented a quote and warned the audience to avoid re-inventing browser integration features, accept some inefficiency, and avoid modularity a la Java EE or OSGi etc.

Any sufficiently complicated JavaScript client application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half a browser.

In conclusion, Tilkov proposed that few organisations are in the business of delivering APIs - UIs matter. Accordingly, frontend monoliths are just as good, or bad, as backend monoliths, and nothing beats the browser with regards to modular frontend delivery. Anyone who is considering, or is currently involved in, a move to a microservice-based application should consider the frontend architecture as just as important as the backend architecture.

The video for Stefan Tilkov’s “Wait, what!? Our microservices have actual human users?” talk can be found on the microXchg YouTube channel, and the slides for the presentation can be found on the innoQ website.

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Distributed UI Composition by Greg Liebowitz

For SPAs, one can split their app into Webpack bundles and lazy-load static files from the parent app. The static bundles are independently served from their respective microservices, and accessed by the client behind a reverse proxy (e.g. Zuul).

Re: Distributed UI Composition by Tom Reid

"served from their respective microservices"

This is not necessarily a disagreement, because I don't think there are any right answers. Each project and organization is different, and that which works perfectly for one organization will fail terribly for another. That said I felt the need to share a perspective based on some recent experience.

The notion that a UI module or bundle be "coupled" to or viewed as a part of a microservice can lead to problems. A microservice can serve many clients, and each client may have specific needs. If a microservice gets into the business of aggregating and doing lookups for data that it does not need, but that a client application needs, then what do you do for the second client with different needs, then the third, and so on? And at that point, is it still a microservice, or a gateway?

I am on a team building a microservice architecture with currently 2 composed client applications. We went down the route you mention above and it was super-painful. We found ourselves breaking the UI up into non-ui concerns instead of functional units, to align with the microservices. The UI and the microservice end up coupled in a way, at which point you no longer really have a microservice architecture, but a distributed monolith. All the overhead of microservices, and none of the benefits.

We have since started evolving away from that toward modular composed mini application that may be used to build many applications. Essentially with the idea that these are pieces of functionality that users and the business cares about. Gateway modules that align with these mini apps will serve the needs of the UX. Microservices can sit behind the scenes and remain small and simple, facilitating essential business process, and blissfully unaware of who or what is consuming them.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.