Slide 1

Slide 1 text

Formal specifications for Microservices Lightning talk © GuanxiLabs 2019

Slide 2

Slide 2 text

Hello 2 François Royer CEO & Principal Consultant francois.royer@guanxilabs.com +33 (0) 6 72 33 75 02

Slide 3

Slide 3 text

What are formal methods and why should you consider them? « Engineers naturally focus on designing the ‘happy case’ for a system, i.e. the processing path in which no errors occur. […] That code path must solve the customer’s problem, perform well, make efficient use of resources, and scale with the business; these are all significant challenges in their own right. Once the design for the happy case is done, the engineer then tries to think of “what might go wrong?”, based on personal experience and that of colleagues and reviewers. The engineer then adds mitigations for these classes of scenarios, prioritized by intuition and perhaps some statistics on the probability of occurrence. » Use of formal methods at Amazon Web Services (2014) Chris Newcombe, Tim Rath, Fan Zhang, Bogdan Munteanu, Marc Brooker, Michael Deardeuff

Slide 4

Slide 4 text

Meet TLA+, by Leslie Lamport The problem definition Invariants and liveness properties (The trains can’t be stuck)

Slide 5

Slide 5 text

Formal methods such as TLA+ can help design complex distributed systems Use of formal methods at Amazon Web Services (2014) Chris Newcombe, Tim Rath, Fan Zhang, Bogdan Munteanu, Marc Brooker, Michael Deardeuff

Slide 6

Slide 6 text

Microservices are hard and are naturally a target for DDD practitioners Building systems using microservices requires us to think more deeply about failure isolation and testing. TLA+ as a formal specification language can be useful in both these scenarios. For failure isolation, TLA+ can be used to identify invariants in your system that can be monitored directly. An invariant can be the ratio of number of requests to one service to the number of requests to a second service, for example. Any change in this ratio would lead to an alert. Source: Thoughtworks Radar

Slide 7

Slide 7 text

The problem … TLA+ can be a significant investment upfront for most projects • Everything is a state machine, which is fine if you’re a physicist or academic CS… • The domain needs to be completely mastered • The syntax takes some time to be accustomed to…

Slide 8

Slide 8 text

DDD methods are great at defining microservice boundaries and events…

Slide 9

Slide 9 text

Software developers must still understand the system behaviour and produce formal specs SHARE AS DOC EXPORT AN API SPEC FOR THE DEV TEAM DEPLOY ON ANY CLOUD FOR COSTING ANALYSIS

Slide 10

Slide 10 text

The DDD ontology appears to define its own regular language, i.e. a state machine… © Alberto Brandolini Entity Repository Factory Value Object Hierarchy And other concepts from the blue book…

Slide 11

Slide 11 text

Let’s build a set of primitives, starting with Commands and Events …

Slide 12

Slide 12 text

… and add time dependency to satisfy liveness …

Slide 13

Slide 13 text

… and finally Entities to add persistence to the workflow

Slide 14

Slide 14 text

Views, bounded contexts follow the same conventions (drag, overlap, link…)

Slide 15

Slide 15 text

francois.royer@guanxilabs.com Interested? www.txime.com @TximeApp