Microservice Architecture at ASOS - DevSum 2017
3 likes1,124 views
The document outlines the microservice architecture implemented at ASOS, emphasizing aspects often overlooked, such as observability and design patterns. It discusses the benefits of microservices, including agility and reduced complexity, while also addressing the challenges like increased latency and the necessity of a new operational mindset. Recommendations are provided for transitioning to microservices, focusing on organizational structure, observability planning, and strategic breaking down of monolithic systems.
Microservice Architecture at ASOS - DevSum 2017
- 1. Microservice Architecture at ASOS Ali Kheyrollahi, ASOS @aliostad aliostad@gmail.com #devsum17
- 2. @aliostad : @aliostad email: the same @gmail http://byterot.blogspot.com Ali Kheyrollahi, Solutions Architect at ASOS
- 3. @aliostad /// mini-agenda > Microservice: aspects you do not hear enough about > Observability > Patterns for building microservices > ASOS Recommendations as an example of Microservices > ASOS: Company and the tech
- 4. @aliostad > stackoverflow > £1.5 bln global fashion destination > 35% year-on-year
- 5. @aliostad
- 6. /// ASOS in numbers 2 0 1 6 T u r n O v e r → £1.5 bln A c t i v e C u s t o m e r s → 12 M E m p l o y e e s → 2500 U n i q u e V i s i t s / m o → 123 M P a g e V i e w s / d a y → 95 M V i r t u a l S t o r e s → 9 A z u r e D C s → 5
- 7. @aliostad Nick Beighton - CEO from “IT Cascade” slides - Oct 2014 © 2017 ||| ASOS Plc
- 8. @aliostad /// stock price: 2009-2013 More than 2000% growth!
- 9. @aliostad /// stock price: 2009-2014 - Multiple IT project failures - Tech issues disrupting promotions - Overdue features were not delivered
- 11. @aliostad© 2017 ||| ASOS Plc
- 13. @aliostad Indicative Team Numbers 6 Digital Domains 19 Platforms 35 Dev / Scrum teams 24 Solution Architects 700+ people in Technology (2500 in Asos total) Avg +20 people per month over last year /// operating model © 2017 ||| ASOS Plc
- 14. @aliostad /// asos tech stack
- 15. @aliostad ASOS ❤
- 17. @aliostad /// microservices Actor-basedAPI-based Adrian Cockcroft (Netflix) Fred George
- 18. @aliostad /// why microservices > Scaling people not the solution > Decentralising decision centres => Agility > Frequent deployment => Agility > Reduced complexity of each ms (Divide/Conquere) => Agility > Cost of mistakes and bad decisions smaller ... > Overall complexity is smaller
- 19. @aliostad /// microservices vs soa SOA Microservices Main Goal Architectual Decoupling Business Agility Set out to solve Architectural Coupling Scaling People, Frequent Deployment Audience Mainly Architecture Business (Everyone) Law Conway’s Reverse Conway’s Impact on Structure of Organisation Minimal Huge Service Cardinality Usually up to a dozen >40 (Commonly >100) When to do Always teams > ~5** ** Debateable. There are articles and discussions on this very topic
- 20. @aliostad /// microservice challenges > Very difficult to build a complete mental picture of solution > When things go wrong, need to know where before why > Potentially increased latency > Performance outliers intractable to solve > A complete mind-shift requiring a new operating model
- 21. @aliostad /// probability distribution Response Time Probabilty
- 22. @aliostad /// performance outliers Microservice A Microservie B 99th Percentile = 500ms 99th Percentile = 500ms A B Total <1s 99% 99% 98.01% >500m 1% 99% 0.99% >500m 99% 1% 0.99% >1s 1% 1% 0.01%
- 23. @aliostad /// probability dist Service A Prob. 10 ms 33% 15 ms 33% 25 ms 33% Service B Prob. 15 ms 33% 20 ms 33% 30 ms 33% A + B Prob. 10 + 15 11% 10 + 20 11% 10 + 30 11% 15 + 15 11% 15 + 20 11% 15 + 30 11% 25 + 15 11% 25 + 20 11% 25 + 30 11% X = 66th=15ms 66th=20ms 44th=35ms 66th=40ms
- 24. @aliostad /// where do you start?
- 25. @aliostad /// some guidelines 1 2 3 4 Break-up your business to domains and subdomains Plan for your system’s observability Define a set of key constraints on microservices Start building by chiselling or strangling parts of monolith
- 26. @aliostad /// some guidelines 1 2 3 4 Break-up your business to domains and subdomains Plan for your system’s observability Define a set of key constraints between microservices Start building by chiselling or strangling parts of monolith
- 27. @aliostad Tracing Logging Credit: Peter Bourgon Events Aggregations Request Scope Telemetry Alerting /// observability
- 28. @aliostad Logging Telemetry Tracing Alerting Log4Net ✓ Time-series DBs ✓ ✓ ✓ Zipkin ✓ ✓ ✓ ✓ Prometheus ✓ ✓ ✓ Elasticsearch ✓ ✓ ✓ ✓ New Relic* ✓ ✓ ✓ Circonus* ✓ ✓ ✓ * paid services /// comparison
- 29. @aliostad /// our stack Performance Counters ConveyorBelt Azure WAD logs ETW Logs Elasticsearch Instrumentation Logs IIS Logs Woodpecker Outputs (Pull Logs) Sources Config Up to 2TB/day
- 30. @aliostad 3x client 2x kibana 20x data (hot) traffic traffic 10x data (warm) /// our setup 3x master ARM Template Desire State Configuration
- 31. @aliostad /// some guidelines 1 2 3 4 Break-up your business to domains and subdomains Plan for your system’s observability Define a set of key constraints between microservices Start building by chiselling or strangling parts of monolith
- 32. @aliostad /// some of asos constraints a b c d All commands across MS are synchronous REST calls Microservices do send ansychronous events OpenId connect for Identity and Azure AD for x-MS calls All REST calls send a set of standard headers such as correlation-id, client version, etc
- 33. @aliostad /// types of microservices Microservice Data Store Functional API Microservice Compositional (sometimes BEFFE, also Gateway) APIservice service
- 34. @aliostad /// exposing data > All data needs to be exposed only via API > For data-intensive operations or when the origin of the request is a system favour data integration > On exceptional performance-related cases, giving read- only access to a secondary data source (e.g. soft store) is OK > For analytics purpose, all data shared via Data Lake
- 35. @aliostad /// some guidelines 1 2 3 4 Break-up your business to domains and subdomains Plan for your system’s observability Define a set of key constraints between microservices Start building by chiselling or strangling parts of monolith
- 37. @aliostad /// strangler pattern E D C A B https://www.martinfowler.com/bliki/StranglerApplication.html Martin Fowler D’
- 39. @aliostad /// recommendations Business Influence Machine Learning Algorithms: MF, FM, etc Business rules: Filtering and boosting
- 40. @aliostad /// lambda architecture Serving Layer Realtime Batch Batch What customer likes? (taste) Realtime What customer wants? (session and context) Serving Layer Merge two models Influence Context MVT, model selection Enrichment Filtering, faceting, boosting Pagination Caching
- 41. @aliostad /// Wrap-up > If you have more than 4 teams, consider Microservices > Response outliers the most intractable problems in Microservices > “Nevermind the Microservices” if you don’t have observability > Define a set of key constraints in/between your microservices > Chisel and strangulate the monolith
- 42. @aliostad >>> Thank You! special thanks to Dave Green Q U E S T I O N S
- 43. @aliostad : @aliostad email: the same @gmail http://byterot.blogspot.com Ali Kheyrollahi, Solutions Architect at ASOS
- 44. @aliostad Thomas Wood: Daisy Picture Thomas Au: Thermometer Picture Torbakhopper: Cables Picture Dam Picture - Japan Hsiung: Lights Picture Health Endpoint in API Design