Composite UIs for Microservices - A Primer
Posts in this series:
Microservices can be easy, if we never have to compose, orchestrate, or otherwise integrate between multiple services. If our inter-service communication is low, we can piecemeal a solution based on basic integration patterns such as messaging.
A land without composition and integration is when I have highly decoupled systems and business organization. If I strictly build systems around the organization structure, and if that organizational structure is entirely driven by capability and function, I can expect rather "thick" boundaries.
In idealized world, my boundaries are easy to define, with organizations using their own isolated systems and applications:
Each employee in each department only uses the applications and systems built for that department, and nothing else. There may be minimal communication between each system, perhaps some swivel-chair integration to accomplish workflows, or perhaps business is driven through emails (typical).
Autonomy can be "easy" for backend services, especially those that treat Conway's law as the defining boundary for services, along organizational lines.
Where things get a bit tricky to manage are cases when we need to compose multiple services to perform a task or present information. And where does this typically happen? For our customers, the most important user of our entire enterprise! Without a good customer user experience, they won't come back to buy our products or services.
The last mile
I tend to think of the customer experience as the last mile problem, delivering our services to the final end user. All of the other backend services don't exist without our customer, so it's critical that this experience is good.
Not all businesses have an application as their end user experience. For example, we might have a sales rep or agent as the connection or liaison between the customer and the back-end messiness of performing a business transaction.
We've all been a part of a bad end-user experience, where the services of the organization were not composed effectively for us. I see this the most whenever I call through customer support, where I just want a question answered but I'm shuffled around through various back-end departments before I can finally get someone to solve my problem. The details of the internal organization of the company were exactly exposed to me, without any encapsulation or composition.
If we want a coherent, cohesive end-user experience, and don't want to create a new monolith, we'll need to compose.
In the next few posts, I'll walk through the different areas we can compose, where each composition pattern makes sense, and some ideas on how we can build some extensions to UI application frameworks where composition isn't a first-class citizen.