Slide 1

Slide 1 text

A competitive food retail architecture with microservices A five year journey Sebastian Gauder Software Architect eCommerce @rattakresch

Slide 2

Slide 2 text

Our history

Slide 3

Slide 3 text

3 Details REWE Group Turnover >57 bn History >90 years Employees >345.000 Inudstries Food Retail, Tourism, DIY Shops >15.000

Slide 4

Slide 4 text

Our history - the overview

Slide 5

Slide 5 text

Service/team growth 2014 40 15 100 28 200 46 2015 2016 2017 # Services # Dev Teams 1 2 2018 270 48

Slide 6

Slide 6 text

Organization and Architecture at Rewe Digital Domain Subdomain Bounded Context Tribe Squad Team Platform Service Is modelled as Consists of Consists of 1 N 1 N 1 N Consists of 1 N Consists of 1 N 1 1 1 1 N 1 Builds Builds 1 N Implements Fulfills requirements of 1 1 Is responsible for

Slide 7

Slide 7 text

How to scale monoliths?

Slide 8

Slide 8 text

Design Goals Vertical Boundaries Decentralization

Slide 9

Slide 9 text

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” Melvin Conway (1967) Conway’s law

Slide 10

Slide 10 text

How to organize teams to build a scalable system? Functional and vertical teams Frontend Backend Database QA Ops ... Team A Team B Team C

Slide 11

Slide 11 text

How to determine boundaries?

Slide 12

Slide 12 text

Customer journey defines subdomains Product Information Backoffice Mobile Plattform Fulfillment Customer Check-in Product Discovery Checkout

Slide 13

Slide 13 text

Fulfillment Fullfilment domain transformation Inbound Inventory Outbound Realization Master Data Platform Backoffice

Slide 14

Slide 14 text

How to guide 150+ developers?

Slide 15

Slide 15 text

Design Goals - Vertical boundaries - Decentralization Architectural principles - Collection of 9 basic ‘laws’ - Autonomy, Automation and Communication Guides - Practical manual for common tasks (RFC 2119) - e.g. Eventing, REST, Authentication Guarding rails for developers MUST SHOULD COULD

Slide 16

Slide 16 text

Architectural principles

Slide 17

Slide 17 text

autonomy

Slide 18

Slide 18 text

Autonomy principles Deploy independently Ensure that the services can and are deployed by the teams themselves. Isolate failure Make the services as resilient as possible. Hide implementation Details Different verticals must be stateless and must not share state. Encapsulate Data Storage For any data resource exactly one service is responsible. If possible, the data supply should proceed asynchronously in the background

Slide 19

Slide 19 text

Bloated Features - Smaller features (MVP) -> fewer teams, lesser synchronization overhead Big Bang Releases - Appropriate patterns -> smaller risk, lesser need for synchronization Urge for Reutilization and Shared Libraries - “WET is the new DRY” The classic enemies of autonomy

Slide 20

Slide 20 text

Autonomy opens your tech stacks

Slide 21

Slide 21 text

automation

Slide 22

Slide 22 text

Automation principles Be Scalable Services are scaled horizontally Embrace a Culture of Automation Test, deployment and operations are completely automated Be Highly Observable Use of semantic monitoring to see if the whole platform works correctly.

Slide 23

Slide 23 text

communication

Slide 24

Slide 24 text

Communication principles Standardize Service communication Inter-service communication is standardized and if possible asynchronous Follow REST Principles The API of a service follows the RESTful paradigm (REST maturity level 2)

Slide 25

Slide 25 text

Communication in microservice worlds Having data is better than fetching data µService Event-API (Kafka) REST-API (JSON) UI-API (HTML)

Slide 26

Slide 26 text

Problems in HTTP/REST-only architectures Gateway µService 1 µService 2 µService 5 µService 4 Things that help: ● Timeouts ● Fallbacks ● Circuit Breakers ● Eventing µService 3

Slide 27

Slide 27 text

Eventing with Apache Kafka ● Eventing != Messaging ○ Publish events that already happened ○ One owning service per queue/topic ● Eventing != Event Sourcing ○ Complete entities - not deltas ○ Allows log compaction ● Re-writing and Re-reading ○ needed in case of additional data ○ useful in case of data loss

Slide 28

Slide 28 text

Eventing is an API as well - Events have to behave like APIs and avoid breaking changes. Writing (generic) APIs is hard - Teams tend to write APIs for special clients (e.g. mobile apps) Breaking changes require a strict procedure - Must be solved by introducing new endpoints / new topics Lessons learned with microservice communication

Slide 29

Slide 29 text

How to access?

Slide 30

Slide 30 text

Usage of API gateways as entry points How to access Microservices?

Slide 31

Slide 31 text

What about frontend?

Slide 32

Slide 32 text

Dynamic frontend composition How UIs in microservice architectures should be composed

Slide 33

Slide 33 text

Dynamic UI composition with DUC Where does my UI come from?

Slide 34

Slide 34 text

Git Project: rewe-digital/integration-patterns https://git.io/vA2MY

Slide 35

Slide 35 text

Thank you Questions ?

Slide 36

Slide 36 text

A competitive food retail architecture with microservices A five year journey with microservices Sebastian Gauder Software Architect eCommerce @rattakresch