In this interview, Aviran Mordo, the head of back-end engineering at Wix, talks about his likes and dislikes about microservices. Here are his answers.
JAXenter: Why did you start using microservices?
Aviran Mordo: We didn’t actually plan to start using microservices, it was a natural evolution of our system. Back in 2010, the term “microservices” was not introduced yet. The actual reason why we started using microservices was to solve an engineering scale problem where too many engineers were working on a single monolith, which caused a lot of dependencies and stability issues. Breaking the monolith into small services allowed us to break our engineering into small teams that have little dependencies between them, thus allowing a faster release cycle of our software.
Microservices also go hand in hand with the DevOps culture and continuous delivery.
Another major reason was our system’s SLA. We had different SLA requirements to different parts of our system, and breaking it into microservices allowed us to easily scale our most important services without affecting others, which would have made it much more complicated.
JAXenter: What is the most important benefit of microservices?
Aviran Mordo:The fact that microservices help decouple teams and allow us to have different SLA for different parts of our system.
The JAX London Conference is a three-day conference for cutting-edge software engineers and enterprise-level professionals. JAX brings together the world’s leading innovators in the fields of JAVA, microservices, continuous delivery and DevOps.
The Conference for Java & Software Innovation | Oct. 10-13, 2016, London
JAXenter: Have microservices helped you achieve your goals?
Aviran Mordo:Definitely, by using microservices we created many small teams where each is responsible for different parts of our system without stepping on each other’s toes. We have also defined two main SLAs where microservices architecture really comes into play and we can easily create microservices for different system SLA.
JAXenter: What do you think should be the optimal size of a microservice?
Aviran Mordo:There is no such thing an optimal size of a microservice in my opinion. The size of a microservice is the size of the team that is building it. Engineers should be pragmatic about their choices. Sometimes it makes sense to have a large microservice that is almost a monolith, and sometimes it can be as tiny as one function. Just like everything we do in a large system, it is all about the tradeoffs and what is more important to your use case.
JAXenter: What is the biggest challenge of microservices?
Aviran Mordo: The biggest challenge is the fact that you are now operating in a distributed system where you really need to understand and handle distributed transactions, cascading failures, deployment dependencies and compatibility issues. Microservices also go hand in hand with the DevOps culture and continuous delivery. Operating a large-scale microservices architecture is almost impossible without the right culture and mindset as your Ops team will not be able to handle hundreds of microservices in production.
The most important tooling for microservices is CI.
JAXenter: What technology do you think is the most important as far as microservices are concerned?
Aviran Mordo: Microservices can be done with any technology stack. I think there are tools and technologies that make things simpler such as containers, Spring Boot and more but it can be done very well without any of them. I think the most important tooling for microservices is CI and good deployment tools together with good monitoring tools.
JAXenter: How much do microservices influence an organization? Can they leave the organization unchanged?
Aviran Mordo: Microservices change the organization structure as they enable the creation of small teams that can progress very fast and independent from each other. Microservices represent the first post-DevOps architecture; old-style organizations that do not practice DevOps will probably not be able to operate large scale microservices in system.
JAXenter: When should you not use microservices?
Aviran Mordo: Like everything, microservices come to solve a problem. If your organization does not have a problem with a monolith and can progress fast enough without any scalability concerns, you should stick to the monolith; it is much easier to operate and understand.
JAXenter: What are your guiding principles in the division of an application into microservices?
Aviran Mordo: These are my principles:
- If you have different SLAs for different parts of the system, break them into different microservices.
- Each microservice has its own datLike everything, microservices come to solve a problem. If your organization does not have a problem with a monolith and can progress fast enough without any scalability concerns, you should stick to the monolith; it is much easier to operate and understand.abase scheme and only one microservice should write to it.
- Having different data access patterns (read vs write).
- By scaling your teams by splitting your system into microservices, you can have small teams handle different parts of your system.
JAXenter: Should every microservice be written in the same language or is it possible to use more languages?
Aviran Mordo: While you can use any number of languages, you really should limit yourself to as few languages as you can (preferable only one or two). There are many cross-cutting concerns that you will have and you will probably put them into shared common libraries or framework.
If I do not have DevOps culture, I would not go down this road.
Things like session validation, logging, communication protocol and scheme, monitoring, security, deployment and more. The more languages you use, the more you will have to duplicate these cross-cutting concerns to all languages, which slows down your progress.
JAXenter: What aspects should you take into consideration before using microservices?
Aviran Mordo: Before going into the microservices world I would ask myself first: what problem I am trying to solve and do microservices help me solve it? Another thing I would do is have the right culture to support this architecture. If I do not have DevOps culture, I would not go down this road.