Pragmatic Dictator

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:

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

When we write programs one of the things we seek to do is encapsulate our data so as to allow us to manage our dependencies and keep our code clean. Most languages OO or otherwise provide mechanisms to support this way of working.

The thing about the average database is that it doesn’t really encourage similar behaviour. It is all too tempting (and easy) to just allow everyone to access everything. Whilst we confine ourselves to a single application using the database, the problem is to some extent contained but often what we actually do is allow multiple applications access to the same database. The exact way in which this is done varies:

1. Sometimes we bundle all our middle tier code together even though it has separate roles and responsibilities and integrate all of it via a single database.
2. Sometimes we have multiple applications each running in a different process.

With each application we put on top of the database the problem gets worse increasing the number of invisible dependencies tying unrelated elements of code together by virtue of accessing a shared schema.

What’s happening is we’re sharing too much intimate knowledge across our system, something we’re all taught to fear. The solution is as always to prevent direct access to this intimate knowledge by interposing layers of abstraction. One way to do this is by requiring access to data to be wrapped up behind an interface. Historically we’ve done this by having a system own the database and expose interfaces that other systems can use to get the data.

Unfortunately there is a well-known issue with this approach which is that the level of granularity is wrong and these additional integration interfaces rapidly balloon into complex beasts. What we need is a a database wrapping entity that has a finer level of granularity than an entire system. Then the integration interfaces will be simpler because there will naturally be a less complex schema underpinning this more limited functionality.

What are we talking about? Services. We end up with a system of lots of discrete services each wrapping up their own data storage.

There are other benefits to this approach:

1. Each service can utilize the most appropriate storage option for it’s contained data whilst having zero impact on other services that might have different needs.
2. Each service is an independent entity that can be managed (monitored, deployed etc) separately.
3. Centralized access patterns are more easily broken down which is useful in cases where we deploy across multiple data-centres.

Who would do such a thing?

Technorati Tags: architecture, database, distributed systems, enterprise

…..Three-tier architecture. Three tier architecture is really a logical partitioning of system functions into presentation, business logic and data-access. Of course, some frameworks have attempted to turn this into a physical reality which is fine but many people believe that such systems are or can be distributed which makes little sense – why?

Because as has been said elsewhere placing code far away from the data source makes little sense. If one is to place code away from the data source it’s going to be for one or more of the following reasons:

1. The computational weight demands separate scaling from the computational load inherent in managing the storage of the data.
2. The computational load in the data-storage layer can be better scaled elsewhere.
3. We can offset the additional latency introduced by network roundtrips.

Most three-tier architectures fail to satisfy any of the above criteria and thus aren’t good candidates for distribution.

…..Synchronous. This is because, in order to offset latency we must exploit asynchronous behaviour. Note that this does not imply the use of messaging rather it means adopting suitable asynchronous design patterns which can be implemented via RPC or messaging.

…..Completely consistent all of the time. Trying to enforce ACID properties across a distributed system is opening an enormous can of worms where one constantly attempts to defy the nature of the network. It’s not impossible to achieve but there is a tradeoff to be made. It’s often better to prefer eventual consistency in good-enough time i.e. something that approximates total consistency under most circumstances whilst degrading (hopefully gracefully) under load or in the presence of failure.

Many have attempted to implement distributed systems whilst falling into one or more of the traps above. Many have paid the price and many have consequently pronounced that distributed is inappropriate, impossible or insane. This is the motoring equivalent of strapping a massive turbo to an unmodified engine and complaining when the pistons explode through the bonnet and the oil is dumped all over the floor. In both worlds the remedy is the same, talk to an expert and be prepared to throw out a few beliefs.

Technorati Tags: architecture, distributed systems

Tom Ayerst pretty much hits the nail on the head.

I would suggest just one more refinement:

Architecture and code need ongoing concern, review and re-organization. One simply cannot leave what has been previously built untended and focus on the next feature. It only takes one broken window……

Intel wades in on the “we can’t do any more magic concurrency for software” issue.

It’s been debated often enough and always seems to come down to the fact that the average programmer isn’t able to cope with concurrency and needs higher levels of abstraction to do it for them. The thing is, we already have such abstractions e.g. transactions and we know they can only take us so far. Worse there are other abstractions out there such as blackboard systems which these average programmers either can’t or won’t try to cope with.

So what is to be done? Well if the last couple of decades are anything to go by, absolutely nothing! Why? It’s the talent limit. How many chip designers are there in the world? How many motherboard designers? How many car designers? How many developers? I’m willing to bet that there are considerably more people in the developer category than any of the others. This is because we’ve lowered the bar in terms of developer quality to cope with the wide demand for bums on seats and lets face it, it’s unlikely that the average enterprise is going to change it’s policies in this respect. It’s interesting to note that it’s much harder to lower the bar in for example chip design, it either works or it doesn’t whilst software is almost expected to be flaky these days.

Until we decide to clean house in software land, we’ll not get progress on these thorny issues because they only matter to the few and when all said and done, there is a school of thought that might suggest that software is good enough, concurrency, efficiency, quality and green’ness be damned.

Update: An example of how challenging it can be to make concurrency easy can be found here. On the surface we’ve done some good things and yet we are still open to the simplest of errors (in this case a missing synchronized clause).