A couple of weeks ago, some of you might recall, I discussed the application management (in the literal, rather than systems management sense of that term) situation as it pertains to the Linux, Solaris and Windows operating systems. My feeling was at that point that application management could be a differentiator on an operating system basis; not that the functionality needed to be added at the kernel layer, but rather that the ability or lackthereof to easily fetch, deploy and maintain applications on a given platform varied widely. After meeting with the folks from OpenLogic up in Broomfield (here’s a James mention of OpenLogic) last week, I can see that I’m not the only one seeing an opportunity here.
While I had a bit of difficulty actually finding their office – the joke was that they needed to put Google’s satellite imagery side by side with the map because it’s so inaccurate – I got the opportunity to sit down with both Andy Grolnick (VP of Marketing) and Rod Cope (CTO & Founder) for over an hour of in depth product discussion and demos. What I found was rather interesting, a product that has some similarity to some of the application/package management mechanisms cited in the above piece, but extended much further.
Their tool, BlueGlue, is a Java based app that supports the management and deployment of complex, heterogeneous open source infrastructures on either the Linux or Windows platforms (for the Sun and/or Solaris readers out there, yes we did discuss Solaris – and DTrace in particular – but no plans there as yet). BlueGlue can install any combination of components from a library of about 130 of the most popular open source projects (as well as sample applications & templates): Ant, Apache, Eclipse, MySQL, Tomcat, etc. While this feature might by itself be attractive to Windows users, who as discussed previously don’t have much in the way of native tools to manage non-Microsoft applications, Linux users are unlikely to be impressed solely by the ability to install applications because most have that already.
OpenLogic’s tool, however, does go beyond the abilities of the Linux package management tools I’m familiar with in a couple of areas. First, and most important from a developer perspective, is that the configuration, installation sequence , and post installation testing (pings and everything) is taken care of transparently. For example, let’s say I want to deploy an infrastructure for building a Java based web infrastructure: I can check off in the tool Spring, Struts, Hibernate and, say, MySQL and have them deployed and configured for me, with zero know how or intervention required on my part. It can even preconfigure applications in the library such as JBoss for external, commercial applications such as DB2 or Oracle.
Why is this important? Well, one of the criticisms of open source we hear frequently is that it’s too difficult to install, configure and manage on an ongoing basis. While I do take exception to this as a generalized statement, because my experience indicates that many of the major products are maturing rapidly in the ease of use and installation areas (see what the folks from Ubuntu, for example, have done for Debian’s installation process), it’s still a fair complaint in many projects. Witness my frustrations with setting up a Virtual Host on Apache, which could by just about any measure be considered a mature project. To be clear here, it’s not that engineering resources and devs can’t figure out how to get the products up and running, but more that time invested in that area can’t be considered well spent.
On top of the overall abstraction of some of the configuration complexities, the tool throws in the ability to parse the licenses (full text) easily – a nice to have for some of the legal departments who might wish to know what their developers are using, as well as manage preconfigured, custom application stacks across multiple users. Oh, and they’ll provide first level support for the applications stacks derived from their library.
My quibbles with the offering are twofold: first, it relies on a local rather than networked model for code, meaning that OpenLogic ships discs containing all of the requisite application code rather than making it available via some form of network connection. This seems to introduce an unnecessary element of latency into the process. Second, it’s been implemented as a standalone environment, while I (as has been covered here many times previously) would prefer to see at least the option for an Eclipse-style integration – as would many customers, no doubt. Andy and Rod took these areas of pushback constructively, however, and I’m sure they’ve heard similar feedback many times before.
Ultimately, I’m still undecided philosophically on where the best place for this type of functionality is: platform independent, specialist third party tool, or OS specific (and therefore differentiating) layer? Either way, however, one thing is clear: there’s a significant opportunity in abstracting infrastructure complexity for enterprises and ISVs alike. Will this type of offering be attractive to every engineer? Nope. Just as there are devs that prefer Vi and Emacs, so too will there be those that will eschew prebuilt and configured environments for something they built themselves. But for every one that does, there are many that don’t. So either way, I think OpenLogic’s worth a look to anyone building complex infrastructures based on open source components.
 Several times of the course of my development career I’ve been bitten by the installation sequence bug, in that it was not enough to simply install the various pieces of software I required – they needed to be installed in a very particular sequence in order to layer themselves properly. The fact that such sequences were not well documented did nothing to endear myself to the packages involved.