This is the presentation I gave at µCon London 2017: The Microservices Conference on 7-th November. Baker is an open-source library we developed at ING so solve the problem of building an orchestration API for a long-running process with process and information state, with a resilient and scalable architecture.

1. Declare, verify and execute
microservices-based process
flows with Baker
http://github.com/nikolakasev | ING
1

2. 2

3. 3

4. 4

5. Symptoms of a Failing Restaurant
5

6. 6

7. 7

8. 8

9. Symptoms of a Failing (Microservices)
Architecture
9

10. Afraid to change the application code
10

11. Functionality breaks unexpectedly
11

12. Slow time to market
12

13. How to turn this around?
13

14. 14

15. 15

16. 16

17. 17

18. 18

19. Simplify
Domain Specific Language for
orchestration flows
Declarative
Easy to change
19

20. Reuse
Recipes
Interactions
Ingredients
Events
20

21. Communicate
Visualize your code
Non-IT understand as well
Reason About Comfortably
21

22. Design-time
22

23. public interface RegisterIndividual extends Interaction {
@FiresEvent(oneOf = {RegisterIndividualSuccessful.class,
RegisterIndividualFailed.class})
RegisterIndividualOutcome apply(
@ProcessId String processId,
@RequiresIngredient("name") String name,
@RequiresIngredient("address") String address
);
}
23

24. public interface RegisterIndividual extends Interaction {
@FiresEvent(oneOf = {RegisterIndividualSuccessful.class,
RegisterIndividualFailed.class})
RegisterIndividualOutcome apply(
@ProcessId String processId,
@RequiresIngredient("name") String name,
@RequiresIngredient("address") String address
);
}
24

25. 25

26. 26

27. 27

28. public Recipe get(){
return new Recipe("MuConf2017Demo").
withInteractions(
of(AssignAccount.class),
of(GetAccount.class),
of(RegisterIndividual.class));
}
28

29. 29

30. return new Recipe("MuConf2017Demo").
withInteractions(
of(AssignAccount.class),
of(GetAccount.class).
withRequiredEvent(TermsAndConditionsAccepted.class),
of(RegisterIndividual.class)).
withSensoryEvents(
TermsAndConditionsAccepted.class,
IndividualInformationSubmitted.class);
}
30

31. 31

32. Run-time
32

33. //for each process instance, bake the recipe
baker.bake(processId);
//notify Baker when events occur
baker.processEvent(processId, new SensoryEvents.IndividualInformationSubmitted(name, address));
baker.processEvent(processId, new SensoryEvents.TermsAndConditionsAccepted());
//retrieve ingredients stored in the accumulated state
assert(baker.getIngredients(processId).get("customerId").equals(customerId));
assert(baker.getIngredients(processId).get("iban").equals(iban));
//retrieve all events that have occurred
Set<String> occurredEvents = new HashSet<>(
baker.getEvents(processId).getEventNameList()
);
33

34. 34

35. Under the Hood
35

36. Why Scala?
4 Best fit for developing DSLs1
on the JVM
4 Compile-time recipe validation
4 Type safety
1
https://martinfowler.com/books/dsl.html
36

37. Why Akka?
4 Event Sourcing2
(events can be replayed)
4 Persistent actors (with Cassandra)
4 Distributed actors across machines (with cluster
sharding)
2
http://martinfowler.com/eaaDev/EventSourcing.html
37

38. Why Petri net?3
3
https://en.wikipedia.org/wiki/Petri_net
38

39. 39

40. 40

41. 41

42. 42

43. 43

44. Best Practices
44

45. Short-lived vs. long-running flows
45

46. State is taken care of:
4 Cassandra for persistent storage
4 Ingredients encrypted by default
4 State recovered automatically
46

47. Run Baker inside of your API
"Smart endpoints and dumb pipes"
47

48. When failure occurs:
4 Baker retries technical failures with exponential
backoff
4 Works well with idempotent services
4 Deal with functional failure in your recipe
48

49. Baker Capability Matrix:
4 Investigate not one, not two, but all business
processes in your company
4 Where do you see re-use?
4 Map using MoSCoW4
to give importance (M = 10, S =
5, C = 2, W = 1)
4
https://en.wikipedia.org/wiki/MoSCoW_method
49

50. Checking Account Savings Account Customer Onboarding
Verify Identity Verify Identity Verify Identity
Register Individual Register Individual Register Individual
Open Checking Account Open Savings Account n/a
Issue Debit Card n/a n/a
Send Message Send Message Send Message
Register Product
Owner
Register Product
Owner
n/a
50

51. https://github.com/ing-bank/baker
51

52. 52

53. Speed of change matters to anyone building software.
Many engineering teams have identified Microservices as
an important component of this architectural approach to
designing more flexible systems that can meet the needs of
their fast changing businesses. Applying this approach
however, is hard. And ideas and practices are still very
much evolving. To help with that, we've launched muCon - a
conference to learn about emerging technologies and
approaches, share challenges and evolve practices and
ideas.
53

54. Their applications are built on top of microservices. If
there careful enough their application serve bad meals.
If we are building microservices or a monolith or any
type of service in general we are serving business logic
to our clients. So no matter what we can not escape the
architectural discussion.
If we are not careful of how we architect our
applications we end up serving bad meals.
54

55. I love cooking food and for the rest of the talk I'll be using analogies from
there. It's very similar to our industry: long hours, hard work, and
delivering experiences to our customers.
Have you been woken up at 3 o'clock in the morning on a Saturday morning
after a night of partying, having to go to the war room and resolve an
application incident. I've been there. When I remember the cold of the
airconditioners, it still makes me shiver.
If we are building microservices or a monolith or any type of application in
general we are serving business logic to our clients. So no matter what, we
cannot escape the architectural discussion. If we are not careful of how
we architect our applications we end up serving a bad meal to our clients.
55