OSGi: A New Cake for the Data Centre

Speaking at Burton Group's Catalyst Conference in Prague, Drue Reeves, VP and research director for Data Centre Strategies says:

Data centres must be more dynamic, especially in today's rapidly changing markets and economies, but organizations can only change as fast as their infrastructure allows.

According to Drue, the Dynamic Data Centre is all about having an agile, fluid IT infrastructure that can automatically change to meet business demands.

What’s on servers in data centres? It turns out that application servers take up a decent percentage of the server estate. At the financial services firm I worked for nearly 50% of servers in the data centres were dedicated to running application servers and this figure is fairly typical.Drue asked me how OSGi fits into the picture of improving operational agility, so I’m going to start answering that by looking at how we deliver the Java applications hosted on those servers.

Enterprise Java program design has matured to an art form. We create loosely-coupled components and carefully layer them on top of each other. Then, we do the artless bit: the packaging. We stuff all the components and all their dependencies into one monolithic archive file for deployment into an application server.Kirk Knoernschild describes the problems with packaging and deploying Java applications this way in his “OSGi in the Enterprise” overview:

Small changes, even if isolated to specific areas of an application, require packaging and redeploying the entire application and often a restart of the JVM instance hosting the application. Transitive dependencies among JAR files when adopting new frameworks are difficult to manage. Homegrown frameworks must be deployed with each application that uses them. Dealing with the problems of multiple class paths is a burden when troubleshooting runtime errors. Fighting through the problems encountered when different JAR files contain the same fully qualified class is painful. The amalgamation of each of these issues, combined with many others that tend to surface, reveals a packaging and deployment model that is broken.

That sounds bad. And it is bad. It’s certainly a maintenance and operations nightmare. And it’s not going to give us the agility we need to move and change those applications dynamically around the data centre. It’s like designing and creating an incredibly elaborate layer cake, then throwing all of it into a big sack. If we want to replace any of it, we have to take it all out, add a different kind of chocolate and build it all again.

OSGi gives us a way to package and deploy each of the layers and tastes separately, more like a bento box than a squashed cake. If you don’t like chocolate mousse, fine. Swap it for a lemon tart. It doesn’t affect the taste of the rest. If the crème brûlée has turned, you don’t need to return the whole box for a new brûlée If the chef demands you eat the tiramisu with the apple sorbet, that’s easy. If we’re sharing the desert and we both want vanilla ice cream, but you want the Madagascar variety, that’s okay, we can have our own versions.

Sure, so OSGi give us a better way of packaging and deploying Java applications. So what?

Well look behind this and it is actually a big deal. OSGi solves some of the thorniest Java deployment and operations problems, namely:

• Eliminates application dependency problems No more guesswork. No more tracking down classloader problems in production. OSGi requires explicit declaration of dependencies between modules.

• Minimizes footprint. Application servers and their hosted services can be “right-sized” by allowing administrators to build the minimal Java application platform. Only the bundles with the explicitly required capabilities will be installed. The platform will dynamically adapt by loading capabilities on demand.
• Solves versioning problems- multiple versions of the same software module can be deployed within the same JVM instance.
• Enables hot deployment - modules can be deployed and updated within a running system without restarting the application or the JVM.

Solving these problems breaks down barriers to Java application mobility and supports changing the workload dynamically as demanded by Drue.

Platform vendors are all busy rebuilding their application servers based on OSGi. There are 2 flavours of OSGi fit out you can see them doing: retrofit and ground-up. You can roughly interpret that as “OSGi for me” and “OSGi for everyone”. SpringSource’s Adrian Coyler characterises the “OSGi for me” vendors as saying:

I happened to use it internally but there's no real way you could tell; it's just my private way of partitioning out my internals

The ground up, “OSGi for everyone” platforms, of which SpringSource dm Server and Paremus’ Infiniflow are good examples are not only building an “a la carte application server”, but exposing the full capabilities of OSGi to enterprise applications.

Is OSGi ready for the enterprise and perhaps more importantly is the enterprise ready for OSGi? Kirk Knoernschild answers these key questions in his “OSGi in the Enterprise” and in recent blog posts: here and here. Certainly the enterprise data centre is ready for technologies that enable fluid and adaptable configuration of workloads.