All we need to do is take these lies and make them true (somehow)
from http://www.tensegrity.hellblazer.com/2009/10/all-we-need-to-do-is-take-these-lies-and-make-them-true-somehow.html
Having
worked in OSGi for quite a while, the most frequently asked question I
get on the technology is "what's the value proposition." Being a
rapacious capitalist at heart, I think this is an eminently fair query
from anyone looking at this OSGi stuff and scratching their head and
wondering why the heck they would even want to consider using this
technology in their systems. There's a non-zero and usually
non-trivial cost associated with changing technology - a cost which
usually grows in direct proportion to how "low" the technology is on
whatever technology stack you are deploying. OSGi is pretty low on
that technology stack, so it has the potential to be very disruptive
and hence very costly to an organization which adopts the technology.
Surely the benefit of making the switch should be at least proportional
to the costs and a prudent business would like to understand what
they're going to get for their trouble, and more importantly, their
hard earned money.
To answer this question, what I first ask is
that people think about their current environment. Assuming you're not
a startup - a domain which I'm not considering in this post - then you
are undoubtedly dealing with a mature system which is now or quickly
will resemble Frankenstein's monster more than anything else. If your
system is successful to any degree - and if it isn't, then we aren't
really having this conversation - what you find is that your system is
a victim of its own success. Grizzled veterans remember the "good old
days" when builds would take less than an hour and everyone could sit
in a room and share a common understanding of what the hell was going
on in this money maker of yours.
Sadly, one day you look up and
find that no one knows what the hell is going on anymore. Build times
- perhaps one of the more visceral measurements of complexity we have -
have jumped dramatically. These days, people fire off builds and then
go on lunch breaks. Worse, your projections are that in just a short
time in the future, the nightly "integration" builds you kick off will
still be running well after your developers have shown up for work.
It's at this point that one panics and decides that dramatic action is
required. Something MUST be done. Well, as long as that something
doesn't require any change to what you're currently doing - i.e. one
starts searching for a silver bullet which will slay this beast of
chaos that you've collectively created and return your life back to the
way things used to be. Before "IT" happened.
Now, this scenario is something that I'm reasonably confident
that everyone can relate to. It's the classic story of the inevitable
destination several turns of the software development cycle will
ultimately lead to. So the question is, how do we deal with this cycle
in a rational fashion and break its grip upon our systems?
Naturally,
I think that OSGi has something to do with the solution to this
problem. It's not the only thing that OSGi offers, but it's one of the
aspects of the system that provides the most understandable benefit
that is easy to explain using the problems that we all can relate to.
On
the right, I have a simple graph with two lines. The Y axis represents
"complexity" and the X axis is time. The astute observer will notice
that one line is linear and the other is non linear. My contention is
that the linear line represents the behavior of systems when developed
using OSGi, strictly from a modularity perspective. The non-linear
line represents systems when developed using what I'll label as
"traditional" technology.
One of the interesting things to note
is that the initial "cost" in complexity is actually higher in the
beginning of the system's lifetime for the OSGi based system. The
reason why is that modularity does have a certain fixed cost which
cannot be simply erased by waving hands. Understanding the basics of
any modular system requires some up front investment in time, training
and build infrastructure. Some thought needs to be put into the way
things are done. Developers need to be familiar with this technology
and understand the processes that are in place to maintain the system.
This is what I call the "cognitive burden" of OSGi.
In contrast,
you'll note that the so called "cognitive burden" of traditional,
non-OSGi technology is rather low, and continues to be lower than what
is required of the developer who works with OSGi for quite some time of
the system's lifespan. What this means, in effect, is that it's pretty
easy to get started in the traditional mechanisms, but it takes a bit
of work when you want to use OSGi.
However, what ultimately
happens to any successful system is that the complexity starts to go
through a non-linear transition. As I mentioned above, build times
start to sky rocket. Tests take forever, dogs and cats start living
together. Total anarchy appears on the horizon and threatens to drink
your milkshake - in more ways than one.
Basically, what happens
is easily explained by the geometric nature of connections. For small
numbers, things look pretty good. But as the number of subsystems and
people become involved, these connections grow geometrically and that
starts to suck pretty hard when you're well into the knee of the
curve. It's at this point that you start looking around for something
- anything - to get a handle on the situation and return things back to
the friendly, cuddly system you used to know.
The value
proposition for OSGi is that the time spent beyond the hard knee of
your curve is where you get your major benefit as a business. What
invariably happens when your system reaches this knee and it starts
punching you in the gut is that organizations start implementing more
oppressive bureaucracies to manage the geometric explosion.
Committees, meetings, high level pow wows - human systems start being
brought to bear on the exploding complexity of a system that used to be
so well behaved.
So, the value proposition of OSGi is that it
provides the mechanisms which can control this complexity. The
simplest being the module meta system which defines the dependencies
between cooperating components. And whether you agree that OSGi
provides the answer, or some other module system provides the answer
instead of OSGi, I would claim that this answer has to be
at least as good as OSGi.
The
ability of OSGi to handle complex systems as a set of interdependent
modules is kind of like toilet paper: Sooner or later, you're going to
want to use it. Naturally, as software developers, we simply cannot
reuse any existing system such as OSGi and consequently there will be a
lot of stupendously successful efforts which essentially recapitulate
much of what OSGi already provides today. Rather than seeing this as a
fundamental problem with OSGi, I see this as merely one of the best
forms of flattery - my mom always told me that Imitation Is The
Best Form Of Flattery, after all...
But
whether
you think there is something - perhaps proprietary, perhaps a
secret plan produced by your favorite vendor - that will supplant OSGi,
the fact remains that what it represents, both at the simple module
level and the far more useful service level (a topic of exploration of
another post), what will eventually become a common, accepted fact of
software development. Something that all the XP and Agile types will
have claimed to have known for centuries. Why? Because it solves the
hard problem of
geometrically escalating complexity. And solves it well.
Yea,
it's going to be something more that "gets in your way" at the
beginning. But only people who develop demos actually program in
isolation - and then throw the system away after the keynote - or those
who develop exclusively in "start up mode" will be primarily concerned
with how fast they can develop "teh quick and dirty". In the
real world, systems
accrete complexity over time. In the
real world, there are multiple existing systems that a "new" piece of
software has to integrate with to work. In the real world, new
software has massive dependencies on pre-existing systems - systems
that, when you inquire about them, you find that anyone who knows about
them has apparently "died".
Unfortunately, our industry pretty much seems to ignores stuff like
this. No one likes having to do extra work and sadly the people who
direct most of the infrastructure development simply don't build a lot
of applications that need to be maintained by a moderately skilled
workforce using the infrastructure technology they're developing.
Demo systems are invariably thrown away rather than carefully nurtured
like the cash cows that are the reason why you're developing for
whatever god forsaken system you're developing/managing as part of your
daily job. Sadly, much
of the razzle-dazzle is focused on satisfying what amounts to a sugar
rush. A quick fix that satisfies and what ever consequences of this
exercise are simply
forgotten after the targeted purpose of the demo is completed. The
result is that
all the focus is on the development of what amounts to green field
systems which is an experience that has little to do with the day to
day life of mining a large, successful application that has scores, if
not hundreds, of developers toiling away tirelessly at its impenetrable
hide. And I have yet to even mention the vast fields of integration
testers and system management entities (they aren't human, you know)
required to actually turn those bits into dollars.
So what is the value proposition of OSGi? In a nutshell, it's a
technology that pays off in the medium to long term, for systems that
are successful and have more than a handful of developers. That's a
hard sell for the attention deficit set, but something that is all too
familiar to those who are tearing their hair out, wondering why their
gentle purring kitten has become a mutant monster three stories tall,
threatening to destroy their cash cow and expected retirement plan.
We, as vendors, have the job of reducing this "cost" of OSGi. Part of
this is through tooling such as IDE integration and such. Part of this
is through education and evangelicalism - if you have been exposed to
the basics of OSGi, it's not that scary when you actually try to use
it, after all. Part of it is the development of frameworks which lower
the "cost of entry" into OSGi, such as the Blueprint specification.
However, for the foreseeable future, there will always be a non-zero
cost associated with OSGi - just as there is with more traditional
technologies. With time, this cost will become institutionalized and
part of the expected curriculum and best practice within the industry.
But for now, I have to write long winded blog posts on the issue,
hoping that some shred of lucidity comes across in the ramblings...