gembin

OSGi, Eclipse Equinox, ECF, Virgo, Gemini, Apache Felix, Karaf, Aires, Camel, Eclipse RCP

HBase, Hadoop, ZooKeeper, Cassandra

Flex4, AS3, Swiz framework, GraniteDS, BlazeDS etc.

There is nothing that software can't fix. Unfortunately, there is also nothing that software can't completely fuck up. That gap is called talent.

About Me

 

All we need to do is take these lies and make them true (OSGI)

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?

the-problem.pngNaturally, 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...

posted on 2010-02-26 15:20 gembin 阅读(586) 评论(0)  编辑  收藏 所属分类: OSGi


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

常用链接

留言簿(6)

随笔分类(440)

随笔档案(378)

文章档案(6)

新闻档案(1)

相册

收藏夹(9)

Adobe

Android

AS3

Blog-Links

Build

Design Pattern

Eclipse

Favorite Links

Flickr

Game Dev

HBase

Identity Management

IT resources

JEE

Language

OpenID

OSGi

SOA

Version Control

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜

free counters