Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building a microservice architecture for a 100mio# revenue company

918 views

Published on

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)

Published in: Software
  • Be the first to comment

  • Be the first to like this

Building a microservice architecture for a 100mio# revenue company

  1. 1. Lessons learned when building a microservice architecture for a 100mio+ revenue company 28.04.2017
  2. 2. ???
  3. 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. 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. 5. Our Project
  6. 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. 7. Introduction – Our stack  Infrastructure Stack:  AWS  Terraform  Kubernetes  Docker  Application Stack:  Java  PHP  Nginx  Tomcat  PostgreSql  Redis  …
  8. 8. Introduction – Our stack
  9. 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. 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. 11. Lets start…
  12. 12. Preparation
  13. 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. 14. Examples
  15. 15. Challenge – Preparation – Examples  API Request with Success:
  16. 16. Challenge – Preparation – Examples  API Request with Error:
  17. 17. Challenge – Preparation – Examples  API-Versioning
  18. 18. Challenge – Preparation – Examples  Documentation
  19. 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. 20. Global Data
  21. 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. 22. Examples
  23. 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. 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. 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. 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. 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. 28. Security
  29. 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. 30. Examples
  31. 31. Challenge – Security – Example: API Permissions
  32. 32. Challenge – Security – Example: Permissions – Grants  Permissions are not only for users but also for services
  33. 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. 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. 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. 36. Versioning
  37. 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. 38. Examples
  39. 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. 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. 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. 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. 43. Logging
  44. 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. 45. Examples
  46. 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. 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. 48. Challenge – Logging – Correlation and Visitor Id
  49. 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. 50. What comes next?
  51. 51. I could continue for a while…
  52. 52. The question is still…
  53. 53. Questions?
  54. 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

×