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.