Slide 1

Slide 1 text

DISTRIBUTED SYSTEMS INTRODUCTION Dev Camp 2014

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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)

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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!

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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)

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Fin :)

Slide 18

Slide 18 text

COUPLING together

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

PLATFORM COUPLING ▸ Standards-based protocols to improve interoperability

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

THE NETWORK matters

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Exeunt, stage left