DISTRIBUTED SYSTEMS INTRODUCTION Dev Camp 2014

SCIENCE! ▸ 10 years ▸ 16 billion kilometres ▸ 510 million kilometres from Earth ▸ 65000 kilometres per our ... and the Rosetta spacecraft's Philae lander touched down on comet 67P/C-G this morning

MARK "MARK I" LANGSWORTH Militant pedant, janitor and soapbox aficiando Also a developer on Team Argonauts

DISTRIBUTED SYSTEMS A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. The components interact with each other in order to achieve a common goal. -- Andrews (2000). Dolev (2000). Ghosh (2007)

▸ Many components ▸ Network messaging ▸ Collaboration towards a common goal

SYSTEMS ARE not APPLICATIONS We're taught to be application developers with an application mindset Remember your first programming lecture at school...

IF YOU THINK LIKE AN application developer ▸ The system is atomic ▸ The system is finished ▸ Business logic is centralised ▸ The network doesn't matter

OUR AIM 1. Logical separation, facilitating physical separation. 2. Separation allows fault tolerance and scale. Contention kills both. So how do we group and delineate our components? Services thinking!

SERVICES HINT: THEY'RE NOT JUST A BUNCH OF COMPONENTS

TENANTS OF A service ▸ Autonomous ▸ Explicit boundaries ▸ Expose schema and contract ▸ Compatibility is determined by policy

VERTICAL PARTITIONING rules ▸ Along lines of business volatiliy ▸ Data lives in proper "islands of consistency" Follow the data

MORE VERTICAL PARTITIONING rules ▸ If messages are big, boundaries are likely wrong ▸ If you see duplicate data between services, go back to the business ▸ Don't name a service until the end, names are misleading ▸ Don't work bottom up

WHAT HAPPENS AT Amazon IF... 1. 15% discount for a certain class of books? 2. A customer changes their shipping address? 3. The government changes the rate of GST? (assume GST applies to below AUD$1000)

WHAT HAPPENS AT a bank IF... You deposit a cheque and then view your bank balance?

SOLUTIONS FOR scale ▸ Design for maintenance upfront ▸ Design for upgrades Versioning is hard, technology won't save you ▸ Reuse is based on a fallacy

ROUND 'EM UP ▸ Don't think like an application developer anymore ▸ Think about business rule and data volality ▸ Data consistency rules ▸ Business modelling, not entity modelling

Fin :)

COUPLING together

SYSTEMS COUPLING 1. Platform coupling (interoperability) 2. Temporal coupling (synchronicity) 3. Spatial coupling (topology)

PLATFORM COUPLING ▸ Standards-based protocols to improve interoperability

TEMPORAL COUPLING ▸ caching ▸ split inter-service communications and handling (pub/sub versus request/response) ▸ manage consistency explicitly (acceptable "staleness") This is a business concern!

SPATIAL COUPLING ▸ delegate to something else eg messaging ▸ load balancing (at first logical, then physical)

COUPLING RULES ▸ Don't mechanically reduce all coupling. Zero coupling is impossible. ▸ Be concerned when we're breaking a pattern All code should be roughly the same quality.

THE NETWORK matters

FALLACIES OF NETWORKED COMPUTING ▸ The network is reliable ▸ There's no latency ▸ Bandwidth is unlimited ▸ The network is secure

FALLACIES CONTINUED ▸ The topology won't change ▸ Administrators will know what to do ▸ Transport is free ▸ Networks are homogeneous

Exeunt, stage left