For about 2 months now, LinkedIn has been actively working on a new iteration of its architecture: one that scales both from a customer point of view, and from a developer point of view. Our desire for modularity, decoupling, and service discovery led LinkedIn to look at OSGi for its new platform/container. Currently we’re using Tomcat for our frontend and Jetty for our backend. OSGi has the right properties that we believe will help us achieve our goal.
Probably one of the most known pieces of software that uses OSGi is Eclipse, the most popular open source IDE for Java (yes, it’s a lot more than that, but this is what it’s famous for). OSGi is a specification and Equinox is an open source implementation of the specification on top of which Eclipse is built. There are other implementations of OSGi, like Apache Felix and Knopflerfish. I went to the EclipseCon 2008 conference a couple of months ago to follow the OSGi track. The good news is that OSGi as a server container is getting a lot of traction as more and more people are embracing the new technology and seeing the advantages of what it can bring (multiple versions of the same class in the same container, dynamic updates of classes, etc.).
Moving to OSGi is not a trivial task as the programming concepts differ quite a bit from the more standard Java development lifecycle we are used to. Furthermore, the tooling is currently in its infancy. At LinkedIn, we have a pretty big code base, so it makes the migration all the more challenging.
In this series of posts on OSGi at LinkedIn, we are going to share our experience with OSGi, our pain points as well as our progress and successes. In the process, we will share some of the internals of how LinkedIn is currently built. In the next couple of days, I’ll be writing about how I was able to make our own (proprietary) JSP compiler work within an OSGi container.