Microservices are to Monoliths, What Web Agents are to ___________?

by Brad Johnson, on Oct 28, 2019 12:46:32 PM

barracuda-fish-ocean-66218

Whenever I’m discussing swimOS with someone reasonably technical, we invariably arrive on the subject of microservices. It makes sense, as microservices are a commonly understood architectural paradigm and represent many organizations’ first step towards a more decentralized software architecture. But there are some key differences between swimOS and microservices architectures. First and foremost, swimOS takes application decentralization significantly further than microservices. To understand how, let’s set a baseline understanding of microservices.

Here’s how RedHat defines microservices:

“Microservices are an architectural approach to building applications. As an architectural framework, microservices are distributed and loosely coupled, so one team’s changes won’t break the entire app. The benefit to using microservices is that development teams are able to rapidly build new components of apps to meet changing business needs.”

Under this definition, it’s a logical conclusion that swimOS is a flavor of microservices architecture. After all, swimOS is “an architectural approach to building applications,” and swimOS Web Agents are “distributed and loosely coupled.” So what makes swimOS Web Agents a step further towards true decentralization when compared with microservices?

Microservices Are Really Just “Microliths”

Microservices are really just “microliths,” in that they’re architecturally similar to a monolith-style application except that each microservice represents a subsystem of a larger application. Microservices then compose together to form the greater application experience. Just like when building a monolith architecture, a microservice will likely need to employ some combination of an application server, a database or file system, a data processor, and/or a message broker. The process of integrating and configuring each of these components must be repeated every time for each microservice. Likewise, each microservice must be operated, updated, and monitored separately.

This isn’t the case for the swimOS platform, which supports a different type of application architecture. Based on the actor model (similar to Akka), swimOS is a collection of stateful Web Agents. These Web Agents can be distributed across a heterogeneous mesh of machines and cloud VMs, but can collaborate peer-to-peer on a shared data plane. 

Web Agents are the Next Step Towards Data Decentralization

Here’s how I think of swimOS Web Agents. In computer science, a User Agent is software that acts on behalf of a user. For swimOS, a Web Agent is software that acts on behalf of a device, or even other software. And just like every User gets represented by a User Agent, every object in a Swim application gets represented as a unique Web Agent. 

This has a profound effect on how applications can be architected, deployed and scaled. For microservices applications, the bulk of engineering effort is spent integrating and configuring open source solutions together to build the microservice architecture. Only a fraction of development effort/time is spent coding actual application logic. Conversely, developers using swimOS only need to setup an appropriate runtime. The remaining of developer effort is spent coding the application logic as Web Agents, and swimOS automatically makes use of available compute/storage resources.

Furthermore, no significant effort is required to add new application features, additional devices, or new data sources. Developers can simply configure a new Web Agent type with any new data traits, and then define relationships to existing Web Agents in the system. This enables tight communication (via bidirectional, multiplexed WARP links) across Web Agents of different types out of the box (even across distributed compute environments). As such, SwimOS makes it easy to correlate multiple real-time data streams, create aggregations, and publish real-time streams of synthesized data. Doing the same with microservices can lead to major architectural challenges.

Learn More

Let us know what you're building using the open source swimOS platform. You can get started with swimOS here and make sure to STAR us on GitHub. You can also learn more about our enterprise product DataFabric here.

Topics:Stateful ApplicationsEdge Computingdistributed computingweb applicationsswimOSmiddlewareRESTWARPstreamingapijavaopen sourceopen source softwaremicroservicesdecentralized

Subscribe