Microservices and DevOps Journey at Wix.com Aviran Mordo www.linkedin.com/in/aviran Head of @aviranm http://www.aviransplace.com @aviranm
@aviranm
@aviranm
Wix In Numbers Over 86M users Static storage is >2Pb of data 3 data centers + 2 clouds (Google, Amazon) 2B HTTP requests/day 1200 people work at Wix @aviranm
Over 200 Microservices on Production @aviranm
Microservices - What Does it Take Do / Use Consider / Understand Continuous Delivery SLA DevOps Distributed Transactions Circuit Breaker Backward / Forward Compatibility Feature Flags Clustering Throttlers Conway’s law Monitoring Development / product lifecycle Testing Boundary Message Bus KISS RPC YANGI REST LEAN @aviranm
Microservices - What Does it Take @aviranm
How to Get There? (Wix’s journey) http://gpstrackit.com/wp-content/uploads/2013/11/VanishingPointwRoadSigns.jpg @aviranm
About 6 years ago http://p1.pichost.me/i/11/1339236.jpg @aviranm
Initial Architecture Tomcat, Hibernate, custom web framework One database Stateful login (Tomcat session), Ehcache, file uploads No consideration for performance, scalability and testing Intended for short-term use Wix Lighttpd MySQL (Tomcat) (file serving) DB @aviranm
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 Wix Lighttpd MySQL (Tomcat) (file serving) DB @aviranm
Breaking the System Apart @aviranm https://upload.wikimedia.org/wikipedia/commons/6/67/Broken_glass.jpg
@aviranm
Concerns and SLA Edit websites View sites, created by Wix editor Many feature request Not many product changes Lower performance requirement High performance Lower availability requirement High availability Write intensive Read intensive @aviranm
Phase 1 Mono-Wix @aviranm
Extract Public Service Editor service (Mono-Wix) Public service @aviranm
Divide and Conquer Editor service Public service Guideline: No runtime, deployment or data dependency @aviranm
Why 2 Monoliths? Baby Steps Public needs stability; Editor need fast development; microservices => scalability /resilient (microservices => decoupling) Editor service Public service @aviranm
Separation by Product Lifecycle Decouple architecture => Decouple teams Deployment independence Areas with frequent changes Editor service Public service @aviranm
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 @aviranm
http://blogs.adobe.com/captivate/2011/03/training-adding-interactivity-to-elearning-courses-with-adobe-captivate-5.html/time-to-learn-clock @aviranm
Service Boundary @aviranm
Separation of Databases Copy data between segments Optimize data per use case (read vs. write intensive) Different data stores Copy necessary data Editor service Public service @aviranm
Serialization @aviranm
Serialization / Protocol Binary? JSON / XML / Text? HTTP? Editor service Public service @aviranm
Serialization / Protocol - Tradeo ff s Readability? Performance? Debug? Tools? Monitoring? Dependency? Editor service Public service @aviranm
API Transport/Protocol @aviranm
How to Expose an API REST? RPC? SOAP? Editor service Public service @aviranm
Wix’s Choices REST HTTP Binary JSON-RPC HTTP Editor service Public service @aviranm
API Versioning @aviranm
API Versioning Maybe here API Schema /v1/v2 Backward compatibility Editor service Public service @aviranm
A-Synchronous @aviranm
Which Queuing System to Use Kafka? RabbitMQ? ActiveMQ? ??? Threads Editor service Public service @aviranm
Service Discovery @aviranm
Service Discovery Zookeeper? Consul? Etcd? Eureka? Configuration (DNS+LB) Editor service Public service @aviranm
Resilience @aviranm
What does the Arrow Mean? Editor service Public service @aviranm
Failure Points = Network I/O Retry policy Retry only on idempotent operations Circuit breaker Be careful – you may cause downtime Throttlers Editor service Public service @aviranm
Degradation of Service Feature killer (Killer feature) Fallbacks Self healing Editor service Public service @aviranm
Testing @aviranm
Test a Distributed System (at Wix) Unit Test Integration Test Server E2E Automation Client Editor service Public service @aviranm
Distributed Logging @aviranm
Build visibility into service @aviranm
Ownership @aviranm
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 @aviranm
What is the Right Size of a Microservice? @aviranm
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 @aviranm
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)
Continue to Extract More Microservices @aviranm
Public Segment Editor Segment App HTML Public HTML HTML SEO MSM HTML API Renderer Renderer Store Editor Mostly reads Mostly writes App Public Flash Public Public API Flash SEO Market Media Editor (Flash) Server Renderer >2 Data centers 2 Data centers User Private Flash Sitemap Robots.txt TimeZone MSP Server Media Db active-active(-active) Renderer Renderer Db active-standby (preferably active-active) Renderer Premium Performance < 500ms 99% Site Pref User Pref Performance < 2s 99% Services Template eCom Viewer Checkout Serves mostly site viewers List DB Serves mostly site builders HTML Feed Me Dashboard Embeder eCom Cart PETRI App Uptime > 99.99 eCom Uptime > 99.9 Builder Renderer Activity HUB Contacts eCom HTML API Catalog Comments Site Mailer Store Mgr eCom Members Orders Shout-out Hotels Dist Logger Snapshoter Slicer Payment Facade Mobile Blog Account Info @aviranm
When to Extract a New Microservice @aviranm
Microservice or Library? I need time zone from an IP address 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? @aviranm
Microservice has Ops, Library is Only Computational @aviranm
Which Technology Stack to Use @aviranm
Free to Chose? Microservices gives the freedom to use a different technology stacks. Enables innovation @aviranm
Default to the Stack You Know how to Operate. @aviranm
Innovate on Non Critical Microservices and Take Full Responsibility for its Operation. @aviranm
Polyglotic System? @aviranm
Limit your Stack Code reuse Cross cutting concerns (session, security, auditing, testing, logging … ) Faster system evolution Development velocity @aviranm
@aviranm http://wallpaperbeta.com/dogs_kiss_noses_animals_hd-wallpaper-242054/
What else will you learn ● Distributed transactions ● System monitoring ● Distributed traces ● Tradeo ff of a new microservice vs. extending an existing one ● Deployment strategy and dependency ● Handling cascading failures ● Team building/splitting @aviranm
Summary @aviranm
Why Microservices Scale engineering Development Velocity Scale system @aviranm
Microservices is the First Post DevOps Architecture @aviranm
Every Microservice is a Overhead @aviranm
It is all about trade-o ff @aviranm
Microservices Guidelines & Tradeo ff s Each service has its own DB schema (if one is needed) Gain - Easy to scale microservices based on service level concerns Tradeoff – system complexity, performance Only one service should write to a specific DB table(s) Gain - Decoupling architecture – faster development Tradeoff – system complexity / performance May have additional read-only services that accesses the DB (not recommended) Gain - Performance gain Tradeoff - coupling Services are stateless Gain - Easy to scale out (just add more servers) Tradeoff - performance / consistency @aviranm
@aviranm
Thank You @aviranm
Recommend
More recommend
