Entries Tagged 'architecture' ↓

Check Out Sixtree

I’ve recently joined the talented people at Sixtree and consequently am blogging over there.  Please check it out.

(Not much to see here in the meantime)

Amazon Shareholder Letter

This is a few months old, but Werner Vogels republishes the Amazon.com Shareholder Letter. A summary of how the quintessential 21st century company views its competitive advantage:

  1. Service Oriented Architecture
  2. Distributed state management
  3. Decision management

Regarding Service Orientation:

Our technologies are almost exclusively implemented as services: bits of logic that encapsulate the data they operate on and provide hardened interfaces as the only way to access their functionality. This approach reduces side effects and allows services to evolve at their own pace without impacting the other components of the overall system. Service-oriented architecture — or SOA — is the fundamental building abstraction for Amazon technologies. Thanks to a thoughtful and far-sighted team of engineers and architects, this approach was applied at Amazon long before SOA became a buzzword in the industry. Our e-commerce platform is composed of a federation of hundreds of software services that work in concert to deliver functionality ranging from recommendations to order fulfillment to inventory tracking. For example, to construct a product detail page for a customer visiting Amazon.com, our software calls on between 200 and 300 services to present a highly personalized experience for that customer.

Any Lessons from the AWS Outage?

You’ve probably heard that Amazon AWS had some problems recently. A question on Stackoverflow recently pointed out a detailed summary of the problem posted on the AWS message board.

Obviously every distributed system is different and every outage is unique so it is difficult to generalise. Some takeways I have are:

  1. Outages happen to even the best guys on the block…so you better plan for yours.
  2. Building distributed systems is hard…so you need experience and experienced friends.
  3. Manual changes are a common cause…not said explicitly in the AWS writeup, but strongly implied.
  4. Outages are often “emergent” phenomena whereby a simple error causes many systems to interact in a way which grows exponentially. The AWS writeup refers to this as a “storm” and I have witnessed similar “storms” in large distributed systems. The degree of coupling and simple aspects like backoff parameters can make the difference between a disturbance that grows exponentially or decays exponentially. Think of the Tacoma Narrows bridge – perhaps the analogy is a stretch, but tuning of a few simple parameters can avoid destructive resonances.
  5. One of the responses pointed to the Netflix Chaos Monkey as being vindicated by the outage. The “Lean” guys have taught us that if something is difficult (like testing or deployment) then you should do it often until it aint difficult any more. Perhaps system failure/resilience is the next frontier for this approach.

Who Cares About Technology?

Steve Jones reminds us that the business doesn’t care about technology – so stop harping about it and using it as an excuse for underperformance.

I totally agree that this is a key reason behind the endemic business/IT culture divide that is the root of many problems.

However this poses an obvious question – who does care about the technology?. The trick is not to over-engineer, but to engineer to just the right level to deliver business value now and into the future.

Somebody has to care about the technology (products, tools, methodologies), because otherwise you lose control and foster a legacy of technical debt which ultimately erodes business value.

I guess this is an axiom of Enterprise Architecture – that lack of governance leads to chaos and inefficiencies. Some would argue with this assertion, but I have never seen a counter-example. And of course the inverse statement is not necessarily true either.

So if the business doesn’t care about technology then who does? And if that is “nobody” then what happens?

Coupling as Inertia

In systems architecture, there are rarely any right answers – mostly just trade offs between one solution or another. In such cases it helps to bear in mind some fundamental principles as a guideline. One principle I often use is cost vs. benefit. Another useful principle is to minimize coupling between systems. Coupling is pervasive and leads to a kind of inertia in enterprise systems. Newton discovered that inertia prevents change and if there is one thing that enterprises struggle most with, it’s change.