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;
• eliminate the trade-off between the complexity of distributed systems and the benefits of deployment independence, i.e. you don’t have to put up with the former to get the latter;
• eliminate the need for deployment automation;
• deploy to any cloud or platform, regardless of differences between vendors or methods of compute delivery;
• deploy faster, MUCH faster;
• dynamically redistribute software to where it is needed, e.g. edge networks, mobile (to support use cases like federated learning);
• easily support multi-tenancy with isolated, customized code and data;
• share code without the need for a monorepo;
• support an agile organization with a multitude of smaller teams that work independently but toward the same larger goals (i.e. a federation);
• enjoy the benefits of a microservices…