Tuesday, January 29, 2008

Service Monolith: Proposed OMC Anti-Pattern #2

Most software services developed and operated these days are increasingly more heterogeneous and distributed, and therefore, complex and hard to setup and manage. On top of all this, the rate of change seems to only go up. These trends can lead to an anti-pattern I've recently documented at the Open Management Consortium called "Service Monolith":

Complex integrated software systems end up being maintained as a single opaque mass with no-one understanding entirely how it was put together, or of what elements it is comprised, and how they interact.


I describe some common rationale for using this anti-pattern and some of its consequences. There are positive design patterns to avoid or mitigate the anti-pattern, too. I find one interesting solution that seems to be becoming more ubiquitous and sort of side steps the deeper problem: virtualization. Virtualization is one strategy for dealing with producing these complicated systems. Using this strategy you get the whole conglomeration working on one host, cobbling the pieces together using the preferred recipe, then "freeze dry" it as an operating system image that you can instantiate on another host. With the image in hand an organization can "stamp it out" as needed. This technique seems to work for small scale deployments but I haven't seen the approach work for maintaining large scale environments. Is this the sign of another emerging anti-pattern?

Edit (Damon 1/31/08):
This is a great quote by Kris Buytaert on his first booting of a vmware instance:
"And thus we joined the era of transferring an unmanagable image that everyone will copy around wile slightly modifying things and never placing them in version control . hence ending up one day with something nobody knows how we got there."

2 comments:

Anonymous said...

Why not manage the desktop into submission with one or two images, locked down via GPO's with no users rights to install software then stream virtualized applications with AppVirt. Silo the app. Everyone wants to throw dedicated VDI hardware at the issue when its not necessary. If apps won't play nice in the same space virtualize them into protected packages that won't install into the local system, write to the local registry or modify the OS.

In this scenario many thousand clients can have access to virtualized applications and the IT department can treat their PC base like toasters or telephones - SLA times for support go down to minutes - swap out the PC and the users apps stream back on authenticated login. We have a client school district with a mix of 10K desktops and laptops doing this.

Damon Edwards said...

dannymk:
I don't think this anti-pattern was really meant to refer to desktop management. In the design pattern the context says "Organizations that operate software as a service". I read that as meaning SaaS and e-commerce type applications. Desktop users and their inherently single-user productivity applications are a different kind of animal.

But even then I think this pattern has some applicability to how you manage those images. If you can't rebuild from scratch either the desktop image or those vm images using a specification driven, fully automated process you are still falling into the "Service Monolith" trap... even if in the short term things seem manageable because you can brute force it all "into submission" because the individual moving parts are still small enough.