I was particularly interested in this part of a recent post from Coté:
James knew that there was a vast schism here between the simple-heads and the complex-heads. The REST and the SOA heads. The WS-Deathstar vs. the WS-* people. Essentially, the two camps don’t want to have anything to do with the other because each thinks the other is fatally flawed:
- The simple-heads think the complex-heads make everything too difficult in the name of…well, they’re not quite sure why. Maybe to sell more software, because they like punishing themselves, or because they don’t know any better.
- The complex-heads think the simple-heads are using “toy” technologies that surely won’t work in “the real world.” Simple software can’t be used for large scale, high-dollar problems: surely you couldn’t transact billions of dollars a day with “simple” software.
I think the root cause of the conflict comes down to differences in underlying design philosophies…..
Challenges
In building their systems both sides must tackle challenges such as:
- Failure
- Scaling
- Data Partitioning
- Persistence
- State Management
- Security
Two Different Approaches
Most of enterprise buys into the middleware concept where all the challenges are to be handled inside of an all-encompassing, tightly integrated framework leaving the “trivial” matter of writing some custom logic to satisfy their specific requirements. Cramming all these things into a single piece of infrastructure inevitably leads to complexity in many forms including large surface area (see the section titled “Simplicity as its Own Virtue”), big hardware, big configuration files and so on.
In contrast stands the web crowd that prefers de-centralized, distributed, layered solutions where all participants share responsibility in handling these challenges and application developers are expected to design accordingly (say by implementing retry strategies, idempotency and the like rather than transactions).
Incompatible Views
Essentially the enterprise crowd tackle these tough challenges with technology whilst the web crowd and others tackle them with design. One side complains of toy technologies because they expect the difficult stuff to be tackled in their underpinning middleware monolith and the other complains of complexity because they prefer to emphasise design and simple components.
Bullets
SOA isn’t (or at least shouldn’t be) about technology. The systems aspects of SOA can be constructed using many different technologies (even a mixture) but many still think SOA requires WS-Deathstar. Similar issues exist around REST which many mistakenly associate purely with http. This speaks to a much bigger ill that is rife in our industry - the tendency to conflate concept and technology.
It can surely be no surprise that the middleware mob find distributed hard, given that all they know and all that they do is pretty much in complete opposition to what is required for such systems.
An oft-cited reason for the existence of complex middleware is enterprise’s desire to utilise commodity programmers. Little wonder that so called rock star programmers have zero interest in such a world and are to be found playing around with the web.
Technorati Tags: architecture, design, systems
Entries (RSS)
August 9th, 2007 at 4:06 pm
I think the enterprise’s desire to utilize* commodity programmers has led to a lot of unnecessary complexity, not just in middleware, but in development methodologies, coordinating geographically dispersed development teams (i.e., offshoring), etc.
*sorry, Firefox’s spell checker insists this is the correct spelling.
August 9th, 2007 at 5:57 pm
I completely agree that SOA is not about or should not be about technology. I also agree that the enterprises should avoid the temptation to hire commodity programmers. I am also not a proponent of the WS-* hype created by the vendors to make us believe that the middle ware will take care of all and you just need to write “trivial” custom logic.
However, I do believe that the basic plumbing infrastructure pieces e.g. logging, monitoring, caching, configuration, timeouts, connection pools etc. should not be reinvented by each and every “hot programmer” team. That’s not the ideal usage of hot programmers. The responsibility should be shared (so that truck factor is more than 1) but there should be minimal (preferably 1) consistent way of doing these “low level yet challenging” things.
August 9th, 2007 at 6:07 pm
“However, I do believe that the basic plumbing infrastructure pieces e.g. logging, monitoring, caching, configuration, timeouts, connection pools etc. should not be reinvented by each and every “hot programmer” team.”
Agreed with caveat:
Ideally that’s the case but for example in a distributed system what that infrastructure looks like is radically different from what one finds in most centralized middleware. When this sort of thing happens it’s sometimes necessary to re-invent the wheel a little. I guess what we really want is a reusable collection of plumbing bits as opposed to the more common tightly integrated all-in-one stack type affair.
August 9th, 2007 at 7:29 pm
“reusable collection of plumbing bits as opposed to the more common tightly integrated all-in-one stack type affair.”
Totally agreed - I could not have said it better.