How to f*ck up your development team with microservices

How to f*ck up your Development Team
with Microservices
Learnings about the Do’s and Don’ts of microservices
that may save your project and development team
Stephan Schulze | 26th October 2018

Contact with me
Email
stephan.schulze@project-a.com
Twitter
twitter.com/nahpeps
LinkedIn
linkedin.com/in/stephan-schulze-24115957/
Website
www.project-a.com
2
Stephan Schulze
CTO - Project A
Talk to me
Everytime at this conference

Project A - The operational VC
We empower tomorrow’s digital winners - www.project-a.com
The fund:
260mio
Assets under management
The people:
100
hands-on professionals
3

Agenda
Teams
3
Scalability
4
4
Introduction and Learnings1
Complexity
2

Disclaimer
It is not all bad!
5

The History
Where are the learnings
coming from?
6

Highlevel Overview
7
Stock &
Availabilities
Saleschannel 1 Saleschannel 2 Saleschannel 3 ...
Routing Service
Content.
Service
Car
Service
Product
Service
Stock
Service
Price
Service
Search
Service
Styleguide
Service
Log
Service
Core
Service
Checkout
Service
Order
Service
Customer
Service
Email
Service
Calculation
Service
Payment
Service
ERP-Conn.
Service
Backoffice
PDM Pricing ERP
Sales Order
Hub
Logistics Finance
Payment
Provider

More Details
8
Example Service
ApplicationWebserver
Caching Queueing
Storage StorageEC2 EC2 EC2 EC2
Managed
Elasticsearch
Managed
Database (RDS)
EC2

Some statistics
9
up to 44 Devs & DevOps & PM
for 2 years
~ 12k files
> 65 GitHub Repositories
> 3 mio Lines of Code
in Java, PHP and
Python
10 live running Environments
17 Services in production
on an AWS / K8s stack

Major Learnings
10

Learning 1
11
You will underestimate the
complexity and so effort!

Learning 2
12
Microservices foster isolation!

Learning 3
13
Scaling has a price!

Agenda
Complexity2
Introduction and Learnings
1
Teams
3
Scalability
4
14

15
Screenshot from: https://de.slideshare.net/AmazonWebServices/data-design-for-microservices
What about:
- Security?
- Local Development?
- Testing?
…
- People?
Infrastructure
Application
Infrastructure

Complexity is never mentioned
16
Why?
Because it is hard to
explain and to understand!

Example 1 - Deployments
Things to consider
17
▪ How do you deploy?
▪ How do you rollback?
▪ Two different versions of the same service at the same
time
▪ Database migrations must always be backwards
compatible
▪ Does somebody may still use the API you are going to
remove? Should the deployment fail in that case?
▪ How do you know, which service version set is
currently in production?

Example 2 - Versioning
Things to consider
18
▪ How do you version your Services?
▪ What is a stable constellation of Service Versions?
▪ Do you have versioned APIs and Dataformats? Is there
a difference between Service Versions and
API/Dataformat Versions?
▪ Is it possible to support two or more API/Dataformat
Versions in parallel?
▪ Does somebody may still use the Version of the API
you are going to remove? How do you find that out?

Example 3 - Monitoring
Things to consider
19
▪ How do you get an overall system health state?
▪ How do you aggregate logs of different services?
▪ How do you identify a service in the logs?
▪ What calls did one service trigger on other services?
▪ How is your runtime environment doing?
▪ ...
Who is looking at all of this?

Example 4 - Local Dev
Things to consider
20
▪ Can you run the stack on your local machine?
▪ What is the Developer experience?
▪ How do you debug?
▪ How do you know what data is exchanged between the
services → especially in a multilanguage stack?
▪ ...

Don’t forget:
21
1. No business logic yet!
2. This is all per language you use!

Agenda
1
Scalability
4
22
Teams3
Complexity
2

Assumption:
All infrastructure is up and
running!
23

So let us speak about Teams!
24

Our Teamsetup
25
Catalog Team Customer Experience Team
▪ 1x PM/PO
▪ 4x PHP
▪ 3x Java
▪ 1x PM/PO
▪ 4x PHP
▪ 2x Java
Content.
Service
Car
Service
Product
Service
Stock
Service
Price
Service
Search
Service
Core
Service
Routing
Service
Customer
Service
Log
Service
Checkout
Service
Order
Service
Email
Service
Calculation
Service
Payment
Service
ERP-Conn.
Service
Cross Functional Teams - responsible for Services divided by business domain
▪ 1x FE
▪ 1x QA
▪ 1x DevOp
▪ 1x FE
▪ 1x QA
▪ 1x DevOp
Teams are minimal dependent.
They have their own responsibilities and
processes.

Observations - 1
Technical site
26
▪ Members where partially overwhelmed by complexity
of stack and architecture
▪ Overall system architecture knowledge got lost over
time and when system grew
▪ Developer often don’t care about infrastructure layers
▪ Cross Language Knowledge Exchange was rarely
happening

Observations - 2
Communication site
27
▪ The teams worked next to each other but not with each
other
▪ Members tend to stay with their service only
(voluntary or because just nobody else was available)
▪ Members became isolated because nobody else knew
their domain and partially also their language
(especially Java Devs during vacation time)
▪ Cross Team / Cross Language Communication got lost

Frustration
28
As one result!

Slowness
29
As another result!

Lethargy
30
As a third result!

31

What went wrong?
32

The f*ck up part
A summary
33
Strong imbalance in teams
▪ one quiet vs. one communicative Team
▪ Wrong assumptions about what need to be really done
in teams and services
▪ To less PM Power
▪ To less Management Power to address this the right
way

You should know before
34

Questions to ask
Regarding Teamsetup
35
▪ Do I have enough people power?
▪ What defines a Team?
TechStack/Skillset, Business Domain, Personality?
▪ Should I have Cross-Functional teams or clearly
separated by function?
For each potential approach you should also check:
▪ Is there enough to do the whole time?
▪ Can I keep the speed of development?
▪ Is time and/or potential wasted?
▪ How will global topics be handled (e.g. Architecture,
Infrastructure, etc.)?

Agenda
1
Teams
3
36
Scalability4
Complexity
2

Scalability
What to take care of
37
▪ In general: Microservices and development scale
But:
▪ Each Microservice must also be build to scale
▪ The Infrastructure and Application Layer must be build
to scale
▪ The teams must scale
Finally:
The organization itself must scale

“organisations which radically change their system
design should expect changes in communication
structure”
38
This will finally also change the
organization structure itself!
Roy van Rijn

Thank you for listening.
Time for questions

How to f*ck up your development team with microservices

Recommended

Recommended

More Related Content

Similar to How to f*ck up your development team with microservices

Similar to How to f*ck up your development team with microservices (20)

Recently uploaded

Recently uploaded (17)

How to f*ck up your development team with microservices