ESB vs REST (Another Case for Multi-Language Programming)

Steve Vinoski recently threw a lit match into the proverbial dynamite shack with his blog post, “The ESB Question“.   Steve’s background and credentials (he was a very senior player at Iona) are impeccable, but a lot of folks had a hard time swallowing what he had to say.  ESB’s, or Enterprise Service Busses are one approach to creating a Service Oriented Architecture (SOA).  The idea behind wanting to use ESB’s to create SOA’s is the desire to enable software to be componentized.  Interestingly, this is also wrapped up to a certain extent (but far from complete overlap!) with the question of how to break down an application into components that can operate across many cpus in a distributed network:  shades of the multicore crisis again!

Vinoski’s original post was inspired by Patrick Logan who muses that:

ESBs seem to me to be lumps of things useful for integration, but do not form any kind of coherent shape out of the individual lumps. If you need XML transformation, email, HTTP, file drop, etc. then why not just use the simplest dang library for the one or two of those needed for any given situation? If you need more than two of those in a single situation, then that’s a symptom rather than a need.

Look at the list of “adapters” or whatever an ESB advertises. In each case, one can locate a fairly simple library, probably already on their machines, that implement that one feature well enough. ESB’s say they can “wire” all that stuff together.

Such wiring usually appears to be more complicated than the original problem.

xml config’ing a zillion jar files to “mix-n-match” all the ESB thingies — who really does that? Successfully? And what does the *architecture* of that look like? I remain unconvinced and nearly uninterested.

I understand Patrick’s problem.  There is a whole raft of configuration to be done to set up this kind of middleware solution and create the ESB.  It’s complicated, dreadfully boring, counter-intuitive, and extremely error prone all at the same time.  You spend so much energy looking at trees that the forest is almost impossible to see.  What a combination!  Given a solution like this, we’re definitely in the land where 70% of what you had to do feels like wasted effort.  There has to be a better way!

Enter Steve Vinoski’s “ESB Question”.  As he puts it, he used to build ESB’s and worked for a company that was deeply involved with them, but he lost the religion.  He lays at least some of the blame for the difficulties with ESB at the doorstep of particular languages like Java and C++:

Eventually, these mono-language programmers end up completely incapable of addressing a problem unless they can see how to implement it in their One True Language™.

This is the message I’ve been talking about that while Java and C++ are great for some things, perhaps even many things, a multiple language Polyglot Programming strategy is much more powerful. 

Interestingly, Steve also identifies cultural problems around Enterprise Architects, who want to have a place of leverage from which to control the Tower of Babel that is the Enterprise’s disparate collection of software from many vendors.  A deeper problem is that the world these things are built on may be changing so rapidly that building the ultimate “deathstar” architecture can take so too long that things change out from under you before you can finish.  A lightweight approach that gets things working fast is a definite advantage in such a situation.

Steve’s answer to these problems?  He likes REST and a dynamic language such as Ruby except in 2 cases, which he feels are rare.  Case one is when you have to connect to a Legacy system that just won’t support anything but an ESB approach.  Fair enough, happens quite a lot, so we just have to grin and bear it.  Case two is when the proven performance envelope just won’t work for REST and the dynamic language.  I’ve italicized “proven”, because in all too many cases programmers reach for premature optimizations just in case something might happen.  As Donald Knuth has said, “Premature optimization is the root of all evil.”  Vinoski believes the number of cases of real performance need are far less than the number of projects that think they might have a problem.

Predictably, Steve got a lot of reactions to his post, and a some was hate mail (“no-light-all-heat “us vs. them” arguments).  Folks objected to the idea that the mono-language thing was bad, that Java/C++ were being bad mouthed, that Enterprises could even begin to consider something with the performance of a dynamic language like Ruby (Oh so slow!), yada, yada.  The usual suspects turned up for the free coffee and donuts.  After the second post didn’t disperse the crowd, Steve got tired of it and vented a bit in a third post.  It boils down to the usual conclusion that happens in religious arguments which is, “You go your way, I’ll go mine, but I’m right and you’ll thank me down the line.”

This train of posts caught my eye, but I don’t feel like the initial posts were able to focus attention quite properly, at least from my own perspective, to push the ball across the line.  Steve has been thinking about this stuff for a LONG time, and when you do that, it’s easy to lose track of what you said to who when, and to establish a good level set.  Blog posts are typically shorter (this one is longer, sorry!), and that makes it hard too.  I went back and read an earlier article he wrote while at Iona, and I think it brings a lot more to the discussion.  Try Rest Eye for the SOA Guy, I got a lot out of it.

First thing it injects is a bigger perpective.  It jumps up 10 or 15 thousand feet.  Instead of ESB bashing, it moves to SOA and looks at the requirements in the abstract.  SOA needs:

• service registries, in which services advertise their locations and capabilities, and where consuming applications go to find those services;
• service repositories, in which developers store metadata, such as contract descriptions and policies, for use at both service design and deployment times;
• service definition languages, which developers use to define service contracts; and
• service platforms, which provide design-time and runtime support for service creation, deployment, and execution.

Then he points out that a lot of distributed computing platforms deal with this stuff, including Distributed Computing Environment (DCE was a toolkit from the early 90’s aimed at creating client/server software), Corba, and Java Enterprise Edition (Java EE or J2EE).  The plot starts to thicken. 

As we look at these tools and their role in creating software components, we see that one of the things they’re trying to do is hack the dynamic nature of some languages into decidedly un-dynamic environments (more properly static).  By un-dynamic, I mean languages where almost everything has to be known when the program is compiled.  You can see how that makes it hard to dynamically combine components at run-time.  You can also see where dynamic languages that do this as second-nature (like Ruby and many others) have a real advantage.  You don’t have to roll that part by hand, or by doing reams of configuration ala middleware solutions if you have a dynamic language.  I can tell you first hand from having both rolled these kinds of solutions (to create a persistent object store for C++ before libraries were available) and from having worked with the middleware approach of things like J2EE, that it adds enormous complexity.  You can see too where we’re not just talking about fairly loosely coupled applications with a very arms-length relationship, but about building distributed software, which is what you have to do to scale and overcome the multicore crisis. 

In the same article Steve resets perspectives again and talks about the origins of REST as a protocol for solving these problems.  The essential point here is that REST is the protocol the Web was built on and there isn’t a bigger, more successful, more scalable, more performant example of distributed computing than the World Wide Web.  John O’Shea puts it well: 

Can enterprise architects disregard the architecture, constraints and protocols that helped the Web scale and adapt to be the global platform it is today? 

In the end the non-uniform interfaces at the heart of these solutions tightly couple the clients and servers and this coupling is the underlying limiting factor on the adaptability and extensibility of these systems. 

That last is bittersweet, because aren’t ESB’s and SOA specifically focused at avoiding that painfully tight coupling?  O’Shea wants to be able to create ad hoc mashups without a lot of setup, and he wants things to be able to survive a version update or two without forcing rewrites.  That seems little enough to ask for this sort of thing.

In the end, both approaches can work.  I’ve seen ESB-like solutions go together and work well, but it took a lot of effort to get there.  I have not personally implemented a RESTful system yet, but I’ve talked to a number of people who have, and their position is that it is so much simpler there is no comparison.  I can certainly see why that is.

The ESB vs REST discussion seems like looking through two ends of the telescope.  ESB wants to enable us with a minimum of disturbance to write programs just as we always have in traditionally compiled languages.  If we put up with the productivity overhead and other costs associated with the middleware, they’ll make the communication between components look pretty similar to other kinds of communication in those languages.  But is that really the right goal to optimize productivity or functionality, or is it a premature optimization?  I think it is the latter.  Turn the telescope around and stop trying to move the past architecture into a distributed world like that.  The bigger problem in writing distributed systems is you should be thinking about them differently.  Dealing with distributed components is not the same as dealing with local components, no matter how convenient the fantasy may be.  There are real differences in behavior that matter.  Because software is so malleable, you can certainly beat it into submission with enough middleware, but there are easier ways to get there.

REST is the web’s view of how it all should work.  It was designed from a blank sheet of paper that asked, “What should this big distributed system look like?”  It answers questions of how to make the system scale, how to achieve reasonable performance in the face of all kinds of failure modes.   And, how to make it approachable to the broadest audience.  It speaks of statelessness and other essential ingredients that many are retrofitting back into their systems after they fail to scale.  By starting out with REST, you are much better positioned to do the kinds of changes that benefit scaling. 

Does that mean we have to give up curly braced languages and ESB’s?  No, I am not an advocate of dropping them wholesale.  I’ve worked more with those languages than any other tool and I’m ready to step right up and do it again.  For the right problem.  What I am advocating is a multiple language approach or what others have called Polyglot Programming.   A number of companies have built the necessary architecture to enable this to happen and they’re enjoying the fruits of that investment.  The next step is to enable it for everyone to do easily without having to build their own multi-language framework.