Strong & Weak Decoupled Architectures

Me nattering on about decoupled architectures and cloud isn't anything new.  But I'm going to harp on it again as a follow up to last episode, maybe with a new twist.

Fundamental to the last notes on uptime, cloud resources are designed to be disposable.  This is a core architectural concept when dealing with elastic scalability.  If you are still looking to cloud while thinking about managing individual instances, need maintenance windows to patch things, and other individual system care and feeding tasks, you need to go back to the whiteboard.  And you need to design a production engineering team who can re-factor your architecture and operations run book to address wholesale replacement of all running instances when your application gets patched.

But let's set that aside for now and talk more about the role that decoupled architectures play in the cloud space.  We all know service oriented architecture (SOA) decouples monolithic applications into composable services.  SOA is where many folks’ enterprise application environments are these days.  We've got our message bus and we've built our standalone service components and everything talks through APIs so we're good to go.

In most cases, a standard SOA environment won't fail too badly if forklifted into a cloud.  SOA’s weak decoupling works fairly well as a starting pattern in a cloud environment.  There is another step to decoupling applications for cloud environments, something I'm going to call “Cloud Oriented Architecture” (Nomex underwear in place for the inevitable flames about using that term).  And I don't mean the same thing as Jason Bloomberg.  He focuses on a random term from the NIST definition and riffs on it.  I'm talking about an extension of the weakly decoupled application components that started with SOA that solve for a unique set of cloud architecture related problems.

So what, pray tell, is strongly decoupled COA?

Let me start with an example of weak decoupling.  Your SOA-based application deals with routing and regulatory decision points, so you included a business rules engine (JBoss BRMS, natch).  It runs on a virtual machine, subscribes to a pub-sub topic, processes your business logic, and all your analysts can write rules without being a developer.  All‘s well and good.  When you get more work, it does more work.  When that isn't enough, you add a second instance and try to load balance it or just make the virtual machine bigger.  The components that make up the rules engine are tightly (relatively) bound to one another to present a single service, Rules Processing.

Now let’s move to the cloud.  We have the same requirements to use a rules system, but our instances could have noisy neighbors; our inbound workloads may be more variable.  And scaling the whole BRMS instance is fragile because it likes to have characteristics of the traditional environment.  But rules processing, inbound ingest, analyst authoring, and demand for each of those functions can scale independently.

Why add more BRMS instances and load balance just to handle more requests?  Add a new rules engine to handle the increased queue depth.  Need to handle more applications?  Add a new message queue for the new kinds of messages.  More analysts need to run reports and author rules?  Stand up more UI nodes.

Each one of the sub-components of the overall BRMS solution can scale independently of the others because their workloads are orthogonal.  Since the interfaces between the components don't change, we can scale up or down as a particular need increases without having to add all of the other components.  When we further break the ties within the Rules Processing service (remember that?), we wind up with a strongly decoupled service.  Any of the components can be modified without breaking the outside view of the service, but it allows for scaling, maintenance, upgrades, and flexibility.  We can cope with noisy neighbors.  We can cope with Cyber Monday pricing discounts and shipping costs with sales tax.  We can cope with architecture changes between PaaS and IaaS.

We also see SLAs go up.  This sort of strongly decoupled service design for composed applications solves for the ephemeral resource problem; it solves for the "HA how-to" problem.  Since we are no longer concerned with a particular tightly coupled suite of suites to provide a particular functional requirement, we don't have to worry about clustering "the application servers."  I recently saw the install documentation for a web content management system that was "cloud-ready," that started with the creation of a 4-node active-active database cluster and when on from there - for web content management.  That's ridiculously overkill on bare-metal; it's pure insanity for a cloud deployment.

The ideas for a strongly decoupled service aren't some future thing; the JBoss folks are working on these ideas right now to provide Enterprise Suite capabilities for OpenShift.  The very origins and design of the integrated component-based Enterprise Suites makes this effort possible.  Maybe we'll see some other manufacturers following suit, but I wouldn't hold my breath.