The AUTO1 story started in 2012. In these six years company grew a lot. From one website written in PHP it evolved into a huge and complex system consisting of large number of components. This article describes the evolution of AUTO1’s architecture from a monolithic approach to Microservices.
The brand independent automotive company owns business units like auto1.com, wirkaufendeinauto.de and autohero.com.
At the beginning we build several classic monolith applications that served different parts of business.
The more we grew the more harder it became to support this applications. They did their job well but suffered from classic problems of monolith architecture.
Our biggest pains were:
They became too big and too complex, so that adding new features and even fixing tiny bug was difficult and time consuming. Additionally applications were using same database and had lots of shared code existing in separate repo.
We decided to migrate to microservices step by step in several iterations.
In the first phase we defined services corresponding to business capabilities. Then, piece by piece, we extracted functionality to separate services.
These services mostly used the same database as the existing applications and served as a business logic layer for them. So for example when user visited auto1.com/my-orders, he still did request to the monolith application. The application, in turn, performed a request to the needed microservices to get all the necessary information in order to respond properly
Apart from that, for all new functionality we started building microservices with own database and own infrastructure. These new services also were integrated into the monolith in the same manner.
Now every team has list of services it is responsible for. Each microservice has it’s own repository (some with an own database) and are responsible only for some specific part of the business.
Services communicate with each other, there is not need to copy/paste code anymore, each service is the source of truth for its own responsibility.
Additionally we introduced a separate deployment pipeline for each service. This allows us to work and release separately from other teams and reduces the amount of dependencies.
The first phase was a great beginning of our journey to the world of microservices. We got amazing results and most of our problems were solved:
Unfortunately there is no silver bullet. The microservice approach approach has its drawbacks and we faced some of them.
To resolve last of this problems we introduced the SPA approach. We started using React. It allowed us to call microservices directly from the frontend with proxying requests through our monolith applications. To be able to do so, we introduced simple proxy layers just for communicating with services. More about this approach you can read in our blog article.
As a result our architecture took it’s next look:
For the last six years we passed a long way from old fashioned php websites to huge distributed net of microservices. Here are some numbers at the end of 2018:
Microservices brought us lots of advantages, but along with advantages new challenges had come.
Building single-page applications