Broken Promises.

Transcription

1 Broken Promises

2 Data is dangerous

3 Microservices are usually required to cooperate to achieve some end goal.

4 Microservices need to be able to trust each other in order to cooperate.

5 Microservices cooperate, they are symbiotic but not parasitic.

6 Microservices have a relationship to each other, but also a relationship with data.

7 There are different types of data that microservices must deal with. 1. Agent internal-data (aka entities) 2. Persisted Data 3. External Service Data

8 How data destroys relationships: Data can Lie 1.Lies of omission 2.Lies of commission

9 How data destroys relationships: Data can be Corrupt Corrupted by good or bad actors.

10 How data destroys relationships: Data can be high maintenance. Hard to secure some, but everyone pays the price.

11 How data destroys relationships: Data is dumb. Data is not self-aware.

12 How data destroys relationships: Data is dumb. Data is too dumb to drive things. To drive something you need to know direction, how to steer, how to interpret.

13 How data destroys relationships: Data is dumb. Data can only inform.

14 How data destroys relationships: Data is dumb. Stateless Architecture, another broken promise

15 If a microservice cannot rely on data to properly inform, then what?

16 We need trust.

17 Microservices be able to make and keep promises.

18 Promise theory is an engineering framework for coping with uncertainty in information systems.

19 Promise theory is an engineering framework for coping with uncertainty in information systems.

20 Promise theory is an engineering framework for coping with uncertainty in information systems.

21 Promise theory is an engineering framework for coping with uncertainty in information systems.

22 Uncertainty Divergence vs Convergence

23 Uncertainty Divergence vs Convergence

24 Uncertainty Divergence vs Convergence

25 Promises help you converge.

26 Obligations aren t better?

27 Back to data and winning back trust

28 Facts AKA Events

29 Facts Should be immutable Should be relevant, or germane to the state at play Could be used to assess whether a promise has been kept.

30 Opinions AKA Views

31 Opinions Views should be generated as a result of ingesting facts. Views should be based on facts. Could be used to broadcast whether a promise was kept.

32 Systems are composed of facts, opinions. States and views.

33 Give data benevolent masters or stewards capable of making and keeping promises.

34 What makes a good steward of state?

35 What makes a good steward of state? Should be smart, intelligent, knowledgeable

36 What makes a good steward of state? Should produce the right, relevant data for its state.

37 What makes a good steward of state? Should know what is a good fact vs a bad fact.

38 Masters need to have clear properly managed boundaries. Context matters.

39 Masters need to have clear properly managed boundaries. Context matters.

40 Masters should be resistant to corruption.

41 A good master is autonomous and responsible.

42 How does a stateful steward repair itself?

43 How does a stateful steward repair itself? By rebuilding the state from events.

44 How does a stateful steward repair itself? By using compensating actions.

45 How does a stateful steward repair itself? Having and executing on info to resolve conflicts.

46 How does a stateless advisor, view creator, repair?

47 How does a stateless advisor, view creator, repair? Rebuild views.

48 Some views need to be fact based, others do not.

49 Some views need to be fact based, others do not.

50 Some views need to be fact based, others do not.

51 Good masters aren t data-driven, they drive the data

52 Data should be isolated Isolation; bad for humans, good for data

53 Promote Isolation & Autonomy by Separating Facts from Views Service API Service Implementation State Changing Requests Data View Requests Facts Views

54 Enter Lagom

55 Lagom empowers your master stewards through isolation, autonomous services

56 Remember - different types of data that microservices must deal with. 1. Agent internal-data (aka entities) 2. Persisted Data 3. External Service Data

57 Account Context account A $$ account C Current Account Balance is the State account B Agent Internal Data

58 Lagom Encourages and Enables You to Contain Mutable State & Publish Facts

59 Store facts as source of truth Entity with published intent

60 Store facts as source of truth Command + Outer Boundary Call

61 Entities in a Cluster Always Maintain a Current view of State

62 Lagom Allows you specialize in order to have the right properties for stewarding events/views.

63 Stateful Agents Stateless Agents FACTS VIEWS

64 Account Context account A account B account C $$ You can do transactions in the boundary of your persistent entity

65 Order Context Manages Saga Shopping Context Fulfillment Context Checkout Context Payments Context

66 Lagom uses asynchronous messaging, asynchronous IO & distributed persistence patterns

67 client command command node node node Reactive programming REST messaging streaming Stateless Behavior command command Service discovery Service gateway Authentication node node command Reactive programming Stateful Entity Reactive System Write model event log DS Event (fact) Event (fact) Event (fact) Event (fact) Read model query db DS

68 Reactive System akka data play akka JavaRX Reactive Systems design is used in between the Microservices, allowing the creation of systems of Microservices that play by the rules of distributed systems Responsiveness through Resilience and Elasticity made possible by being Message-Driven. spring

69 Summary Data can hurt relationships if you let it. Build trust by managing data with specialized stewards. Empower your entities to keep their promises. Managing state requires care, awareness. Distributed systems require a level up on the care.

70 Summary