Daniel's full question: My name is Daniel Bryant. I am one of the InfoQ editors and I am here at QCon London with Aviran. You are the head of back-end engineering at WIX. Aviran, could you explain a little bit about what that role entails?
Head of engineering at WIX is a very complex role. Our company structure is divided into mini start-ups. We call them companies. Every company has a business unit and a vertical that they are building, and for each company, they have engineers, they have product managers, they have front and back-end developers and every developer belongs to a profession a guild. So a head of back-end engineering and now I am head of engineering basically ensures the professionalism of the people is met: recruiting the right people, maintaining the engineering culture of the company, training engineers, doing reviews and basically making sure that each and every one of the mini companies that WIX has can perform at the highest level.
2. [...] Maintaining ability to be hands on - How do you find it, Aviran? Do you find time for coding?
Daniel's full question: Very nice. We talked just briefly before coming into the room about maintaining ability to be hands on. I think a lot of us struggle with that as we move on to architects, head of various departments and head of engineering. How do you find it, Aviran? Do you find time for coding?
Actually, no. I cannot find time for coding. It depends on how many people you have to manage. If you manage 100 people then you have to make a conscious decision and say “I do have time for code. I need to make a career change and be a technical leader, a technical manager”. So I do a lot of architecture, I do a lot mentoring and coaching, but unfortunately I have no time for coding.
At the beginning I missed it a lot. As I go on I tend to miss it less. I mean I get a lot of satisfaction from doing other things.
Daniel's full question: That makes a lot of sense. So, your talk is entitled “Microservices and DevOps Journey”. How should people approach this if they are looking into microservices? What do you think is most important - organizational things or technical things?
Well, going to microservices just because some company tells you that microservices are the new hype is wrong. Microservices is something that comes to solve the problem. For WIX, it came to solve our scalability problem and velocity issues. So when you are working on a monolith a lot of people are just stepping on each other’s toes and you progress very slowly. The fact that we are going to microservices allows us to scale the engineering part of our company and by doing that, we progress a lot faster in many, many areas. So basically, if you do not have a problem, do not go to microservices.
Daniel's full question: I think that is very interesting. I think now, we are hearing a lot more companies say that. But it is something I have talked to you about before. You said almost “Do not cargo cult. Do not just copy companies for the sake of it”. Any advice for people on when they see something interesting in the conference and they are excited and they want to take it back home? What do you recommend them to do?
If you see something exciting at a conference and you think “This is the new cool thing” stop for a minute and think how that would fit into my company? How would that fit into my culture? Do not just copy and use and I mean all the tools – and you see a lot of cool new tools and open sources – just because they are out there. See how they fit into your culture, into your company and make the adjustments. Consider whether you really, really need it, or if it just the new cool thing and it will eventually fail or it will just cost a lot more than just not doing it.
6. [...] Have you got any tips on how to incentivize, sort of creating a DevOps friendly culture?
Daniel: Something I picked up on there. You mentioned about the “DevOps culture” and I think that is something very tricky to create and drive. Have you got any tips on how to incentivize, sort of creating a DevOps friendly culture?
Creating a culture is very difficult, but from the things that I have seen at WIX is that you can actually start small. You start with a small team that is doing something evolutionary or revolutionary, depending on what company you are at. People will watch you and see that it works and they will try to copy you or be part of this great, new, shiny thing because they see the value. Microservices were actually the first post-DevOps architecture, and when you are building a large scale systems, your poor Ops guys cannot handle hundreds and hundreds of services. So even as a business perspective, you cannot scale the company when you are doing microservices, unless you do DevOps culture.
Daniel's full question: Yes. That is some really good advice there. There is something we talked about before in relation to that. Say a new start-up has got a business idea – should they go to microservices straight away? Should they try to drive that culture straight away? Or do you think a monolith is something more appropriate?
A start-up company is a DevOps culture, because when you have a start-up, you have like two or three developers, they are doing everything, they are collaborating, they sit together – so they are basically doing DevOps. Going to microservices at this point? I think they should do whatever is best for them to progress fast. I actually think that starting with a monolith is a better and faster approach in order to get fast to the market, because you do not have to worry about distributed interaction and circuit breakers and all the other things entailed into the microservices architecture. But it is very important to keep the DevOps culture, because if a start-up succeeds – and let’s hope it does – then it is much easier to change the architecture and to evolve the architecture into microservices because you already have the culture to support that.
Daniel's full question: Very interesting. One thing looking at the talk notes here is that you mentioned a lot about modularization in terms of architecture. So if you do have a monolith, you can easily break it up into microservices. As the head of engineering, have you got any tips on how we might communicate that to fellow developers? How to modularize things?
It is very, very difficult. I mean you would have to have very senior or very knowledgeable engineers in order to do it right. I think that is what microservices is actually solving because it actually forces engineers to modularize their architecture. When you are doing anything in a monolith and if people did not really do microservices before, it is really, really difficult and it is really, really tempting to go and break that model. I mean we are doing it at WIX for new developments and new products - we are actually starting with a mini-monolith, but since we already have that engrained in us and we have the experience, we know exactly not to break those modules and make that really easy to break into microservices. But this is an evolution, after six years of doing microservices. When we started, we had no chance to do it right.
I would not recommend anything. I mean you should do, try, test whatever works for you. I mean there is no one tool. DevOps is not about the tooling. I mean we develop most of our tools our own because we started early and there were not any tools, but tools are just a means to an end. If you have the right culture, the tools do not matter.
10. [...] Freedom and responsibility - Is that important in the WIX culture?
Daniel's full question: Very nice. Something I picked up on the keynote this morning at QCon London was this notion that Netflix embrace freedom and responsibility. And for me the really interesting thing there is the responsibility. So developers and engineers are free to chose what they want, but they have to live with the consequences. Is that important in the WIX culture?
Yes and no. You have a lot of freedom and responsibility, but it is not a total freedom. I mean when you are working with microservices, it is very important to keep things very, very simple and with a lot of often organizational knowledge because you have a lot of DevOps overhead. If anyone would do whatever they want and pick whatever technology they want, then it will be really hard to scale the company. If one team is doing Cassandra and one is using MongoDB and the other is using React, they cannot collaborate between themselves. They cannot share knowledge because everyone is doing their own and a lot less people can help in case of a down time. By limiting the stack to a small set of acceptable technologies, you get a lot scalability. People can move between teams and they can actually be a lot more pro-active and productive. Having said that, the freedom and responsibility comes when you want to do an innovation. When you say “My standard tool set is not good enough for whatever I am doing” you can justify that and then you can go and explore a new technology. But then you take full responsibility for it. No one from the company will help you until the second or third team will use your experience, will learn from you and will implement that on their own products. When you have three teams doing that, only then that becomes a standard where everybody can freely use that as another tool in the stack.
12. [...] Distributed computing - Could you offer any more thoughts on that, Aviran?
Daniel's full question: Very interesting. So in your talk, you also mention something about distributed computing. It kind of seemed a bit scary up front. You mentioned service discovery, distributed log tracing, but it is not necessarily so scary when you begin the implementation of a microservices system. Could you offer any more thoughts on that, Aviran?
So when you go to conferences like QCon, you hear the Netflix of the world, you hear about the Twitter of the world, you hear about the WIXes of the world, companies that have made a journey and are running a large-scale microservices architecture. The reason why you have all those discovery tools and all those nice open source projects is because those companies encounter a problem, and they had to solve that problem by building a tool, but when you start with a microservices, when you start just a couple of microservices or two, three, you do not need all those tools. They create a DevOps overhead. They imply complexity in the system, and when you do not have the knowledge and you do not have the experience in operating a large scale microservices operations, you do not really need to add more complexity by adding those tools and learn how to operate them. So keep it very simple. We, at WIX, we have like over 200 microservices and we still do not have a service discovery because we do not need it. Use a DNS and a load balancer and it works fine. Configuration file as an XML on your service is a perfectly valid option. You do not need Eureka or Consul or whatever. It just works and it does not create another overhead, a DevOps overhead or a learning curve for engineers to learn yet another tool or configuration management tool or whatever.
Daniel: That totally makes sense. A lot of companies mention that there is often the challenge of learning more, more tooling before even solving the problem, which is I hear very strong from you is basically “Always solve the problem”.
Yes. Always solve a problem. Microservices come to solve a problem. They actually come to solve a scaling and an engineering scaling problem and if you want to progress fast, that is the problem that it came to solve. It is not an architecture that comes to solve all the problems in the world and it should not be employed to every single system just because it is there.
Daniel's full question: It totally makes sense. A final question: Aviran, you mentioned about learning from other organizations and I know I have chatted with you about this before. How do you recommend people learn from the likes of Neflix, the likes of Google and ultimately, the likes of WIX for sure? I know you are sharing lot of things at conferences. Can developers reach out to you via e-mail, Twitter or what is the best way to learn?
Most of the companies that are speaking at the conference, and WIX is a part of them, are very open about the things they do. We are sharing knowledge via blogs that every company has. And yes, you can reach out by Twitter, you can reach out by e-mail. I know that for myself and for WIX, we do a lot of consulting. A lot of companies are coming and visiting us and we show teach the whole industry. Those companies that are reaching out and speaking at conferences are changing the industry and not just in conferences. You can probably reach out to any of those companies and some way they will be happy to sit down with you individually and show you, and teach you and consult.
Daniel: Perfect. Thank you for your time today, Aviran. I really appreciate it.
No problem.