Embed Size (px)
Citation preview
Lessons learned when
building a microservice architecture
for a 100mio+ revenue company
28.04.2017
???
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!
About me
Stephan Schulze
CTO@Project A
https://www.linkedin.com/in/stephan-schulze-24115957/
https://twitter.com/nahpeps
https://insights.project-a.com/tagged/tech
Our Project
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
Introduction – Our stack
Infrastructure Stack:
AWS
Terraform
Kubernetes
Docker
Application Stack:
Java
PHP
Nginx
Tomcat
PostgreSql
Redis
…
Introduction – Our stack
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)
Introduction – The abstract architecture
Routing/Rendering
S1
S5
S2
S6
S4
S7
S9
S3
S8
Lets start…
Preparation
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
Examples
Challenge – Preparation – Examples
API Request with Success:
Challenge – Preparation – Examples
API Request with Error:
Challenge – Preparation – Examples
API-Versioning
Challenge – Preparation – Examples
Documentation
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.
Global Data
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
Examples
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
Challenge – Global data – Example: Session Data
Routing/Rendering Service is session data master
Routing/Rendering
S1
S5
S2
S6
S4
S7
S9
S3
S8
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
{{Header}}
{{Content}}
Template1Routing/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
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!
Security
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
Examples
Challenge – Security – Example: API Permissions
Challenge – Security – Example: Permissions – Grants
Permissions are not only for users but also for services
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
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
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
Versioning
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
Examples
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)
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
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
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
Logging
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?
Examples
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)
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
Challenge – Logging – Correlation and Visitor Id
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
What comes next?
I could continue for a while…
The question is still…
Questions?
Contact
Stephan SchulzeCTO
Project A Services GmbH & Co. KG
Julie-Wolfthorn-Str. 1
10115 Berlin
Tel: + 49 30 340 606 300
Fax: + 49 30 340 606 399
www.project-a.com
facebook.com/projectaberlin
twitter.com/projectacom
