Presentation: The Microservices and DevOps Journey



1:40pm - 2:30pm

Day of week:

Key Takeaways

  • Learn practical advice adopting and moving to a Microservices architecture.
  • Hear about the full stack considerations that may affect your move to Microservices.
  • Understand the importance of devops in move to Microservices.


Switching from a monolithic to a microservices architecture is no easy task. At Wix, it was a 5 year journey, but we now have over 200 microservices successfully running on a battle-tested production environment.

I will share what we learned as we worked toward this milestone—how microservices and DevOps go hand in hand, and what it takes to operate and build a successful microservices architecture from development to production.


QCon: What is your main role today?
Aviran: I am head of engineering for Wix. I’ve written blogs since the early 2000’s, so I am knowledgeable blogger. I consult many different companies about DevOps and scale. I am the one who leads the Wix engineering culture which is developer and DevOps centric.
QCon: What does your day look like?
Aviran: A lot of overall architecture reviews. I am managing many people. Since we work similar to Spotify, we have a guild. There is a lot of the culture and training people involved, and operating the guild and sharing knowledge across the companies. I’m involved in solving our scale issues, especially engineering scale, because I think we are alright regarding our infrastructure scale. We know how to do that. We are now trying to figure out how to scale engineering better and grow the company.
QCon: Can you describe the guild at Wix?
Aviran: We have an organizational structure that is divided between companies. We call them companies - mini startups, between 4 and 100 people - and they work on a specific product such as the HTML website builder, ecommerce, hotel solutions, calendar management, and others. We created these mini startups with their own resources, front and back end, support, QA, products, etc. In order to keep all the companies aligned, using the same methodologies, avoiding silos and sharing knowledge, we have these professional guilds. An example would be the back-end guild including all the back-end engineers.
All the front-end developers belong to the front-end guild. People work on their respective products, but one day a week all the guilds come together talking about their work. They share knowledge, discuss issues relevant to all the different companies and enhance our products. Some discuss the user interface for all of the products, back-end talks on the infrastructure, enhancing our framework, enhancing our logging system, our deployment system. There are retrospectives and other fun stuff.
QCon: What does scale mean at Wix?
Aviran: Wix has around 80 million website builders that are using our platform. This means we serve millions of websites. We have a complete solution. We host everything at our end, so we have over 2 petabytes of images that are part of the websites. We handle about 2 billion requests a day just to serve those sites. We serve about 100 million websites a week.
In terms of traffic and performance, we are really keen about speed. When we receive a request, we send the initial HTML response in about 20 to 30 milliseconds with no caching.
We can relax our performance requirements when someone is in editing mode, but we are not willing to pay the price of even 10 extra milliseconds for the viewers.
QCon: What is the motivation for the talk?
Aviran: The motivation for the talk is to share from my experience with other companies that want to do Microservices. First, it’s not that difficult (as long as you do it right). My talk is how to get there. It’s not that scary because a lot of things that you hear about such as service discovery and distributed logging tracing, are not really needed when you start.
My recommendation when starting to break up a monolith is to move from one monolith to two monoliths. So start with two, learning along the way how to do it, and it is not that difficult as long as you have the right culture. That culture has to really embrace DevOps, because it can not be done without a DevOps culture.
QCon: What are some of the tips to someone that complains that their business logic is so coupled that he/she is afraid it might break when attempting to change anything?
Aviran: First of all, if you don’t have a problem, then don’t do it.
The only reason why we chose microservices was to scale engineering. Once you have a monolith and you have a lot of groups working on the same code (or the same artifact), everybody steps on each other toes. Progress is really slow. Microservices is something that a team can handle. The size of a microservice is directly related to the size of the team. It can be large, or it can be small.
There can be mini-monoliths or microservices which serve just one function. There is really no good answer here. If things need to stay together, they should stay together. There is no real reason to break them apart. If a team cannot progress in producing code fast enough, then maybe you should think about how do you actually split the teams. If they are each working on a different subset of the system, that is what defines the boundaries of a microservice. If teams can work independently, that is a good starting point, because they can create various microservices which talk with each other. They just have to have well defined interfaces.
When we start a new project, we always start from a monolith. That monolith at some point is broken into microservices. Since we write a monolith that is well organized in modules, moving to microservices is very easy. You just wrap it in a WAR and you have the microservices (But that process can only be achieved after you master and understand microservices for a while, we as engineers are always tempted to cross the module boundaries, so you need a lot of discipline and experience to not do it).
QCon: What do you feel are the key takeaways that someone is going to walk away with from your talk?
Aviran: DevOps is really important. The culture of ownership with DevOps is really important. Another important thing is understanding tradeoffs. What do you gain versus what you lose when going to this architecture? Keep it simple and try to have a relatively small set of middleware to simplify the life of operations, and most importantly is do what is right for your organization don’t try to copy what works for other companies but be inspired by them.


Covering innovative topics

Monday, 7 March

Tuesday, 8 March

Wednesday, 9 March

Conference for Professional Software Developers