Federated Applications: E Plurbus Unum
Many Teams, One Application
I’ve written several articles on this topic now, each time trying to refine the idea and explain it from a different vantage. This short article provides an executive summary of the others.
Because the term microservice is well known in cloud-native application design, I’ve employed it in my descriptions of what might be more perspicuously called, federated application components.
A federated app is one whose components:
- are loaded from multiple network locations and repositories at runtime;
- can run together in a single process;
- can be reloaded at any time without restarting the process or interrupting other components running in the process;
- are not installed on the server but streamed over the network.
In a federated architecture, microservices can be implemented as federated application components without loosing any of the main qualities that make them valuable, like deployment independence. So why is this relevant? As detailed in previous articles, there are several reasons. Let’s quickly review them here.
With application federation you can:
- eliminate the microservice premium;