OK, file this under "food for thought." On second thought, maybe you shouldn't think about food and read this one.
Maybe you've heard news of a recent San Jose incident, in which the many leftover contents of a shared office refrigerator were emptied out for cleaning -- resulting in the evacuation of the office due to the smell and 7 people being hospitalized due to the toxic mix of fumes created from the cleaning process.
Fortunately everyone seems to be OK now. But it made me think of a disgusting, but kind of effective metaphor for shared computing environments. IT has focused much effort on making more room in the fridge, rather than better planning to decrease the need for a fridge.
At a desktop level, we already saw the complexity of systems increasing to follow Moore's Law. We are constantly increasing CPU speed, RAM, hard drive capacity, bandwidth, and the install size of the OS and many software packages seem to keep bloating to meet it.
In the enterprise, we saw the advent of SOA approaches - great if well planned, but nauseating for companies who started service-enabling everything and end up with JBOWS (Just a Bunch of Web Services) sitting around that couldn't communicate with each other.
Then came Virtualization - you could take 10 servers, or 100 system configurations, pack them up and deploy them as VMs on one machine with much less overhead. Awesome savings in hardware costs, but, eventually, like our fridge, you have a proliferation of many Virtual instances that can sit around past their expiration date.
Even with Cloud Computing you can experience this kind of pollution -- since provisioning costs are so cheap, even individual developers can throw an app into a Cloud environment with the relative ease of buying lunch on a credit card. What happens if some code is still referencing that instance, but the original owner forgets about it?
With today's flexible, decoupled software approaches, are we absolutely certain some part of a service or app we communicate with is not tied to some service down the line that has "gone sour?" And who judges which Services and virtual instances need to be turned off, when some dependencies aren't clearly labeled? "Whose, uh, thing, was this anyway..."
The answer to "rotten assets" lies in good architecture, a well thought-out plan of testing and rolling out services and Cloud instances around business needs that support the lifecycle (and not just convenience), and a strong governance approach that sets firm Policy (such as declaring expectations for use, expiration date, etc.), enforced with continuous validation that services are operating normally, whether real or virtualized. With some discipline, we have the means to keep our IT environments (and our shared office fridge, for that matter), a lot less cluttered.
Of course, you expect advice like that here. I just thought it was an interesting comparison and invite your thoughts on the concept!
Comments