Skip navigation

Twain's Open Source

Posted by marklittle May 24, 2015

Only a few years after the rise of public Cloud (essentially after a certain online bookshop offered its services to the public) I recall a number of people talking about how open source would no longer matter. The argument, which from 39000 feet made some sense, went something like this: people use open source because closed source equivalents are too expensive, often too difficult to use and generally just a way of accomplishing something "good enough" in a cheaper way. Because cloud offered capabilities, such as web server, messaging, storage etc. to developers on a pay-as-you-go basis, what did it matter if under the covers the implementations were based on closed source or open source? Therefore, people wouldn't approach developing solutions in the cloud by even considering the provenance of the underlying components.


Now of course even at that time you could argue that the argument didn't hold water at all levels. Specifically the operating system back then was predominately Linux based, which last time I checked was most definitely open source. In the intervening years we've seen Microsoft enter the space and whilst Linux is no longer the only operating system available in the clouds it's definitely still the dominant one. But that's not the only thing to change which drives a tank-sized hole in the original position. Today in all public or private clouds you don't have to look hard to find open source making it a reality. Whether it's OpenStack as the infrastructure, databases such as MySQL or MongoDB providing persistence, A-MQ or RabbitMQ for messaging, EAP/WildFly or GlassFish or Tomcat hosting some of the business logic, open source is integral to the success of public, private and hybrid cloud. Obviously there's a chance a developer may not know or even care that open source is responsible for the success of their application or business, but that doesn't negate the fact that cloud is successful today primarily because of open source.


There's also one important aspect that the original argument failed to take into account: users of open source are just one part of the overall value proposition; contributors/developers of open source are just as important. When you look at all of the examples of open source used in cloud I mentioned above, or go further and look at all of the others, you'll see that as well a individuals helping to develop these critical software pieces you've got pretty much all of the significant software vendors of our age as well as many of the most significant software users (verticals such as finance and healthcare, not to mention NASA).


Not exactly related to cloud, but when you get a company such as Microsoft making such an about turn on open source as they've done in the past year or so then it's probably a good bet that open source isn't dropping down the list of priorities for developers or companies. Therefore, to paraphrase and misquote Mark Twain, I think it's safe to say that reports of its death have been greatly exaggerated.

So I mentioned in a separate entry that I have problems with the term "web-scale". I get what the comment author is saying in that entry and I agree with several of the sentiments that are made but it did raise a few interesting thoughts in my head. Some of them I thought I'd addressed over the years but perhaps it is time to revisit. Or simply reference again in case your favourite search engine isn't working.


I've definitely addressed the issue of monolithic application servers in the past, whether through articles like this one or presentations. Monolithic application servers do exist, but there are application servers (Java and Java EE based) that simply don't match those characteristics. Whilst an application server may not be right for your use cases it's far better to rule it out based upon objective analysis than some (almost) subjective definition. I said a few months back that containers aren't all bad! Even as early as last year there were some good discussions about monoliths, microservices and balls of mud that would be well worth spending a few minutes reading and thinking about, because a knee-jerk reaction to a so-called monolithic architecture isn't necessarily going to give you the benefits you're after.


It's also interesting to think that the move we're seeing in the industry towards separate services is very much in line with what we had back in the CORBA days (something I've repeated a few times.) No, I'm not suggesting CORBA got it all right! Something else that was very much at the heart of CORBA was asynchronous invocations. This wasn't just something that was an add-on/bolt-on to synchronous APIs. Now in the transition from CORBA to Java EE we lost some of this work in favour of the more traditional (synchronous) RPC approach. If you've done your homework (or were around back then) you'll understand why RPC was (and still is) used so much in distributed systems: most of the languages we use(d) are procedural and it's natural to want to extend that paradigm to distributed programming and make remote invocations opaque. Now of course there are well know issues with this approach but that's not really the subject of this article.


The point I'm trying to make is that asynchronous programming isn't the domain of new languages and frameworks. Whilst I do agree that many of the APIs we have grown used to today are synchronous in nature and retro-fitting asynchronous approaches on top would be hard or impossible, it's worth remembering that there's often a good separation between interface and implementation in many mature implementations. For instance, some component implementations within various application servers date back to the CORBA days (or even further), and may have even been designed with asynchronous in mind. So whilst the APIs of some Java EE components may not easily be used asynchronously it's worth remembering that there is a large body of research and development which will help that rapidly evolving front of our industry build on much of what is there today, assuming of course that some implementations aren't there already. As I've said many times before, I hate reinventing the wheel.


Web-scale: a complaint

Posted by marklittle May 10, 2015

An interesting comment to an entry I made the other day got me thinking about "web-scale". It's a term I may have used. I know others have too. Yet WTF does it really mean?

Filter Blog

By date:
By tag: