6. 2006 2007 2008 2009 2010 2011 2012 2013 2014
Wix is founded
First funding
Open beta
1 M users
eCommerce
10 M users
IPO
50 M users
Mobile
App Market
Hive
Wix Worldwide
HTML 5
19. Development Velocity - 2010
• Large and entangled codebase
• Hard feature rollout
• While at the same time, the iPad was
released
• We needed to enable Wix to move fast
23. Why CI / CD / TDD / DevOps?
• Fear of change
• Low quality
• Slow product development
• 3 months from dev to GA
I want
change
I want
stability
24. CI / CD / TDD / DevOps
• Small and fast changes
• Empower the developer
• Automate!!!
• Measure!!!
• = x xRisk
Number
of
changes
Size of
change
$$$
impact of
change
28. Micro-Services
• Over 100 micro-services at Wix
• A Micro Service is
– Independent deployment
– Independent OS process
– Independent database
• Size of a service – based on the team
29. Micro-Services
• The good news:
– Great risk mitigation
– Enforces separation of concerns
– Minimal blockers for deployment
• The bad news:
– More network hops - Increases % of failures
– Requires Back / Forward compatibility
– Distributed operations / transactions
30. Scala
• Moves Java developers out of their
comfort zone.
• Forced them to grow
• Question how things are done
• End result – great innovation
31. Companies & Guilds
• Companies focus on products
• Guilds focus on technology
How
What
Company leader
Guild master
Angular
React
Server
QA
Analysis
UX
32. Angular & React
• Modern & Productive
• Angular
– Applications – like my account
• React
– Websites – Wix sites are React
– React Templates for applications – Wix editor
33. Node.js
• Frontend server
• Complement Scala
– Not replace
• Let frontend devs take ownership of the
full HTTP stack
– HTML, Ajax, Sockets, etc.
Built for fast development
Did not know what are business is
We know we will need to replace it
Did not know how hard that will be
Sites should never ever have a downtime!
Sites should work as fast as possible, always!
However, an editing system does not require this level of SLA
Releases of Editing feature should have no impact on existing site operations!
Solution - The two concerns evolve independently
The Public segment targets serving websites
Has mostly read-only usage pattern
Simple publishing system
Simple + readonly -> simpler to have higher SLA and DRP
MySQL used as NoSQL – single large table with XML text fields
The Editor segment
Exposes the Editing APIs, user account and galleries management.
Has different release schedule compared to the Public segment
Use one non-normalized table, primary key access, json fields
Immutable blobs, blog table with pointers
No transactions
No MySQL auto generated keys
GUID for keys – no locks, enable master master replication
Amsterdam for 3 way active active -> failed
Doing 2 way active active + service disruption on third
The “upload to app server, post process files, copy to lighttpd server, serve by lighttpd” pattern proved inefficient, slow and error prone
ls does not scale
Needed control over http headers for caching
Train the people you already have
Hiring the right people is key to success
Hire only the best developers (only seniors)
Don’t count only on the interview, you need to test actual coding
Hire people who will challenge you (no “yes man”)
Get people you can trust with “root” access to production
Never stop hiring
