Moving from OSGi to Akka – and why we knew after 5 minutes that it was a good idea

3 comments Written on June 1st, 2012 by
Categories: Tech, Uncategorized
Tags: , ,

We want to share some of our experience of developing with OSGi for 1,5 years and finally moving to Akka as a replacement. We hope you you find it useful to read about our experiences, that it helps you to ask the right questions when selecting a framework for your software, and we hope you enjoy it ;) .

Why using OSGi at all?

For our first product idea, described in our Nodalities article, extensibility in the form of plugins that add functionality has been an important technical requirement. We therefore decided to go for OSGi, as we had some experiences with it from Semaplorer. In general it seemed to be a good idea at that point in time [tm].

However, with the evolution of our product idea towards Smart Keywording, the priority of technical requirements also changed. For our first demo we stayed with OSGi, which enabled us initially to provide it in time for CeBit. However, in the following months OSGi became more and more a resource killer. At times, we spent more time fixing our builds, or working around OSGi limitations, than implementing features or improving our algorithms. And one of the main features of OSGi, exchanging functionality based on plugins, was hardly required. Finally, we decided to get rid of OSGi and switch to Akka. We literally knew after 5 minutes that this was a good idea. In this blog post we are going to tell a bit what was annoying with OSGi, and how we have much less issues with Akka.

Just a warning beforehand. This article is highly subjective. We are talking about some experiences on a very high-level. There are reasons to choose Akka, and there are other reasons to choose OSGi, or a specific implementation of it. It highly depends on your requirements, and probably also on the way you develop software. For us, the switch to Akka was mainly positive, but this must not be true for you. So read with care!

Build eco system

Having a good and reliable build system is key to providing software. We are constantly updating our services using a continuous deployment pipeline. Building Akka applications is not different from building any other Scala application. We use sbt with the xsbt-start-script plugin to build our backend into a deployable artifact. We use sbt-revolver during development to start and stop our services from within a sbt session. And we use quite a number of great open source libraries, that are available as dependencies directly for consumption with sbt (i.e. as maven or ivy artifacts). Building and deploying our software using this infrastructure is a no-brainer. As IDEs we use the Scala IDE and recently I personally started to switch to Sublime Text 2 and Ensime.

With OSGi that was different. There is Tycho as a quite sophisticated maven plugin that provides the means to build OSGi applications based on the Eclipse Equinox/RCP platform. Tycho made great progress during the period we used it, but the whole OSGI/Equinox/RCP framework is just ways more complex than building an Akka application. And basically you have a lock-in situation. When your build runs with Tycho, you need to use the Eclipse RCP eco-system. Everything else is not really feasible. Furthermore, you can not consume normal dependencies, but you need bundles. Often you have to build them on your own. Many frameworks need significant manual work to be run in OSGi. We invested days of work in getting Jersey and Guice running in Equinox, or to get Sesame up and running. Eclipse provides some nice tools for developing RCP applications, but regularly we encountered problems with our product or feature definitions. We needed to remember millions of things in order to get reliable and reproducible builds. So, building our application was basically following the same steps as our Akka based build, but it was much more involved without providing any substantial benefit.

Dependencies

We already mentioned it before. Dependencies are a problem in OSGi. Of course, you have more ways to specify and ensure that you consume the right dependency. But in order for that to work you need an OSGi bundle. Many frameworks provide such bundles, but especially in the Scala world is not common to provide bundles. So, our choice for the right library was often led by whether it was available as a bundle or not. Or we invested time to build a bundle ourselves.

However, our practical experience showed us, that the additional control over the dependencies provided by OSGi was not beneficial for us. We never required this feature, probably because we completely control our software. Seriously, having granular control over what packages your bundle imports or exports in what version sounds great, but really think about whether you need this control or not. We migrated our software to Akka, and there was not a single issue with dependency versions or package conflicts.

Tooling

What I am going to say now, is my personal view and not necessarily the view of the company, but I think tooling is often overrated for software development. Eclipse provides many nice editors, views, and wizards for anything required to implement OSGi software. And the same is more and more true for Scala development as well with the Scala IDE. However, I recently switched from Eclipse + Scala IDE as my development environment to Sublime Text 2 + Ensime + sbt. The latter have less features, but they are faster, more responsive, and closer to the final build eco system. The switch just happened a couple of days ago, so I am still in the process of finding out whether I will continue to use them, or whether I will switch back to the Scala IDE. But currently, I enjoy developing software with such a rather minimal environment.

However, the general point here is the following. There is in fact lots of tooling for OSGi, but the very fundamental problem is that you need all that tooling. You don't have the choice. I don't want to write OSGi applications just with an editor and a build tool. When you try to develop a non-trivial OSGi application without a sophisticated IDE you are doomed, IMHO. But I can do it with Scala and Akka. Frameworks should be there to help you develop your software more efficiently, and should not start to stand in your way. In this respect, Akka clearly wins over OSGi.

Agility

This brings me to another important aspect. Agility. We are a startup, and our most important tool is our agility. We need to try out new ideas fast, to test new features, or to implement fresh requirements. We don't have a long-lasting release plan, but we learn and adapt continuously. Now, being agile is mainly a question of your workflows and processes. But in OSGi adding new features or changing components was often more problematic. Partly due to the issues we mentioned before, i.e. the problem with the dependencies or the more fragile builds, but also due to the fact, that a typical OSGi based architecture assumes clearly defined APIs that hardly change etc. Now, don't get me wrong, when you want to write good software you need good and clean code, and having well defined APIs clearly helps, as does a good architecture and design. But, sometimes it is more important to add a feature fast with minimal effort. Especially, when you don't know whether the feature is really a good idea or will be thrown away the next week anyway. Doing this in Akka is just simpler and faster, and thus it supports us in being agile. Of course, you have to handle your technical debt appropriately.

So, to make this clear. I am convinced that agility is a question of the right processes and the right people, and not a question of tools. So, you will be able to develop your software with OSGi in an agile way (we did so), and you will be able to develop software in Akka using the waterfall method (we didn't). But from our experience, there are tools that better support you with being agile, and tools that offer greater resistance in that respect. For us, Akka clearly provides less resistance than OSGi.

Architecture and algorithms

One last point I would like to mention is the architecture and the software itself. Both Akka and OSGi have commonalities and differences. Akka is event driven, and provides the actor as an abstraction of functionality that can be triggered from outside. OSGi uses the idea of services for a similar purpose. OSGi has a stronger focus on being able to exchange implementations, while Akka clearly focuses on concurrency and distribution. So it's a matter of your requirements, whether the one or the other seems to be a better choice. In our case, we have requirements that better fit Akka, and requirements that better fit OSGi. But eventually we were able to satisfy our requirements with both. Akka and OSGi have a different focus, but in our experience both were valid candidates for our backend. Therefore, choosing the right one is not so much a technical question, but rather a question of the team, their preferences, and their development process.

Summary

We decided to write this blog post, since we read a lot great articles before from people who share and communicate their experiences with technology and their business. We thought it is about time to share some of our experiences from our switch to Akka. Akka and Scala are both gaining attention and are increasingly used in production, but still it seems to be a bit of an exotic choice. We used Scala from the very beginning, also to write our bundles for the OSGi-based prototype, and we never regretted that decision. But the switch to Akka reinforced us in our decision to develop within the Scala ecosystem. And this was clear after 5 minutes of developing with Akka.

We will probably continue with this kind of blog posts, in order to show that using Scala and and its ecosystem, tools, and libraries are a great choice for software development, especially if you need to be agile and lean. We hope you enjoyed reading about our experiences, and we are happy to receive your feedback.

Tags: , ,

3 comments “Moving from OSGi to Akka – and why we knew after 5 minutes that it was a good idea”

We also thought to go with Osgi and Scala. As you wrote there seems to be nearly zero Osgi support/integration of Scala with Osgi. That’s the reason why I found this post.
But to be honest I do not understand what it means to migrate from Osgi to Akka. I thought those are completely different things? The one is a system for modularization and the other is about concurrency isn’t it?

Certainly, OSGi and Akka have different focus. But depending on why you choose one or the other, it might be possible to migrate. In our case, we initially had a different system in mind. Initially, we wanted to have a core system that can be extended by plugins, similar to how the Eclipse ecosystem works (though our product never was a rich client app). But we then pivoted away to providing SaaS, so that plugins have not been an issue anymore. We were able to do all the wiring either at compile time or by registries (e.g. to use different algorithms controlled on a per request basis).

Fact is that OSGi provides some building blocks to get this functionliaty, but we had to write a lot of code to really get it working. The different specs are not really integrated (e.g. Declarative Services and Config Factories, IIRC). Then we always had to fight with the manifests. Eclipse and Tycho are of great help, but it was always a hassle, especially if a new dependency or module was introduced. With Akka, you can do very similar stuff. An actor is basically a service. The API is defined by the messages it reacts to. You can wire actors by name. Building a system whose behavior can be changed during runtime or on a per request basis is extremely simple compared to OSGi. With remote actors, you can easily let actor systems communicate (something that OSGi does not really provide). And one of the main promises of OSGi is to provide you great depdency management. But honestly, this has not been an issue a single time so far. In contrast, with OSGi we had far more dependency hell, since we had to get OSGi bundles, which are not available for each library, fix issues if bundles were not build correctly, be very careful with versioning of our own bundles, and so on.

So, in our specific case, we used functionality that is available in both OSGi and Akka, but Akka was just easier to use. And, with Akka you get concurrency for free (at least if your architecture uses actors and events correctly). But it is also clear that something like Eclipse is very likely better built using OSGi. It depends on what you want to accomplish.


Leave a Reply