Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Mircoservices and DevOps journey at Wix.com

3 583 vues

Publié le

Wix.com started the journey on DevOps and Microservices about fife years ago and switched from a monolithic application to a microservices-based application. It took full two years to complete the transition from monolith to microservices. Having a great success in this process today Wix operates over hundred microservices on production leveraging multi-cloud platforms and have many lessons learned making this journey. We will talk about why Continuous Delivery and DevOps are important requirements for microservices and what are the guidelines for a good microservice architecture, why YAGNI and KISS are important and some recommendations on the best way to go from a monolith to microservices architecture.

Publié dans : Logiciels
  • Soyez le premier à commenter

Mircoservices and DevOps journey at Wix.com

  1. 1. Aviran Mordo Head of Microservices and the DevOps Journey at Wix.com www.linkedin.com/in/aviran @aviranm http://www.aviransplace.com
  2. 2. Wix In Numbers ~95M users Static storage is >2Pb of data 3 data centers + 2 clouds (Google, Amazon) 2B HTTP requests/day 4 R&D centers (Tel-Aviv, Vilnius, Dnipro, Kiev) NEW
  3. 3. Over 250 Microservices on Production
  4. 4. Microservices - What Does it Take
  5. 5. Why Microservices Scale engineering Development Velocity Scale system
  6. 6. Microservices is the First Post DevOps Architecture
  7. 7. How to Get There? (Wix’s journey) http://gpstrackit.com/wp-content/uploads/2013/11/VanishingPointwRoadSigns.jpg
  8. 8. http://p1.pichost.me/i/11/1339236.jpg About 6 years ago
  9. 9. The Monolithic Giant One monolithic server that handled everything Dependency between features Changes in unrelated areas caused deployment of the whole system Failure in unrelated areas will cause system wide downtime Lighttpd (file serving) MySQL DB Wix (Tomcat)
  10. 10. Breaking the System Apart https://upload.wikimedia.org/wikipedia/commons/6/67/Broken_glass.jpg
  11. 11. Concerns and SLA Many feature request Lower performance requirement Lower availability requirement Write intensive Edit websites Not many product changes High performance High availability Read intensive View sites, created by Wix editor
  12. 12. Mono-Wix Phase 1
  13. 13. Extract Public Service Editor service (Mono-Wix) Public service
  14. 14. Divide and Conquer Editor service Public service Guideline: No runtime, deployment or data dependency
  15. 15. Separation by Product Lifecycle Decouple architecture => Decouple teams Deployment independence Areas with frequent changes Editor service Public service
  16. 16. Separation by Service Level Scale independently Use different data store Optimize data per use case (Read vs Write) Run on different datacenters / clouds / zones System resiliency (degradation of service vs. downtime) Faster recovery time Editor service Public service
  17. 17. http://blogs.adobe.com/captivate/2011/03/training-adding-interactivity-to-elearning-courses-with-adobe-captivate-5.html/time-to-learn-clock
  18. 18. Service Boundary
  19. 19. Separation of Databases Copy data between segments Optimize data per use case (read vs. write intensive) Different data stores Public serviceEditor service Copy necessary data
  20. 20. Serialization
  21. 21. Serialization / Protocol Binary? JSON / XML / Text? HTTP? Public serviceEditor service
  22. 22. Serialization / Protocol - Tradeoffs Readability? Performance? Debug? Tools? Monitoring? Dependency? Public serviceEditor service
  23. 23. API Transport/Protocol
  24. 24. How to Expose an API REST? RPC? SOAP? Public serviceEditor service
  25. 25. Wix’s Choices REST HTTP Public serviceEditor service Binary JSON-RPC HTTP
  26. 26. API Versioning
  27. 27. API Versioning Public serviceEditor service Backward compatibility Maybe here API Schema /v1/v2
  28. 28. A-Synchronous
  29. 29. Which Queuing System to Use Public serviceEditor service Threads Kafka? RabbitMQ? ActiveMQ? ???
  30. 30. Service Discovery
  31. 31. Service Discovery Public serviceEditor service Configuration (DNS+LB) Zookeeper? Consul? Etcd? Eureka?
  32. 32. Resilience
  33. 33. What does the Arrow Mean? Public serviceEditor service
  34. 34. Failure Points = Network I/O Public serviceEditor service Retry policy Circuit breaker Throttlers Be careful – you may cause downtime Retry only on idempotent operations
  35. 35. Degradation of Service Public serviceEditor service Feature killer (Killer feature) Fallbacks Self healing
  36. 36. Testing
  37. 37. Test a Distributed System (at Wix) Public serviceEditor service Unit Test Integration Test Server E2E Automation Client
  38. 38. Distributed Logging
  39. 39. Build Visibility Into the Service
  40. 40. Ownership
  41. 41. Team Work Microservice is owned by a team You build it – you run it No microservice is left without a clear owner Microservice is NOT a library – it is a live production system
  42. 42. What is the Right Size of a Microservice?
  43. 43. The Size of a Microservice is the Size of the Team that is Building it “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Conway, Melvin
  44. 44. What did you Learn from Just 2 Services ● Service boundary ● Monitoring infrastructure ● Serialization format ● Synchronous communication protocol (HTTP/Binary) ● Asynchronous (queuing infra) ● Service SLA ● API definition (REST/ RPC / Versioning) ● Data separation ● Deployment strategy ● Testing infrastructure (integration test, e2e test) ● Compatibility (backwards / forward)
  45. 45. Continue to Extract More Microservices
  46. 46. HTML Editor Flash Editor MSM Private Media Public Media Editor Segment Public Segment Premium Services List DB App Builder App Store App Market Dashboard Mailer TimeZone Public HTML API Public API (Flash) MSP Public Server HTML Renderer HTML SEO Renderer Flash Renderer Flash SEO Renderer Sitemap Renderer Robots.txt Renderer User Server Template Viewer ContactsHUBActivity Site Members Store Mgr Comments Snapshoter User Pref Feed Me Shout-out Hotels PETRI Site Pref Dist LoggerSlicer eCom Renderer eCom Cart eCom Checkout eCom Catalog eCom Orders Payment Facade Account Info HTML API HTML Embeder BlogMobile Mostly writes 2 Data centers Db active-standby (preferably active-active) Performance < 2s 99% Serves mostly site builders Uptime > 99.9 Mostly reads >2 Data centers Db active-active(-active) Performance < 500ms 99% Serves mostly site viewers Uptime > 99.99
  47. 47. When to Extract a New Microservice
  48. 48. Microservice or Library? Do I create deployment dependency? What is DevOps overhead (managing middleware) ? Who owns it? Does it have its own development lifecycle? Does it fit the scalability / availability concerns? Can a different team develop it? I need time zone from an IP address
  49. 49. Microservice has Ops, Library is Only Computational
  50. 50. Which Technology Stack to Use
  51. 51. Free to Chose? Microservices give the freedom to use different technology stacks Enables innovation
  52. 52. Default to the Stack You Know how to Operate
  53. 53. Innovate on Non Critical Microservices and Take Full Responsibility for its Operation
  54. 54. Polyglotic System?
  55. 55. Limit your Stack Code reuse Cross cutting concerns (session, security, auditing, testing, logging…) Faster system evolution Development velocity
  56. 56. http://wallpaperbeta.com/dogs_kiss_noses_animals_hd-wallpaper-242054/ Reduce the Cost of a New Microservice
  57. 57. What else will you learn ● Distributed transactions ● System monitoring ● Distributed traces ● Tradeoff of a new microservice vs. extending an existing one ● Deployment strategy and dependency ● Handling cascading failures ● Team building/splitting
  58. 58. Summary
  59. 59. Every Microservice is a Overhead
  60. 60. It is all about trade-off
  61. 61. Microservices Tradeoffs Monolith Microservices
  62. 62. Thank You
  63. 63. Q&A @aviranm http://www.aviransplace.com www.linkedin.com/in/aviran Aviran Mordo Head of Engineering http://goo.gl/32xOTt http://engineering.wix.com @WixEng We’re hiring www.wix.com/jobs Kiev