As former student of literature, I’ve always been into language (specifically the English one!) and the shifting tides of meanings, and linking that language brings from one area of human activity to another. One word that resonates for me is the “dependency”. My title comes from a work I did I was when I was doing my Master in American Studies. As part of sessions on US domestic policy we looked at that concept of the “Dependency Culture”. The basic premise is an overly generous welfare programs leaves people “dependent” on the state for handouts – and make then unlikely or unwilling to search for work. The book we read at the time was called “Losing Ground” by Charles Murray.
It was the term “dependency culture” started me thinking about the “dependencies” we have in corporate IT systems – and the culture that causes those systems to be created and maintained.
Clearly, we’re “dependent” on such systems just to make the business function – but also I was thinking about the complex state of service dependencies a true multi-tier application possesses. This goes WELL beyond just VM1 must start before VM2. Often each tier of an application (Web, DB, Application) has many nodes within to offer redundancy (web01/web02/web03; DB01, DB02, DB03; App01, App02,App03). If the TCP sessions between each layer is not desecrate there’s likely to to TCP load-balancer – at the very least at the web-tier. Outside of the application – but to other infrastructure – the Virtual infrastructure; Server infrastructure; Network infrastructure; Security infrastructure (Firewall, IDS etc).
In the ideal world these dependencies should be loosely coupled – to allow for changes to take place at one layer, without a complete reconfiguration of another. My feeling is if the dependencies are too tightly coupled this leads to big problems. What do I mean by tightly coupled? Well, I mean within a tier when applications has series of features are interconnected – SettingA cannot be changed without affecting SettingB, C, D, E, and F… For me there’s two outcomes from this – firstly, the adoption of a technology becomes stymied by “Settings Anxiety”. The organization realises that setting A, B, C, D, E and F should be configured in such away they that NEVER need to change, because the change is so difficult and so catastrophic that no one would want to undertake it. Therefore an excess of time must be spent designing the configuration of the application – but also agreeing that with various stakeholders on what those settings should be.
Now you could argue that our dependency culture is a fact of life, and its our job to manage, maintain and protect those dependencies. Agreed, I have no real argument with that. My contention is that more dependencies there are the greater complexity. The great the complexity the increased chance that the application or service will fail. I see it as probability factor – an application with 21 dependencies is more likely to fail than one with only 3. The law of averages would decree the greater the number of the parts, the great the number of opportunities for failure or misconfiguration by the operator/administrator. Fundamentally, I think our industry is still building applications/services that are just too complicated in effort to pack in more features on an annual basis or as method of driving scale – by scaling out and adding more nodes. Invariably the vendors who build such application crow about its scaleability, whilst at the same time ignoring the administrative burden introduced by a scale-out model.
Why is this important? Well, at the moment some say that the barrier of getting “enterprise applications” into the public cloud – is they are not “designed for failure”. In that each of the components can be treated as cattle, rather than cats in terms of the impact if they fail or die. It’s part of many developers DNA to create systems that have complicated inter-connected dependencies. If they don’t start off with this – there’s a tendency that it grows to be so overtime – as the product “matures” and grows in popularity – more modules and parts are added increasing dependencies and complexities. Of course the solution to this is to build enterprise applications that are “cloud ready”.
BUT, and this big but (hence the capitals) as with life, that’s easier said than done. It’s a bit like saying the solution to obesity is people should eat less, or the solution to binge drinking is folks should drink less. It’s tautological in the sense that the solution to the problem, is not create the problem in the first place. This is where I feel out “dependency culture” kicks in. The important aspect is the word “culture”. It’s very hard to change culture, as any new CEO will tell you. You can tinker around the edges with organisation structures – but trying to change the way people think is the hardest thing to achieve. Personally, I don’t think people change the way they think or behave very often – unless confronted with a catastrophic paradigm shift – say when scientist demonstrated the earth revolved around sun. Even when the paradigm shift is obvious, the response of many humans is to merely pretend it hasn’t happened. That’s especially easy in our technology world where shifts are happening constantly. I personally think the next generation of “cloud aware applications” can’t be created by the current generation. It needs a new generation unfettered from the mental constraints of doing things “the way they have always been done”. In the meantime we will be lumbered with supporting complicated multi-tier applications that are resistant to cloudifcation.
Call me a pessimist if you like.