Web 2.0 Killed the Middleware Star
Tuesday, July 26, 2011 at 9:53AM The discussion culminated in what appeared to be the sentiment that middleware was mostly obsolete with respect to PaaS.
THE OLD WAY
Very briefly for those of you who are more infrastructure / network minded than application architecture fluent, let’s review the traditional middleware-based application architecture.
Generally speaking, middleware – a.k.a. JMS, MQ Series and most recently, ESB – is leveraged as means to enable a publish-subscribe model of sharing data. Basically, it’s an integration pattern, but no one really likes to admit that because of the connotations associated with the evil word “integration” in the enterprise. But that’s what it’s used for – to integrate applications by sharing data. It’s more efficient than a point-to-point integration model, especially when one application might need to share data with two, three or more other applications. One application puts data into a queue and other applications pull it out. If the target of the “messages” is multiple applications or people, then the queue keeps the message for a specified period of time otherwise, it deletes or archives (or both) the message after the intended recipient receives it.
That pattern is probably very familiar to even those who aren’t entrenched in enterprise application architecture because it’s similar to most social networking software in action today. One person writes a status update, the message, and it’s distributed to all the applications and users who have subscribed (followed, put in a circle, friended, etc… ). The difference between Web-based social networking and traditional enterprise applications is two-fold:
- First – web-based applications were not, until the advent of Web 2.0 and specifically AJAX, well-suited to “polling for” or “subscribing to” messages (updates, statuses, etc…) thus the use of traditional pub-sub architectures for web applications never much gained traction.
- Second – Middleware has never scaled well using traditional scalability models (up or out). Web-based applications generally require higher capacity and transaction rates than traditional applications taking advantage of middleware, making middleware’s inability to scale problematic. It is unsuited to use in social networking and other high-volume data sharing systems, where rapidity of response is vital to success.
Moreover as James Urquhart 
noted earlier in the conversation, although cloud computing and virtualization appear capable of addressing the scalability issue by scaling middleware at the VM layer – which is certainly viable and makes the solution scalable in terms of volume – this introduces issues with consistency, a.k.a. CAP, because persistence is not addressed and thus the consistency of messages across queues shared by users is always in question. Basically, we end up – as pointed out by James Saull 
- with a model that basically kicks the problem to another tier – the scalable persistence service. Generally that means a database-based solution even if we use the power of virtualization and cloud computing to address the innate challenges associated with scaling messaging middleware. Mind you, that doesn’t mean an RDBMS is involved, but a data store of some kind and all data stores introduce similar architectural and technologically issues with consistency, reliability and scalability.
THE NEW WAY
Now this is not meant to say the concept of queuing, of pub-sub, is absent in web applications and social networking. Quite the contrary, in fact. The concept is seen in just about any social networking site today that bases itself on interaction (integration) of people. What’s absent is the traditional middleware as a means to manage the messages across those people (and applications). See, scaling middleware ran into the same issues as stateful applications – they required persistence or a shared-nothing architecture to ensure proper behavior. The problem as you added middleware servers became the same as other persistence-based issues seen in web applications, digital shopping carts and even today’s VDI implementations. How do you ensure that having been subscribed to a particular topic that you actually manage to get the messages when the load balancing solution arbitrarily directs you to the next available server?
You can’t. Hence the use of persistent stores to enable scalability of middleware. What you end up with is essentially 4 tiers – web, application, middleware and database. You might at this point begin to recognize that one of these tiers is redundant and, given the web-based constraints above, unnecessary. Three guesses which one it is, and the first two do not count. 
Right. The middleware tier. Web 2.0 applications don’t generally use a middleware tier to facilitate messaging across users or applications. They use APIs and web-based database access methods to go directly to the source. Same concept, more scalable implementation, less complexity. As James put it later in the conversation, “the “proven” architecture seems to be Web2, which has its limitations.”
BRINGING IT BACK to PaaS
So how does this relate to PaaS? Well, PaaS is Platform as a Service which is really a nebulous way of describing developer services delivered in a cloud computing environment. Data, messaging, session management, libraries; the entire application development ecosystem. One of those components is messaging and, so it would seem, traditional middleware (as a service, of course). But the scalability issues with middleware really haven’t been solved and the persistence issues remain.
Adding pressure is the web development paradigm in which middleware has traditionally been excluded. Most younger developers have not had the experience (and they should count themselves lucky in this regard) of dealing with queuing systems and traditional pub-sub implementations. They’re a three-tier generation of developers who implement the concept of messaging by leveraging database connectivity directly and most recently polling via AJAX and APIs. Queueing may be involved but if it is, it’s implemented in conjunction with the database – the persistent store – and clients access via the application tier directly, not through middleware.
The ease with which web and application tiers are scaled in a cloud computing environment, moreover, meets the higher concurrent user and transaction volume requirements (not to mention performance) associated with highly integrated web applications today. Scaling middleware services at the virtualization layer, as noted above, is possible, but reintroduces the necessity of a persistent store. And if we’re going to use a persistent store, why add a layer of complexity (and cost) to the architecture when Web 2.0 has shown us it is not only viable but inherently more scalable to go directly to that source?
At the end of the day, it certainly appears that between cloud computing models and Web 2.0 having been forced to solve the shared messaging concept without middleware – and having done so successfully – that middleware as a service is obsolete. Not dead, mind you, as some will find a use case in which it is a vital component, but those will be few and far between. The scalability and associated persistence issues have been solved by some providers – take RabbitMQ for example – but that ignores the underlying reality that Web 2.0 forced a solution that did not require middleware and that nearly all web-based applications eschew middleware as the mechanism for implementing pub-sub and other similar architectural patterns. We’ve gotten along just fine on the web without it, why reintroduce what is simply another layer of complexity and costs in the cloud unless there’s good reason.
Viva la evolution.
Related Articles
Reader Comments (6)
An enterprise IT system is made of many heterogeneous systems -- a mix of made, purchased and rented solutions... all of them potentially addressing very different business domains (HR, sales, manufacturing, after-market, finance...), and with their very own life cycle & governance (& politics).
Using a middleware within a single software solution dedicated on solving one business need is probably overkill (one layer of unneeded extra complexity)... and asking for troubles; I clearly agree on that point.
However, looking at the whole picture, using a middleware to integrate those heterogeneous systems together is not a silly idea at all, or even a thing of the past. IMHO, it has never been so relevant: a middleware is tool that clearly has it's use, even in a Web 2 / cloud based mindset -- even more I would say, as it bring much needed loose coupling between different vendors' solutions.
(speaking from my own experience, designing & building IT solutions for both a large company and a small start up!)
I cannot agree with such interpretation as author puts it. Generally solution architecture described as "the new way" is very limited - and IMHO problem of integration is just pushed one layer below (being persistence) where all of "unnecessary complexity" will have to be solved (i.e. concurrent writes, queuing, cascading etc.). I'd really like to see, how in this "new way" solve a use case, where 2 different applications manages data update of the same persistent entity, because scalability in this case is usually done by using so called NoSQL (or better "Eventually consistent data store") - but this is not an always available option. So yes - i rather agree with Cedric, that this solution is only valid for "single purpose" applications which by design do not integrate with external systems, where I understand middleware to be solving exactly this problem (being integration). There is a lot of new tools/solutions solving this problems in a "Web 2.0" way, but nevertheless, at the end of the day, EIP will have to be executed somewhere and as soon as it gains significant complexity (because of realized business requirements) it will become candidate for separation from the "App tier" - and one is back at the beginning - is it a middleware then?
Agree with Cendric M. The article misses the point that middleware is supposed to be used in the enterprise application integration world (EAI) were you may have both in-house developed and COTS applications written in dozens of languages and platforms (mainframes anyone?) spread over numerous ownership domains. It is not the case for social web apps which are usually more or less monolithic from the enterprise architecture point of view, so you don't really need any sort of middleware internally.
Agreed with 'missing the point' posts. The problem of distribution has to be solved whether its in the middleware or at the database layer. Like Igor,you need an open middleware layer to integrate different application services.
If you're just knocking up a web app which is simple and isolated then scalability isn't a problem, even at large numbers. Yes, when you get to 500 million daily users you may have a bit of an issue, but even large webapps we see on here are based on mysql with an in-memory cache of some kind.
Interesting article. Would I use a message bus if I were writing Facebook or Twitter? No - too much contention, need something simpler to go fast. LMAX came to a similar conclusion not to use queues when they were developing their disruptor pattern to handle 100k trades/second - they lost so much performance through all the required locking.
But would I use a message bus for integrating internal systems with a corporate office, with less extreme performance needs? Yes - benefits of generic pub/sub over polling/bespoke point-to-point integration are hard to deny.
Wow! This is great example of why you should always read the comments to a blog post.
Good post, and also great comments.