Middleware seems like a dinosaur concept from enterprise client-server computing.  On the web, everything is open and anybody can connect to a service, so who would need Middleware?  Damn it, the whole Internet is Middleware!  Not so fast. Let’s revisit some of the enterprise issues that Middleware helps to address: scalability and flexibility.  The root of these tend to be the N*M problem and the bottleneck problem.  If you have N servers and M clients that all need to talk to each other you wind up with N*M connections between them.  Within the enterprise that could lead to having too much network traffic.   It also meant that if you changed one server you had to change M clients.  Finally, if you had a slow server, all the clients would be slow and there was little you could do about it other than try to improve the server (which might well be something from a vendor who might no longer be around or hold you up for a lot of money).  Middleware  – when done right – solved these problems.  The clients and servers connected to the Middleware, reducing the number of connections to N+M.  Changes to a server could take place without directly impacting the clients.  If a server was slow it is now possible to add caching to the Middleware layer without having to modify the server.

So do any of these arguments apply to the web?  I believe they do.  Obviously, one of the great strengths of Internet architecture is to remove central points of failure.  But there is also a cost to the many point-to-point connections.  There is overhead in terms of bandwidth and server power.  It may not seem like a lot, but many useful services out there are free or thinly monetized and would benefit from offloading.  Thats the problem Gnip is attacking (at some point though I will write a post on how polling is an abomination and should *always* be replaced by callbacks).  Mashery also helps with offloading by fronting APIs.  They also deal with a scaling problem that is much bigger on the open web than within the enterprise – the provisioning of API accounts.  Another scaling problem is one of learning.  If you are a small site, do you really have the time to figure out the competing (and evolving) implementations of identity by each of the big ones (MSFT, Yahoo, Google, Facebook, AOL and now even Twitter)?  No.  Thankfully, there is a Middleware service by Janrain called RPX.  You connect to it (1 API) and it connects you to everyone else, dramatically reducing the learning curve (I managed to implement third party signon for Dailylit in about 7 hours this weekend).  All of these three add the flexibility that comes with an additional layer of abstraction.  As long as Gnip, Mashery and Janrain can “remap” APIs within their Middleware services, this insulates service consumers from API changes by the providers.

Now some folks might point to the story of GrandCentral which tried to do just that as early as 2000.  I don’t think that would be a warranted conclusion.  At the time, web services were in their infancy.  Today, I can’t think of any company in our portfolio that doesn’t make use of web services, often for mission critical functionality.  That’s why the middleware services opportunity exists now.

Middleware seems like a dinosaur concept from enterprise client-server computing.  On the web, everything is open and anybody can connect to a service, so who would need Middleware?  Damn it, the whole Internet is Middleware!  Not so fast. Let’s revisit some of the enterprise issues that Middleware helps to address: scalability and flexibility.  The root of these tend to be the N*M problem and the bottleneck problem.  If you have N servers and M clients that all need to talk to each other you wind up with N*M connections between them.  Within the enterprise that could lead to having too much network traffic.   It also meant that if you changed one server you had to change M clients.  Finally, if you had a slow server, all the clients would be slow and there was little you could do about it other than try to improve the server (which might well be something from a vendor who might no longer be around or hold you up for a lot of money).  Middleware  – when done right – solved these problems.  The clients and servers connected to the Middleware, reducing the number of connections to N+M.  Changes to a server could take place without directly impacting the clients.  If a server was slow it is now possible to add caching to the Middleware layer without having to modify the server.

So do any of these arguments apply to the web?  I believe they do.  Obviously, one of the great strengths of Internet architecture is to remove central points of failure.  But there is also a cost to the many point-to-point connections.  There is overhead in terms of bandwidth and server power.  It may not seem like a lot, but many useful services out there are free or thinly monetized and would benefit from offloading.  Thats the problem Gnip is attacking (at some point though I will write a post on how polling is an abomination and should *always* be replaced by callbacks).  Mashery also helps with offloading by fronting APIs.  They also deal with a scaling problem that is much bigger on the open web than within the enterprise – the provisioning of API accounts.  Another scaling problem is one of learning.  If you are a small site, do you really have the time to figure out the competing (and evolving) implementations of identity by each of the big ones (MSFT, Yahoo, Google, Facebook, AOL and now even Twitter)?  No.  Thankfully, there is a Middleware service by Janrain called RPX.  You connect to it (1 API) and it connects you to everyone else, dramatically reducing the learning curve (I managed to implement third party signon for Dailylit in about 7 hours this weekend).  All of these three add the flexibility that comes with an additional layer of abstraction.  As long as Gnip, Mashery and Janrain can “remap” APIs within their Middleware services, this insulates service consumers from API changes by the providers.

Now some folks might point to the story of GrandCentral which tried to do just that as early as 2000.  I don’t think that would be a warranted conclusion.  At the time, web services were in their infancy.  Today, I can’t think of any company in our portfolio that doesn’t make use of web services, often for mission critical functionality.  That’s why the middleware services opportunity exists now.