Creating a Developer-Centric Culture and Building Platform as Runtime

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Aviran Mordo, who is the VP of Engineering of Wix. Aviran, welcome. Thanks for taking the time to talk to us today.

Aviran Mordo: Hello and good evening.

Shane Hastie: Thank you, and good morning to you. I'm a New Zealand Aviran is in Israel, so the miracles of modern technology, we are able to communicate in real time. Aviran, the place I'd like to start with our guests is who's Aviran?

Introductions [00:48]

Aviran Mordo: I'm VP of Engineering for Wix I've been at the company for 12 years. Before that, I worked at a lot of big companies like Lockheed Martin. I had my own startups. So I've been around for quite a while. I've been a very vocal advocate of the DevOps culture at Wix. We call it the developer-centric culture where we put the developers in the middle and then the organization helps developers to ship software faster, and that's our goal, to try to figure out ways of how to ship software faster.

Shane Hastie: So what does a developer-centric culture look like and feel like?

In a developer-centric culture, the whole organisation is optimised to help ship software faster [01:24]

Aviran Mordo: If we think about development lifecycle, like an assembly line for cars, for instance, the developers are the assembly line because they build the product. So the software is the product, and they know the product the best. They know it better than the QA, testing, they know it better than the product that try to define them because they actually coded the actual product. So the whole developer-centric idea is the entire organization have a support circle with specialized professions that supports developers and help developers basically shift software faster.

Shane Hastie: And for the individual developer, how do we prevent this from feeling just like, "Work harder?"

Aviran Mordo: Because it's not work harder, it's work smarter. You do more things in the same amount of time that would've taken you before this whole continuous delivery movement or finding ways to do smarter things. If we're talking about platform engineering or low code development where you codified a lot of the things ahead and you basically have to write less code and achieve much more in a lower amount of time with fewer people, which we know developers are very scarce and hard to recruit. So if you can do more, you just basically need less developers.

Shane Hastie: So one of the things you mentioned before we started recording was the concept of platform as runtime. What do you mean by that?

Platform as runtime [02:52]

Aviran Mordo: Platform as a runtime, this is a new concept that we have been internally working on at Wix. It relates to platform engineering. However, if you hear about all the talks about platform engineers and a lot of companies are talking with regard to platform engineering on the CI, Kubernetes, all those areas of the platform and Wix are basically past that thing because we built this platform many years ago and we took the platform engineering to the next level to codify basically a lot of the concerns that developers have in their day-to-day life.

But if we'll take our own areas of business, which is basically business models, we build com platforms, we build blogs, we build events platforms or booking platforms. So those are all business applications. And for all business applications, you have basically the same concepts or the same concerns that you need to do, like throw domain events, model your entities in a way that is multi-tenant, you know, GDPR concerns, GRPC communications and how all those things are working together.

So usually most companies, we build our own frameworks and libraries that the common libraries that developers just build into their microservices deployables. And that creates a problem because while we build those libraries, we also build tons of documentations that developers need to understand to use those libraries. Okay, for GDPR, you have to be expert in privacy. And how does the AB testing system works for each company have their own AB test for feature flag systems, and how do you communicate via GRP? What are the headers that you need?

So tons of documentations that developers need to learn and understand. And what we did is that we codified a lot of these concepts into our platform. So basically we looked at the amount of lines of code that developers have to write, and by analyzing them, we saw that 80% of the lines of code are basically wiring stuff and configuring things and not actually writing the business logic that you have to write, the business value, that this is what we get paid for, to bring business value to the business, not to wire things.

And that's 80% of our work is wiring stuff. So what we did is we coded it into a very robust framework or platform. We took this framework and instead of having developers to compile this loaded framework, which is basically 80% of your deployable is the framework. And we build a serverless cloud, our own serverless infrastructure, and we put the framework on the serverless cloud. And now developers, they don't need to compile this code themselves, they just build against an interface of some sort, and they deploy their deployable into the cloud where they get the framework.

Benefits from platform as runtime [05:58]

Aviran Mordo: So the platform is basically their runtime. It runs their business logic for them. What that actually also gives us is the ability to have a choke point and to update. If you think about it, Wix have about 3000 unique microservices clusters. If we think about the Log4j security vulnerability that was discovered a few months ago now, what we had to do before we have the platform as a run time is to ask all the teams in Wix to rebuild 3000 microservices to recompile with, "Okay, we update the framework, we update the dependency. Now everybody have to rebuild, recompile and redeploy everything into the cloud."

And that takes a lot of time. And of course, a lot of things get missed on the way. So by taking out the platform, the framework from the microservice itself and put it outside of the microservices as a runtime, we can control these whole common libraries that appears everywhere else in all the microservices and control it from a central place as the runtime. And that gives us a huge velocity gain. So before we build, we codified all this logic. So now developers don't need to read dozens of documents just to understand how things works. Things just works for them.

And during this process, we were able to eliminate between 60 to 80% of the lines of code that developers have to write to achieve the same goal and reduce the time for development tremendously. From weeks, it took us like two to three weeks for a new microservices that doesn't really do much. Basically a basic crowd operations because you really have to work hard to do all these wiring things into a matter of hours. So now developers in a matter of two or three hours, they can have a new microservice running on the cloud with all the legal requirements, the business requirement, the infrastructure, the ecosystem requirements that's out there.

Shane Hastie: Who are the team that maintain this platform?

Maintaining the platform [07:59]

Aviran Mordo: So we have an infrastructure team and they work just like any other product team. So we looked at our platform as a product and we have technical product that go into the different teams at the company. They sit with them, they analyze their code, they build with them code and try to extract and find commonalities between different business units. They say, "Okay, this is something that is common to a lot of developers. So it's common for Wix's business areas. And we extract those things and we will create a team of people from different parts of the company. We try to understand, "Okay, what is the commonality code?" Put that into the platform and have that as a product. We had this concept before we kind of did this mind shift. Infrastructure teams, they tend to build things that are cool that they say, "Okay, this is what developers should know and understand."

And then a lot of times the products that the infrastructure teams are building are not being used or being used in very small parts of the organizations. So what we did in our platform engineering team is we put one main KPI for our infrastructure team is you do something, you commit on adoption, you're not succeeding just by finishing this new shining infrastructure. It's just like when you develop a business product, you want customers to come and buy your product. So same for infrastructure teams. We commit on adoption. Our success is how many developers in the organization actually use this new infrastructure. And if they don't use it means that we didn't succeed in building the right product for them.

Shane Hastie: How do you prevent this from becoming a single point of failure? How do you keep quality in this platform?

Maintaining quality in the platform [09:52]

Aviran Mordo: There is always a single point of failure in every system. At Wix, we put a lot of emphasis, and especially in the infrastructure team, on quality. We are doing the best practices of test driven development and constantly monitoring things. But we also have the single point of failure is not really single because it is a distributed system. There are hundreds of servers running. So unless there is a bug, then you have to fix it. But for that, you know, got test, you got gradual rollout, you got AP testing, feature flex.

So all the best practices in the industry to prevent it. But if a service goes down, then that's just one cluster of hundreds of cluster or thousands of clusters that are coming down. But it happens rarely, but it does happen. But we look at this runtime as a critical infrastructure, just like you would look at an API gateway. Just a critical infrastructure that essentially it is a single point of failure. So we look at it just as another layer, just like a load balancer or a gateway server. This is the platform, this is the runtime, it has to be at the highest quality and the best performance that we can get.

Shane Hastie: Another thing that you spoke about before we started recording was shifting left in the design space. What are you doing there? It sounds pretty interesting.

Shifting left in design [11:13]

Aviran Mordo: We talked about how we constantly trying to try ways in improving our development velocity. So up until now we talked about the backend side. So let's talk about the frontend side. Since Wix is a website building platform, we employ in Israel the most amount of frontend developers in Israel and the largest design studio in the country. So we have a lot of experience of seeing frontend developers and designers how they actually work together.

And what we saw that they don't really work together, they work alongside each other. So in most cases, when you want to design a new web application or a website, you have the designer design in whatever design tool that they want via Photoshop or Figma or any design tool that they feel comfortable with. And then they hand over the designs to the developers and they try to copy to the best of their ability and their tools into HTML and CSS.

It's a web browser. So it's a two different tools that are not always compatible in their capabilities. And there is always this back and forth ping-pong between designers and developers. And then for every change, even during the life cycle of a product, for every change that marketing want to do or the business product want to do, they have to go back to the developers, "Hey, I need to move this button from here to there. Please change this color or we want to do a test." Or something like that. And that is kind of wasting the time and talent of developers because if I need to move something on the screens, it's something that you don't really need a developer to do. So we want developers and designers to work on the same tools. So this is where the movement of flow code comes into place.

So which is one of the players in this area. So we have our own product, it's called Editor X, where designers and developers basically can work on the same tools while designers move components around. They put it on the screen, developers go in the same IDE, it's basically a visual IDE and codify their components. So instead of having developers ... I wouldn't call it wasting their time, but investing their time in trying to move things around or doing the pixel perfect, messing around with CSS and browser compatibilities, developers and designers work together as one team.

So the design becomes just another developer with their own responsibility and developers codify the actual business logic that runs behind the component. So we created a holistic team that can actually work faster and better. And if product managers, they want to change something on the screen, they don't need to go to developers, which is basically the most expensive resource in the organization. Our developers, they can have the designers or the UX expert just play around with the design, change the design without affecting the code because you are working on the same environment.

Shane Hastie: So this is a tighter collaboration. These are often people with very different skill sets, but also perspectives. How do you bring them together into this one team? How do you create the one team culture?

Enabling one-team culture [14:50]

Aviran Mordo: So this is something that is ingrained in the way that Wix is working. Our organizational structure is basically defined as we call them companies and guilds. So companies think about it as a group of people that are responsible for business domains. So they actually build the product and they have their own 1, 2, 3, how many teams that they need to work. So in this team, you have developers, you have QA, you have product managers, you also have UX experts and designers, and they're all part of the same team.

And then you have the guilds, the professional guilds that are responsible for having the standards and the professional expertise and building the tools for each profession. So having them working on the same team, having the same business goals, it creates a holistic team that instead of throwing the work over defense, and this is tied up to all the DevOps, continuous delivery culture that instead of throwing the responsibility, "Okay, I'm done with my work now. Okay, product manager done with the work, now go developers, develop now, QA tested." And in our system they operated, we create this whole, again, it's this whole dev-centric, developer-centric culture that it's one team with experts, with subject expert, they're all working together as a team to basically help the developers basically ship the product. So designers just become an integral part of the development team.

Shane Hastie: That structure makes sense with the companies and the guilds, what you're calling the company there, I would possibly have called it a value stream. How are these companies incentivized?

Incentivizing internal companies [16:33]

Aviran Mordo: Well, they have their own business KPIs, and it's not a P& L, especially at Wix because we have companies that their product earn money. For instance, the e-commerce platform, this is a product that makes money. You have the people going and buying and stuff. But we have another company that's, for instance, the blog company. The blog is an add-on. It's a necessity for the whole Wix ecosystem because most websites need blog. But blog is a free product. So each company have their own KPI. So if the blog KPI will be adoption or a number of customers, they're not paying customers.

But we see that there is an adoption to the product. A lot of websites have installed blogs in their website while let's say the econ platform or the payments company that are responsible for receiving processing payments and stuff, they have their own KPIs. So payments is not something that you sell, but it's something that you process. So their payments KPI will be the number of transactions that we processed or how many customers decided to install, for instance, Wix payments as opposed to just use PayPal or any alternative payments, so they have their own KPIs and the ecom platform have their own KPIs, right? Number of stores or in the stores, they know the number of transactions or the GPV, each company have their own metrics.

Shane Hastie: And how do you keep those aligned with the overall organizational goals?

Aviran Mordo: That comes to our organizational structure. We specifically call them companies and not value streams because we treat them as startups within the big organizations. So each company have their own quote unquote CEO. We call them head of company and they have their own engineering manager. And basically they get funded by Wix as a whole. And while they have their own KPIs, if you think about startups, startups have board of directors that they align them with strategic goals. So each company have, we call them a chairman, which is basically the board of director.

The chairman is one of the Wix's senior management. And between the head of company and chairman, they can decide like 95 of the things they can decide together without involving all of Wix's management. So the chairman, which is serves as the board of director, aligns the company with the needs of Wix and also considers the needs of this mini-company itself within Wix. So it's just like any other startup.

Shane Hastie: Interesting structure and sounds like an interesting place to work. Thank you very much. Some great examples of tools, techniques to improve velocity, and I think there's a lot that our audience will take away from this. If people want to continue the conversation, where do they find you?

Aviran Mordo: They can find me on LinkedIn mostly. I'm also on Twitter, but mostly on LinkedIn.

Shane Hastie: Wonderful. Thank you so much.

Aviran Mordo: Thank you very much. It's been a pleasure.

Mentioned:

• Wix
• Aviran Mordo on LinkedIn