Slide 1

Slide 1 text

Messaging Between Microservices Lorna Mitchell, Developer Advocate, IBM

Slide 2

Slide 2 text

Microservices are components by a buzzier name @lornajane

Slide 3

Slide 3 text

Messaging is how data moves between the components @lornajane

Slide 4

Slide 4 text

Microservices or SOA @lornajane

Slide 5

Slide 5 text

Gathering Data @lornajane

Slide 6

Slide 6 text

A swarm of tiny apps talking to the same storage is not microservices; it is an HTTP-enabled monolith. @lornajane

Slide 7

Slide 7 text

Data Hygiene Access to each storage piece should be "owned" by one component • decoupling improves scalability • some platforms charge by execution time; don't wait for a network call • improves maintainability - and sanity @lornajane

Slide 8

Slide 8 text

Moving Data @lornajane

Slide 9

Slide 9 text

Start with Security We know how to secure HTTP connections, so do it! • Auth standards e.g. JWT • Security in transmission: use HTTPS @lornajane

Slide 10

Slide 10 text

One System, Many Pieces @lornajane

Slide 11

Slide 11 text

Consider the Medium Is this a web request, with headers? A message on a queue e.g. RabbitMQ or Kafka? @lornajane

Slide 12

Slide 12 text

Designing Data Formats • JSON or XML? • Binary formats? • Apache Thrift • Protocol Buffers • Avro • Data vs MetaData @lornajane

Slide 13

Slide 13 text

Ship the documentation first; it's the cheapest phase of the project to fix bugs in @lornajane

Slide 14

Slide 14 text

Docs-First API Design • Quick and cheap to produce and change • Everyone can participate and discuss • Details (including field names!) are sorted out early Documentation is the first deliverable, and it's a living artefact (keep it in your repo) @lornajane

Slide 15

Slide 15 text

Returning Data @lornajane

Slide 16

Slide 16 text

Components that work alone need excellent log arrangements. It is the only way they can communicate with you. @lornajane

Slide 17

Slide 17 text

Logging and Microservices • Standard, configurable logging setup • Use a trace_id to link requests between services • Aggregate logs to a central place, ensure search functionality • Collect metrics (invocations, execution time, error rates) • display metrics on a dashboard • have appropriate, configurable alerting @lornajane

Slide 18

Slide 18 text

Originator Feedback In a microservices application: • errors can occur at any time • the last microservice should send information to the originating application • remember that distributed systems get everything done but not necessarily in the order you expect @lornajane

Slide 19

Slide 19 text

Data In Microservices @lornajane

Slide 20

Slide 20 text

Data In Microservices • Where does data come from? Where does it enter the application? • How does data move safely around the application? • How is data conveyed back out of the application? @lornajane

Slide 21

Slide 21 text

Resources • Website: https://lornajane.net • Email me: [email protected] Further reading: • Designing Data-Intensive Applications By Martin Kleppmann • Production-Ready Microservices By Susan J. Fowler @lornajane