Federated Applications: E Plurbus Unum

Federated Applications: E Plurbus Unum

Many Teams, One App

·

2 min read

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 as needed.

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;

  • easily support multi-tenancy with 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 goals (i.e. a federation);

  • Don’t needless copy data from one location to another (ETL to a data lake)— move software to where the data is: support data mesh with software federation and code streaming

  • enjoy the benefits of a microservices implementation without the costs.

There are additional capabilities for which federation is necessary but not sufficient. They can be achieved by combining federation with additional design elements. I’ve covered some of these in previous articles or videos. See the links below.

Self-deploying applications: deployment automation that works anywhere How to deploy to any environment in seconds without deployment automationtrmidboe.medium.com