1.
Streamlining
Product
Handovers and
Takeovers
UXDX Helsinki 2020,
March 17
MATTHIEU GUILLERMIN,
MAKSIM EKIMOVSKII
17-03-2020

2.
2
WHY?

3.
5
ZALANDO AT A GLANCE
~ 6.5billion EUR
revenue 2019
~ 350
million
visits
per
month
~ 15,000
employees in
Europe
> 80%
of visits via
mobile devices
31
million
active customers
> 500,000
product choices
> 2,500
brands
17
countries
as of September 2019

4.
6
SOME OF OUR MOST INNOVATIVE TECH IS DEVELOPED IN HELSINKI
Connected retail
We are integrating 640,000 physical
stores into the Zalando
New product for Zalando, launched in
March 2018 and built in Helsinki.
Zalando logistics
Warehouse software to manage logistics
network complexity and improving
distribution of the goods
Fashion Store
Personalised content selection

5.
7
CAMPAIGNS & COLLECTIONS TEAM

6.
8
CAMPAIGNS & COLLECTIONS TEAM
Happy
customer
Interface Framework
Content selection systemContent solutions
system
UI Tool 1
BFF
service
Mgmt
API
Q1
...
Mgmt
API
...
...
...
Fashion
Store
API
Delivery
API
Entity IDs
Internal
users GraphQL
Media
service
Validations
API
Score
Rendering
Engine
Renderers
...
UI Tool 2 BFF 2
Mgmt
API 2
Q2
...
Outfit
Mgmt
Creator
Mgmt
Legend
Outside scope
Within scope
Search
...
UI tool 3 ... Q3 ... Q3
Catalog
Auction

7.
9
ZALANDO TECH “KITCHEN”
1. Autonomous teams = You run what you’ve built
2. Cloud native = AWS + K8S + Continuous Delivery
3. Open code = Everyone can see the code of everyone
4. API First = Microservices + OpenAPI REST (guidelines)
5. Writing culture = Our engineers are great writers

8.
10
2019: SCALE
140Clusters
~400Accounts
~200Engineering teams

9.
11
dwwd
THE 5 PRINCIPLES
OF A TAKEOVER

10.
12
THE 5 PRINCIPLES
1. Start early
Better safe than sorry
2. (Over-) communicate
DRY? Please, repeat yourself, leave nothing to chance
3. One document as a single source of truth
Write it. Pale ink is better than the best memory
4. Iterate
Don’t try to solve everything at once
5. “Don’t break things”
Luckily you know how to fix it when it happens, right?

11.
13
1. START EARLY
● Estimate your team capacity
How many people need to be involved?
● Identify constraints and risks
Time constraints? Do we know a tech stack of the project?
● Innersource small things when possible
Learning by doing is a good way to get familiar with a new
project. Start small.

12.
14
2. (OVER-) COMMUNICATE
● With involved teams
In-person, hangouts, via google docs.
● With your stakeholders
Make sure they know whom to contact in case of issues,
requests, etc.
● Via documenting exhaustively
Gather as much info as possible while previous team is there and
knowledge is fresh.

13.
15
3. ONE DOCUMENT AS A USE SINGLE SOURCE OF TRUTH
● Create it
Create a google doc, put all info there, document exhaustively
● Share it
Everyone should know where to look and track the progress
● Get feedback
Gather as much info as possible while previous team is there and
knowledge is fresh.

14.
Document collaboration demo

15.
Document collaboration demo

16.
23
4. ITERATE
● We know how to operate the system
Monitoring, logs, alerts. Incident impact is clear
● We know the dependencies and stakeholders
Upstream/downstream. Relevant contacts
● We know how to fix small bugs
Development/deployment process is clear
● We know how to evolve the project
Ability to build mid/long-term features. Longer-term vision

17.
24
5. “DON’T BREAK THINGS”
● Blue-Green deployment model
Make API, database, message queue migrations great again
● Graceful URLs migrations
Make use of DNS CNAME records, give people time to migrate
● Monitor access logs and help stakeholders to switch
Log requests with old URLs, notify the owners

18.
25
BLUE-GREEN DEPLOYMENT MODEL
https://martinfowler.com/bliki/BlueGreenDeployment.html

19.
26
API MIGRATIONS
Route53 Route53
old-cluster new-cluster
CDP

20.
27
API MIGRATIONS
Route53 Route53
old-cluster new-cluster
CDPCDP

21.
28
API MIGRATIONS
Route53 Route53
old-cluster new-cluster
CNAME

22.
29
API MIGRATIONS
Route53 Route53
old-cluster new-cluster

23.
30
DATABASE MIGRATIONS
● Downtime for writes is allowed
The system can tolerate no writes for minutes or few hours
● Only minimal downtime for writes is allowed
The system can tolerate no writes only for few minutes

24.
31
DOWNTIME ALLOWED -> CLONING
S3 Backups
S3 Backups
(empty)
old-cluster new-cluster
API

25.
32
DOWNTIME ALLOWED -> CLONING
S3 Backups S3 Backups
old-cluster new-cluster
API
1. Read-only mode
2. Restore from the backup

26.
33
DOWNTIME ALLOWED -> CLONING
S3 Backups S3 Backups
old-cluster new-cluster
API

27.
34
MINIMAL DOWNTIME ALLOWED
S3 Backups
S3 Backups
(empty)
old-cluster new-cluster
API

28.
35
MINIMAL DOWNTIME ALLOWED: STANDBY
S3 Backups S3 Backups
old-cluster new-cluster
API
Standby cluster
1. Restore from the backup
2. Keep replicating the data

29.
36
MINIMAL DOWNTIME ALLOWED: PROMOTE
S3 Backups S3 Backups
old-cluster new-cluster
API
Promote to master

30.
37
MINIMAL DOWNTIME ALLOWED: DETACH
S3 Backups S3 Backups
old-cluster new-cluster
APIAPI

31.
38
dwwd
CONCLUSION

32.
39
THE 5 PRINCIPLES
● Start early
● (Over-) communicate
● One document as a single source of truth
● Iterate
● “Don’t break things”

33.
40
WHAT’S NEXT?
● Assess integration with existing components
Does it make sense? Are there overlaps?
● Define a target architecture
Based on a longer-term vision and strategy
● Progress step by step towards the target
Re-assess as you go

34.
Questions?

35.
MATTHIEU GUILLERMIN
Engineering Lead,
MAKSIM EKIMOVSKII
Senior Software Engineer
matthieu.guillermin@zalando.fi
maksim.ekimovskii@zalando.fi
17-03-2020