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)