Project A's CTO Stephan Schulze presents in his talks his learnings when building a mircroservice architecture for a 100mio+ revenue company. The talk was held at codetalks conference in Berlin, April 2017 by Stephan Schulze (Twitter: @nahpeps)

1. Lessons learned when
building a microservice architecture
for a 100mio+ revenue company
28.04.2017

2. ???

3. Summary – Takeaways
1. Microservices are no silver bullet!
2. Microservices come with a lot of
complexity that you don’t see at the first
glance!
3. Microservices are a tool. Check if it is the
right one!

4. About me
 Stephan Schulze
 CTO@Project A
 stephan.schulze@project-a.com
 https://www.linkedin.com/in/stephan-schulze-24115957/
 https://twitter.com/nahpeps
 https://insights.project-a.com/tagged/tech

5. Our Project

6. Introduction – Overview
 Developing a new eCommerce
Platform based on a microservice
architecture
 Current KPIs:
 Revenue: > 100mio€/year
 SKUs: 500k
 Expected KPIs:
 Revenue: > 200mio€/year
 SKUs: 1.5mio
 General Expectations:
 Scalable, flexible, developed
inhouse
 Should allow to run different
business models in parallel
 Should be suitable for online
and offline sales

7. Introduction – Our stack
 Infrastructure Stack:
 AWS
 Terraform
 Kubernetes
 Docker
 Application Stack:
 Java
 PHP
 Nginx
 Tomcat
 PostgreSql
 Redis
 …

8. Introduction – Our stack

9. Introduction – A common understanding of microservices
Microservices are a distributed System
Characteristics:
 isolated vertical infrastructure for each service
 communication only via APIs
 no referential integrity across services
 each service serves one business domain
 Service provides its own HTML (Customer Facing and Backoffice)

10. Introduction – The abstract architecture
R
o
u
t
i
n
g
/
R
e
n
d
e
r
i
n
g
S1
S5
S2
S6
S4
S7
S9
S3
S8

11. Lets start…

12. Preparation

13. Challenge – Preparation
 Think about and define basic parameters for your system
 Communication formats (Language; Protocol; Message Formats; Error Handling, …)
 Security Model
 Notifications and Configuration Mgmt.
 API Versioning
 Deployments
 Document your results

14. Examples

15. Challenge – Preparation – Examples
 API Request with Success:

16. Challenge – Preparation – Examples
 API Request with Error:

17. Challenge – Preparation – Examples
 API-Versioning

18. Challenge – Preparation – Examples
 Documentation

19. Challenge – Preparation – Takeaways
1. You will not be prepared enough!
2. Build PoC application infrastructure and
test it.
3. Have a common understanding and
documentation.

20. Global Data

21. Challenge – Global data types
 Rare changing data:
 Countries
 Languages
 Currencies
 can be part of the service
 should be cached
 Often changing data
 User/Customer Sessions
 Tracking
 Must not be part of the service
 Must not be cached
 Regular changing data
 URLs
 Configurations
 Permissions
 should not be part of the service
 should be cached

22. Examples

23. Challenge – Global data – How we share it
 Rare/Regular changing data is:
 Provided by a central registry
 Cached in the service
 Updated via deployment and notification
 Often changing data is:
 Part of the request/response of a service call

24. Challenge – Global data – Example: Session Data
 Routing/Rendering Service is session data master
R
o
u
t
i
n
g
/
R
e
n
d
e
r
i
n
g
S1
S5
S2
S6
S4
S7
S9
S3
S8

25. Challenge – Global data – Example: Session Data
 Routing/Rendering Service is session data master
 Each service has its namespace in the session
 There is a global part in the session which is well defined
 Session data is part of the request header, including:
 Global part
 Service specific part
 Updates to the session are part of the response of a service request
 Problem:
 Inconsistent Global Data in two different services

26. {{Header}}
{{Content}}
Template1
Routing/Rendering
Challenge – Global data – Example: Session Data
S1
S2
/url123
URL Template
/url123 Template1
/url1234 Template2
… …
URL Placeholder Service Endpoint
/url123 Header S1 /header
/url123 Content S2 /customer/login
… …
/header
/customer/login
 Problem: Inconsistent Global Data in two different services

27. Challenge – Global Data – Takeaways
1. Independent of what others say:
There will be global data and you will
depend on it.
2. Thinking about different data types and
the best implementation approach early,
helps a lot!

28. Security

29. Challenge – Security
 Rule #1: Don’t trust anybody else
 Roles and Permissions
 Must be part of your architecture from day one
 Tokens (e.g. JWT) or similar approaches are best practice
 token can contain permissions already
OR
 Permissions can be provided by a central registry
 Each service must care about its own security

30. Examples

31. Challenge – Security – Example: API Permissions

32. Challenge – Security – Example: Permissions – Grants
 Permissions are not only for users but also for services

33. Challenge – Security – Token (in)validation
 How do I know whether a Token is still valid?
 Two approaches:
1. Authorize Token on every call
2. Cache permissions and token locally
 We go for approach 2
 If permissions behind a token changes or token becomes invalid
 Whole system is notified
 every Service must take care on its own

34. Challenge – Security – Example: Permissions at S2S
calls
 Situation
 User registers new Customer in Backoffice (via CustomerService)
 Registration requires Discount creation (DiscountService)
 Registrations requires sending a Welcome Mail with Discount (via Mailservice)
 Case 1: User Token is used for subsequent calls
 User must have permission to create Discounts and send welcome Mails also
 Case 2: CustomerService Token is used for subsequent calls
 User must have permission to create Customer
 CustomerService must have permissions to do all business steps

35. Challenge – Security – Takeaways
1. Security is crucial
2. Use tokens (and think about how to
authorize and invalidate them)
3. Take care of a chain of rights

36. Versioning

37. Challenge – Versioning
 What need to be versioned?
 Whole services
 Service APIs
 Service Frontends and so Assets, Sessions, Permissions, …
 Things get more complicated:
 Services must provide more than one API version at once
 Different API Versions of a Service can have a dependency to different API Versions
of other services
 Different API Versions will operate on the same database

38. Examples

39. Challenge – Versioning – our Approach for APIs
 API Version is part of the request header
 One Service release must support multiple API/Frontend versions
 Every service expose the API versions it offers and it consumes (in code)

40. Challenge – Versioning – our Approach for APIs
 How does that look at runtime?
Release 1
API: 1.2.3
Release 2
API: 1.2.3
API: 2.0.0
Release 3
API: 1.2.3
API: 2.0.0
API: 2.1.0

41. Challenge – Versioning – our Approach for APIs
Release 3
API: 1.2.3
API: 2.0.0
API: 2.1.0
X-Api-Version: 1.2
X-Api-Version-Used: 1.2.3
X-Api-Version: 1.2.3
X-Api-Version-Used: 1.2.3
X-Api-Version: 2
X-Api-Version-Used: 2.1.0
X-Api-Version: 3.1.0
ERROR

42. Challenge – Versioning – Takeaways
1. Versioning is a pain but necessary
2. A lot parts in the application
can/should/must be versioned
3. Validating API/Service dependencies
should happen before deployment

43. Logging

44. Challenge – Logging – Areas
 Infrastructure centric: everything necessary to run a service
(Docker, Kubernetes, …)
 Service centric: everything that is related to a specific service
(Webserver, ApplicationEngine)
 Application centric: everything that is related to the application itself
(Exceptions, Warnings, Notices, …)
 Major Question: How should be logged and what?

45. Examples

46. Challenge – Logging – Our stack
 Logs are going to stdout
 Using Fluentd as logshipper to elasticsearch setup
 Why not logstash?
 Much faster ramp up
 Native kubernetes integration
 Each log entry includes:
 Instance-Id (always)
 Service release (if available)
 API-Version (if available)
 Correlation-Id (if available)
 Visitor-Id (if available)

47. Challenge – Logging – Correlation and Visitor Id
 Correlation Id  forwarded by each service or created if none is available
 See the way of a request through the whole application
 Is valid for one request
 Visitor Id  forwarded by each service if received
 Group all calls of a specific User/Customer
 Stored at the User/Customer for longterm usage

48. Challenge – Logging – Correlation and Visitor Id

49. Challenge – Logging – Takeaways
1. You need to know everything!
2. Infrastructure vs. Applications vs. Request
Logs  each of them matter
3. Using Correlation-Ids and Visitor-Ids is
recommended
4. Service-Identifier, -release, -instance and
API Version must be part of every
application log entry

50. What comes next?

51. I could continue for a while…

52. The question is still…

53. Questions?

54. Contact
Stephan Schulze
CTO
Project A Services GmbH & Co. KG
Julie-Wolfthorn-Str. 1
10115 Berlin
Tel: + 49 30 340 606 300
Fax: + 49 30 340 606 399
stephan.schulze@project-a.com
www.project-a.com
facebook.com/projectaberlin
twitter.com/projectacom