Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1SbjUWM. Aviran Mordo talks about how microservices and DevOps go hand in hand, and what it takes to operate and build a successful microservices architecture from development to production. Filmed at qconlondon.com. Aviran Mordo is the head of back-end engineering at Wix. He has over 20 years of experience in the software industry and has filled many engineering roles and leading positions, from designing and building the US national Electronic Records Archives prototype to building search engine infrastructures.

1. @aviranm
Aviran Mordo
Head of
Microservices and DevOps
Journey at Wix.com
www.linkedin.com/in/aviran
@aviranm
http://www.aviransplace.com

2. InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/wix-microservices-devops

3. Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide
Presented at QCon London
www.qconlondon.com

4. @aviranm

5. @aviranm
Wix In Numbers
Over 80M users
Static storage is >2Pb of data
3 data centers + 3 clouds (Google, Amazon, Azure)
2B HTTP requests/day
1000 people work at Wix

6. @aviranm
Over 200 Microservices on Production

7. @aviranm
Microservices - What Does it Take

8. @aviranm
How to Get There? (Wix’s journey)
http://gpstrackit.com/wp-content/uploads/2013/11/VanishingPointwRoadSigns.jpg

9. @aviranmhttp://p1.pichost.me/i/11/1339236.jpg
About 5 years ago

10. @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
Lighttpd
(file serving) MySQL
DB
Wix
(Tomcat)

11. @aviranm
Breaking the System Apart
https://upload.wikimedia.org/wikipedia/commons/6/67/Broken_glass.jpg

12. @aviranm

13. @aviranm
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

14. @aviranm
Mono-Wix
Phase 1

15. @aviranm
Extract Public Service
Editor service (Mono-Wix) Public service

16. @aviranm
Divide and Conquer
Editor service Public service
Guideline: No runtime, deployment or data dependency

17. @aviranm
Separation by Product Lifecycle
Decouple architecture => Decouple teams
Deployment independence
Areas with frequent changes
Editor service Public service

18. @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

19. @aviranm
http://blogs.adobe.com/captivate/2011/03/training-adding-interactivity-to-elearning-courses-with-adobe-captivate-5.html/time-to-learn-clock

20. @aviranm
Service Boundary

21. @aviranm
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

22. @aviranm
Serialization

23. @aviranm
Serialization / Protocol
Binary?
JSON / XML / Text?
HTTP?
Public serviceEditor service

24. @aviranm
Serialization / Protocol - Tradeoffs
Readability?
Performance?
Debug?
Tools?
Monitoring?
Dependency?
Public serviceEditor service

25. @aviranm
API Transport/Protocol

26. @aviranm
How to Expose an API
REST?
RPC?
SOAP?
Public serviceEditor service

27. @aviranm
Wix’s Choices REST
HTTP
Public serviceEditor service
Binary
JSON-RPC
HTTP

28. @aviranm
API Versioning

29. @aviranm
API Versioning
Public serviceEditor service
Backward compatibility
Maybe here
API Schema /v1/v2

30. @aviranm
A-Synchronous

31. @aviranm
Which Queuing System to Use
Public serviceEditor service
Threads
Kafka?
RabbitMQ?
ActiveMQ?
???

32. @aviranm
Service Discovery

33. @aviranm
Service Discovery
Public serviceEditor service
Configuration (DNS+LB)
Zookeeper?
Consul?
Etcd?
Eureka?

34. @aviranm
Resilience

35. @aviranm
What does the Arrow Mean?
Public serviceEditor service

36. @aviranm
Failure Points = Network I/O
Public serviceEditor service
Retry policy
Circuit breaker
Throttlers Be careful – you may cause downtime
Retry only on idempotent operations

37. @aviranm
Degradation of Service
Public serviceEditor service
Feature killer (Killer feature)
Fallbacks
Self healing

38. @aviranm
Testing

39. @aviranm
Test a Distributed System (at Wix)
Public serviceEditor service
Unit Test
Integration Test
Server E2E
Automation
Client

40. @aviranm
Distributed Logging

41. @aviranm
Build visibility into service

42. @aviranm
Ownership

43. @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

44. @aviranm
What is the Right Size of a
Microservice?

45. @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

46. 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)

47. @aviranm
Continue to Extract More Microservices

48. @aviranm
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

49. @aviranm
When to Extract a New Microservice

50. @aviranm
Microservice or Library?
Do I create deployment dependency?
What is DevOps overhead ?
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

51. @aviranm
Microservice has Ops, Library is Only
Computational

52. @aviranm
Which Technology Stack to Use

53. @aviranm
Free to Chose?
Microservices gives the freedom to use a different
technology stacks.
Enables innovation

54. @aviranm
Default to the Stack You Know how to
Operate.

55. @aviranm
Innovate on Non Critical Microservices and Take Full
Responsibility for its Operation.

56. @aviranm
Polyglotic System?

57. @aviranm
Limit your Stack
Code reuse
Cross cutting concerns (session, security, auditing, testing,
logging…)
Faster system evolution
Development velocity

58. @aviranmhttp://wallpaperbeta.com/dogs_kiss_noses_animals_hd-wallpaper-242054/

59. @aviranm
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

60. @aviranm
Summary

61. @aviranm
Microservices is the First Post DevOps
Architecture

62. @aviranm
Every Microservice is a
Overhead

63. @aviranm
It is all about trade-off

64. @aviranm
Microservices Guidelines & Tradeoffs
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
Gain - Performance gain
Tradeoff - coupling
Services are stateless
Gain - Easy to scale out (just add more servers)
Tradeoff - performance / consistency

65. @aviranm

66. @aviranm
Thank You

67. @aviranm
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

68. Watch the video with slide synchronization on
InfoQ.com!
http://www.infoq.com/presentations/wix-
microservices-devops