Entries from April 2009 ↓

In my opinion, coupling is the most fundamental attribute of a system architecture and tight coupling is probably the most common architectural problem I see in distributed systems. The manner in which system components interact can be a chief determinant of the scalability and reliability of the final system.

So I really like Ian Robinson’s post on Temporal and Behavioural Coupling where he uses two coupling dimensions and the inevitable magic quadrant to classify systems based on their degree of temporal and behavioural coupling.

See Ian’s post for the slick professional graphics, but to summarise – event-oriented systems with low coupling  occupy the “virtuous” third quadrant of the matrix. Conversely the brittle “3-tier” applications that many of us struggle with, occupy the “evil” first quadrant where coupling in both dimensions is high.

However I’m a little miffed to see no mention of my favourite “document-oriented message” in Ian’s diagram. As Bill Poole writes; document messages have lower behavioural coupling than command messages, but more than event messages. So would you put document-oriented messages near the middle top of the matrix between command-oriented and event-oriented messages? Unfortunately that would break the symmetry. But it also highlights another problem.

Any type of message – document, command or event-oriented could temporally be tightly or loosely coupled. Temporal coupling is more a property of the message transport than of the message type. So I suggest that the two coupling dimensions are characterised as follows:

• Temporal coupling – characterised by message transport from RPC (tight coupling) through to MOM (loose coupling).
• Behavioural coupling – characterised by the message type from event-oriented (tight) through document-oriented to event-oriented (loose).

It so happens that distributed 3-tier systems generally employ both command-oriented messages and RPC transports – hence making them inherently “evil”. Whereas events (being asynchronous)  are naturally virtuous by typically being carried over MOM transports (it’s difficult to request an event notification).

Between heaven and hell, it is in the murky mortal realms of SOA where we need to be constantly mindful of the interactions between message type and transport – lest our system ends up in limbo.

The recent brouhaha about Twitter scalability has highlighted the growth of the latest spectator sport in the blogosphere – “armchair architect”. Everyone’s a Monday morning expert on which language/database/framework is/isn’t the secret to extreme scalability. The real secret is the architecture and organizational maturity. Here are some case studies to prove it:

A Conversation with Werner Vogels where Werner talks about using service-orientation to scale out massively distributed services which power the Amazon e-commerce platform. This is one of my favourites because it covers organizational as well as technical aspects of scalability. One of the unique attributes of Amazon is that service-orientation pervades everything – even their organizational structure. Developers are responsible for running their own services.Werner characterises the adoption of services as a challenging and major learning experience, but it has become one of their main strategic advantages. Key lessons learned:

• service-orientation is an excellent technique to achieve isolation and high levels of ownership and control
• prohibiting direct database access allows scaling and reliability improvements without affecting clients
• a single unified service access mechanism supports service aggregation, routing & tracking
• service orientation improves development and operational processes leading to more agility
• giving developers operational responsibility enhances the quality of the services.

The eBay Architecture (PDF) covers the evolution of eBay from 1998 to 2006. It’s a great example of how continuous reinvention is needed to keep up with rapidly growing scaling requirements. Frank Sommers writes a good summary and discussion where he argues that organizational capability is just as important as technical architecture for scalability. Another key ingredient of the eBay story is the ability to discard “conventional wisdom” when required. This is covered in an interview with Dan Pritchett, revealing some of the “rules” that eBay bends in order to scale.

• eBay.com doesn’t use transactions – mainly for scalability and availability reasons
• different data is treated in different ways – so best effort suffices for some
• references the CAP theorem – consistency, availability, partitioning – pick any two
• many have arrived at the same idea – and transactions are the first to go

Scalable Web Architectures is a great presentation on scalable web architectures in general and Flickr in particular. Also check out Cal Henderson’s list of his other presentations.

Architectures You’ve Always Wondered About provides slides from QCon London 2009 presentations. Case studies about eBay, Second Life, Yahoo!, Linked-In and Orbitz.

Avoiding the Fail Whale is a video in which Robert Scoble interviews architects from FriendFeed, Technorati and iLike.

Improving Running Components at Twitter – Evan Weaver describes how Twitter learned to scale by moving to a messaging architecture.

Real Life Architectures at High Scalability – provides a huge collection of pointers to architecture case studies from around the web.

Back around 1997 I speculated to a colleague that the general purpose web browser would disappear in 10 years. My rationale was that the user experience of HTML and the web at the time was so limited that users would be enticed by installable widgets that combined the advantages of the desktop for rich interactivity plus an HTTP “back end” for access to web-based services.

Skip ahead 12 years and obviously my prediction hasn’t come true – quite. The main reason is that Rich Internet Applications (RIAs) have been achieved inside the browser using technologies like Flash and AJAX and the challenges of installation and maintenance have held back widespread adoption of desktop widgets.

However there is one other reason why widgets have not taken off and it has nothing to do with the widget. It all has to do with the hitherto tight coupling between the server and the client in web-based “services”. All web applications to-date have had the back-end services and the front-end “browser experience” developed and marketed by the one company as a complete unit.

Until recently there were no standalone web services. Very few, if any public web services have been designed with multiple different and independent front-ends in mind. Where they have emerged, they tended to be “hacks” created by individuals who came up with creative ways to re-purpose back-end services. Perhaps the pioneer was the use of Gmail as a file system.

I think this situation is about to change dramatically, driven by a number of factors:

1. New platforms such as iPhone and Android make web-based widgets more compelling compared with the generic browser on those platforms.
2. There are now well-established standards for web services in platform neutral formats (I’m thinking JSON and XML)
3. Cloud computing further reduces the entry cost for service providers.

The main element that remains is for the business models to emerge around pure service delivery. Twitter is the most visible example that a company can provide web-based services as its primary mission and leave the development of user interfaces to others. Biz Stone of Twitter states that:

“The API has been arguably the most important, or maybe even inarguably, the most important thing we’ve done with Twitter. It has allowed us, first of all, to keep the service very simple and create a simple API so that developers can build on top of our infrastructure and come up with ideas that are way better than our ideas…”

Biz then goes on to describe how the API is central to their business model plans.

Another good example of standalone web services is how OpenID provides authentication services which are completely independent of the consuming business/application. Sites like StackOverflow can then outsource the boring authentication bits of their site and concentrate on more important content.

This is where the service-oriented architecture of the web really becomes interesting…a loosely coupled ecosystem of service consumers and providers providing the real architecture for serendipity.

Update 04/05/09: I recently found an interesting slide presentation on this topic entitled “The Rise of the Widgets” – well worth a look.