Joel's SharePoint Architect Blog

Mon, 12 Nov 2007 18:22:35 GMT

It’s been a while since I last saw Pat presenting on SOA. He hasn’t lost the magic. But he has lost a ton of weight. Or gained a lot of height or something! Pat – well done mate!

Continuing his Metropolis series of SOA talks, Pat’s theme this time is around composability and interchangeability of Services.

A Short History Lesson

The European System of Manufacturing – before 1800s

The build of complicated objects required each part to be manually lathed or turned in such a way that no two craftsmen produced the same precise part; no two (otherwise identical) parts produced by the same craftsmen were identical enough to be interchanged. To scale up, more craftsmen were required. When things broke down with the goods being built, replacement parts would require "manual fitting" to make them work. Variance in the manufacture of parts caused unscalable systems.

The American System of Manufacturing – circa 1800s

Due to a lack of manual labour and engineers, the Americans adopted a mechanised approach of manufacture. Heavy (steam) power tooling was used, which saved labour. However, these were not automated, and variation in parts produced during manufacture was inevitable. Manual fitting was still required; machinery just got us to that point quicker.

The US Armoury System of Manufacturing – mid 1800s

Le Blanc, Jefferson, Whitney hypothesised a system of interchangeable parts, which depended upon the manufacture of specific parts being reproducible, predictable, and with tight tolerances to variation. Notably, Whitney won a contract with the US military to manufacture arms using this method; he failed because he was unable to eliminate the requirement for manual fitting – i.e. the methods were too hard to produce identical, interchangeable parts to their rifles.

John H. Hall, circa 1820s

John H. Hall developed accurate machines to build interchangeable parts in gun manufacture. His machines were expensively hand crafted to accurately reproduce, time and again, the same parts down to a very fine tolerance in variation. Ultimately Hall was to fail as he lacked the funds to realise economies of scale.

Sewing Machines – circa 1870s

Wheeler and Wheeler sewing machines produced 25,000 machines in 1860. By 1876 this figure rose to 108,000. They achieved this by using machines to make their products. Brown and Sharp also adopted this method.

The Pope Bicycle – circa 1890

Parts built by Sharps Rifle Company using machines that worked from reusable, accurate templates.

Why is this important?

This takes the narrative from European, hand-finished manufacture, all the way through to the Model T Ford, via the US Armoury and the Pope bicycle.

Model T Ford

Ford was inspired by mass production of meat. Butchers – working in what Pat calls "disassembly plants" – would stand in front of a conveyor of meat carcasses, and apply the meat cleaver to each one without having to move from carcass to carcass. What impressed Ford was the efficiency with which the production line operated. The "operator" never had to move; the parts were brought to the operator. From this, it’s a relatively short journey to Ford’s Assembly Line of Model Ts.

The Assembly Line’s purpose was to eliminate custom fitting altogether. From this he derived the ability to repeatedly, repeatably, indefinitely minimise variation and produce tens of thousands of identical parts. Ford’s machines and buildings were tailor made to the design of a specific car. To change the design required buildings to be dramatically changed, and machines to be retooled. For 20 years the Model T Ford did not change at all in design. A new one was virtually indistinguishable from one 10 years its senior.

General Motors

GM introduced the concept of the recurring annual new model. Arguably the first concrete example of agile manufacturing. GM provided heavy duty, multi-puropse, multi-site production processes and equipment, taking the assembly line approach from Ford and extending to allow reuse of key components – engine, chassis, transmission, etc – whilst allowing evolution of other components – e.g. bodywork, gearing.

This first example of flexible mass production owes everything to mechanised production and complete interchangeability of parts. This allowed GM to rapidly (over a number of years) change to new models.

From History to Transactions

American System of Transaction Processing

Pat then draws the comparison between early American manufacture to traditional transactional processing.

Any two appilcations performing similar tasks are allowed by the technology an immense amount of flexibility and variance in implementation. Consider the operation to update an accounting and an invoicing system. This could be implemented in a massive variety of different ways; at the simplest level, updating accounting tables first, and invoicing tables last. Alternatively the other way round is equally logical.

It is precisely this flexibility of the toolset – in the case of manufacture we’re talking about lathes, planes and so on; in the case of transactions we’re talking about software languages, programming environments, etc – which gives the problem. Of course, this is only a problem when you come to a point that you need to swap out the accounting or invoicing system for a new one.

So – flexiblity of this scale is a problem when we cross boundaries of trust or service. Instead, we should try and aim for a more appropriate model of…

Transactional Machine Tools

Applying the General Motors model to application development, we need to consider:

• Applications are Independent, Standalone – although no program is an island, eh Don?
• Interconnectivity with Independent Services – services share Schema (format), Contract (sequence) and VERSIONED Reference Data.
• Optimistic Concurrency does not stretch across Trust Boundaries – Interactions should be based on business functionality, not data exchanges!

That last point is particularly poignent. Consider, if you will, Optimistic Concurrency and your bank. You can’t just give your bank a set of new values you’d like your balance to be. You have to invoke business operations; Deposit, Withdraw. Incidentally, banks do not do atomic transactions as such. Deposit and Withdraw are examples of potentially long running, cancellable transactions; which brings us to….

Armoury System of Transactions

We can go one better right now. If the US Armoury had been building transactional systems, they would have probably built them to use:

• Compensating Operations
• Tentative Operations
• No Transactions Shared Across Boundaries

Pat then quoted one of his previous discourses. "Two phase commit is the anti-availability protocol." Which makes a lot of sense. 2 Phase Commit locks resources; the more contention, the worse the locking. For services, that should be composable, this is not acceptable.

Key to deriving the same economies of scale with services are Tentative Operations (Cancellability), Composability and Nesting of Cancellation. At all costs, avoid Variance, Option and Choice. These are bad for interchangeability.

A Word about Data

Consider two kinds of data – Activity Data and Resource Data. These data have very different requirements during transactional handling.

Activity data, is what you might find in activity-related operations. Your Amazon shopping basket; deposits to your bank balance. These are things t
hat can be rolled back very easily if anything should go awry. Compensating actions are easy to devise and apply.

Resource data is altogether more complex. Consider booking hotel rooms for your stay during Tech Ed. If the conference were cancelled before the event, each night of your potential stay would have to be compensated. The night of Nov 5th. The night of Nov 6th etc. All get one extra spare hotel room added back to the appropriate bucket. Back to the "Reservation Pool" if you will.

Essential in the handling of resource data – in Reservation Pool Management – is that all access and changes should be contained within, encapsulated in, a suitable Reservation business operation.

To handle these various scenarios, your operations need to be able to cope with

• Long Running Transactions
• The Ability to Place the Same Order Again
• Tentative Operations

In order to achieve these behaviours, remember: Specificity GOOD, Variety BAD.

Domain Specific Languages

DSLs are the heavy duty, multi-purpose machine tools of the General Motors model. Just as GM was able to swap out chassis, transmission, engine parts, DSLs let you swap out logon services, retrieve customer services, accounting services.

DSLs get us close to flexible mass production. Harping back to the World of Warcraft in Visual Studio demo of the Keynote – wasn’t that an example of a Domain Specific Language that churned out Lua code? Retooling made easy, without having to restructure your factory (your IDE) or your craftsmen (your dev team).

Finish on  a Song

OK. He didn’t. Not this time, anyway.

But he did finish with some philosophy.

Atomic Transactions are like Singularities. Singular points in space and time. Two phase commit makes time problems go away. Changes in our industry, moving away from mainframes to minis, from monoliths to services, introduce distance into the equation. Interchangeability of parts makes space and time effects surmountable.

Summary

Services offer us a different paradigm to traditional transactional processing. Always consider:

• Explicit Boundaries – autonomy of services
• Acceptance is Different – Confirm and Cancel, not Commit
• Semantics – Intricacies should be avoided
• Interchangeability – Variance prevents interchangeable operations

TechEd-Developers

Technorati Profile

Technorati Tags: Microsoft, SOA, TechEd 2007

Fri, 9 November 2007 10:45 GMT

Pat Helland

Microsoft Corporation

A cracking session from Pat. My notes don’t do it justice.

Forces, Objects and Evolution

• Economic and technical forces driving our industry
• Forces are influencing the way we build our applications
• This drives new models for building applications
• Causes evolution in computing models – new models must respect legacy stuff

Forces in Processors

• Moore’s Law Continues!
  • The CPU Wall
    • # Transistors still doubles ever 2 years
    • Voltage isn’t dropping as fast; power consumption now up at 150 Watts
    • CPU Frequency is plateau-ing at 4GHz
    • CPU performance hits the "Power Wall"
      • "Static Power" vs "Dynamic Power" – Static Power increases as performance increases
      • As transistors get smaller, they "leak"
    • Clock Frequency causes a rise in "Dynamic Power"
    • Vicious Circle: Faster Chips get hotter; Hotter Chips user More Power; Hotter Chips…
  • The Memory Wall
    • Plateau at 60ns access
    • More bandwidth is doable, but not shorter latency
      • Faster CPUs wait more
    • Speculative Execution
      • Guesses what memory will be needed in advance
      • "Out of order processing" to bring data in to cache early
      • Fractionally more performant; 5 times more complicated
    • In Order Execution
      • Simple 1 Instruction at a time
      • Slower clock speed equal fewer waits
      • Slower clock speed can be almost as fast as Speculative Execution

• Many Core CPUs
  • Can’t currently make faster CPUs
  • Solution is to put multiple CPUs per chip
  • The future is moving towards 500 Cores per chip in the next decade
  • Our software is not ready for this! It doesn’t take advantage of 2 core properly yet!
  • On-Chip Memory Cache – shared across multi core (locking issues?)

• Parallel Processing will be orders of magnitude cheaper than sequential
  tyle="margin-top:0in;margin-bottom:0in;margin-left:0.375in;direction:ltr;unicode-bidi:embed">
  • How can we take advantage of parallel processing?

Forces in Data-Centres

• Buildings outlast servers
• Currently we overestimate requirements
• Reducing power saves air-conditioning
  • Double savings

• Backup power is 20% of datacentre cost
  • Batteries for a while
  • Backup generators cost $2M

• Trends in datacentres
  • Datacentre in a shipping container!
  • Fail-in-place
  • Don’t use backup power: use multiple datacentres!
  • Only works with applications that will scale out
  • Move towards stateless, composable, distributed applications
  • Future will have a mixture of traditional datacentres and low-power, datacentre in a shipping crate datacentres

Forces in Storage

• Disk Is Tape
  • The pipe to the disk is getting smaller
  • Capacity increases with areal density
  • Read/Write time with linear density
  • 10+ Terabyte disks projected for 2010 for $100 or so
    • 5-15 hours to read sequentially
    • 15-150 days to read randomly

• Flash Is Disk
  • Moore’s Law Drives Flash RAM Capacity
  • Low power, low temperature
  • Not constrained by "disk pipe" issues
  • By 2012 Flash will be same price as cheapest disks

Forces in Communication

• Bandwidth and Latency
  • Datacentres dark fibre bandwidths
  • Total Bandwidth triples every 12 months – exceeds Moore’s Law
  • Latency reductions are limited – by the speed of light

• Wireless Everywhere – Mostly
  • Applications need to exhibit "Always Offline" behaviour
  • Don’t resort to the hourglass
  • Useful work always continues
  • Data gets less stale

• It is easier to move a "bit" than it is to move a "watt"
  • Datacentres moving to be close to Hydro-Electric dams

Forces in the Cloud

• Videos: Software and Services
• Application State must be separated from the machine
  • Per user, Per app state
  • Safety and sandboxing
  • Controlled and safe sharing across apps
  • Controlled and safe sharing across users

• Parallelism
  • Pipeline parallelism
  • Partitioned Parallelism
  • Bulky Xml? Not  problem considering trends in computing
  • Problems today
    • Servers: big databases
    • Clients: big exes

• Gain speed by bringing data close
  • Principal of locality of data

• It’s OK to have copies of data close by
  • Read-Only Reference Data
  • Divergent Changes of Copies

• Defy Authority
  • Multiple changes to multiple copies
  • No Single Source of Truth
  • Who to believe?
  • Historic trust

• How can we build apps out of small, independent and UNRELIABLE pieces?

Demand for disconnection, scaling, cheap computers and cheap datacentres

The Movable Objects

Admitting we’re confused

• Even if the computer is accurate
  • Data are entered by people
  • Data are entered by sensors
  • Decisions are made

• Guessing and partial knowledge
  • Separated from the real world
  • Map be separated from other replicas

• Computers do not make decisions
  • They *try* to make decisions
  • Good guesses, bad guesses but no certainty

• Memories and Sharing
  • Remember your guesses
  • Sharing your memories is useful
  • Fidelity of memories tightly bound to cost
  • More memories = longer latency

• Investing in remembering well is a business decision
• Screw-ups and apologies happen – it’s OK to be decisive and wrong
• Airlines, bookshops – many business take advantage of this

Working in the here and now

• Smaller computers offer more "bang for the buck"
• Smaller datacentres offer more "bang for the buck"
• Smaller datasets frequently offer more "bang for the buck"
• OK to have copies of data
  • There is no authoritative copy
  • Versioning and change history show what was intended
  • Application design for independence is required
  • Big websites have large caches of product catalogues and price lists
    • Computing with versions
  • Demand for cheap datacentres adds to this need

Cutting the work into little pieces

• Scaling with local transactions
  • Assume your computation must be done, can’t wait to cooridate and your partner is likely to be remote
  • You must do local work

• Solution: Uniquely keyed objects and partitioning
  • Must identify objects with a unique key as its identity
  • Transactions cannot occur across

• Queries are different
  • No transactional queries
  • May not be on same machine
  • No remote transactions
  • Can query stale copies
    • What does stale mean?

• Alternate indices are different!
• Fine-Grained workflow
  • These objects and their data are not like traditional DBs
  • T
    his is traditional workflow but with fine-grained participants
  • Separate Transactions on Little Objects
    • Smaller is better

Independent Changes to Little Pieces

• Subjective Consistency
  • Given what I know here and now, make a decision – REMEMBER THAT INFORMATION!
  • Other copies of the object ma make divergent decisions
  • Ambassadors had authority: before radio

• Eventual Consistency
  • Eventually all the copies of the object share their changes
  • Now apply subjective consistency
  • Given the same knowledge, produce the same result
  • Everyone sharing their knowledge leads to the same result

• Idempotence, commutativity and associativity of the operations are all implied by this requirement

• The CAP conjecture
  • Consistency
  • Availability
  • Partition Tolerance
  • …PICK ANY TWO!

• Subjective Consistency plus Eventual Consistency means it’s OK to have some screw-ups

Interoperate and Entice

• Must interoperate with the existing software investments
• A lot of code exists and it very important
• Entice into the new world
  • Drawing people in will happen though financial and business drivers

Conclusions

• Hardware is changing

Lots of CPUs; no faster though

Power and heat

Lots of devices

Lots of bandwidth -> intermittent device connectivity

• Economics are changing
  • Small is beautiful
  • Unreliable is cheaper
  • Configuring costs more than the devices
  • An onslaught of data

• Components must change
  • They need

• ACID  - Atomic, Consistent, Isolated, Durable
  • Goal for transactional ACID was to make the insanely complex look like a single machine

• ACID for objects – Associative, Commutative, Idempotent, Spread out and independent
  • The drive to stateless computing
  • To recognise that the work will be done by lots of unreliable machines
  • Associative: (A + B) + C = (A + C) + B
  • Commutative: A + B = B + A
  • Idempotent: repeatable, no side effects
  • Distributed: Spread out and autonomous

• Not for everything
  • Not for real time systems (closed queuing networks)
    • e.g. Fly by wire; nuclear power plants
  • Not for very expensive apologies
    • "Oh crap, I just launched the space shuttle"

• The new ACID
  • Huge Numbers of Relatively Small Operations
  • Cost and Probability of apologies is small
  • Essential for service and product provides

Technorati Profile

Technorati Tags: Microsoft, SOA, TechEd 2007