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.

Original AUTO1 architecture

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:

• Code duplication
• Shared database
• Git Merge nightmare
• Codebase complexity
• No ownership
• Regression testing is almost impossible
• Long process from development to deploy

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.

Breaking down monolith to microservices

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.

Usual service architecture:

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:

• Code duplication Solved
• Shared database Partially Partially Solved
• Git Merge nightmare Solved
• Codebase complexity Solved
• No ownership Solved
• Regression testing is almost impossible Solved
• Long process from development to deploy Solved

Unfortunately there is no silver bullet. The microservice approach approach has its drawbacks and we faced some of them.

• System architecture complexity increased
• Development time for complex features increased
• We still had some parts of monolith that added complexity to development

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:

Results

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:

• Over 250 microservices created
• Over 655 repositories
• Over 30 application databases
• Written on Java, PHP, Go, NodeJS
• Over 200 Engineers
• More than 20 teams (some of them are remote)
• Each team owns 5-20 services
• Average 10 releases per day

Microservices brought us lots of advantages, but along with advantages new challenges had come.