How we developed IT in Leroy Merlin: engine reassembly on the move

Four years ago, the customer base was maintained separately in each store, plus another one on the site.

In the previous series: three years ago we decided that we need to do our development in Russia. Two years ago, they began to write their own code instead of modifying the fork code of the parent company. Today's story will be about how we switched from one big legacy monolith to a bunch of small microservices connected by a kind of bus (orchestrator).
')
The easiest user: make an order through the website and pick it up in a real Leroy Merlin store in Russia. Previously, online store orders were processed in another application in general and in a different way. Now we needed an omnichannel showcase, so that any order would be broken down into an interface: cash desk in the store, mobile app, terminal in the store, website — whatever. If you put Linux on a microwave - let it be a microwave. The main thing is that some interfaces can knock on the API to the back and say that you need to place such an order right here. And they got a clear answer to this. The second story was with requests for the availability and properties of the goods from his card.

At the front (we will write about it soon), we have a monster - AEM, and behind it in the back there were two large applications: OPUS and MoVe. The first is the database of the properties of each product (from dimensions to description), the second is responsible for the checkout, that is, the cash register monolith. If greatly simplified.

What was wrong with Opus?

OPUS is a large distributed database. More precisely, it is a software that provides an interface to the database, that is, it accesses the database and, for example, searches or simply exposes the API so that clients do not go directly to the database. This software works and is supported in France. The second feature, as we have already said , is that the queue of improvements on it is very long, and we are not in the highest priority in comparison with the business unit of France.

With great difficulty we could understand how developers could make changes without a team from France, there were very long approvals. The feature was released for six months. Actually, at first we wanted to do our development and their review, and then we came to our own development, our infrastructure, our tests and in general all our own. And at the same time they threw out almost a third of the Legacy code.

But back to the OPUS. Since the system stores up-to-date information on availability, characteristics, transactions, etc., we pounded on it for any reason. Specifically for the site, this meant that if the user has three items in the basket, then you need to knock into the database from each page, because it is checked for relevance. Even if you knock once for the cache, and then update it intelligently, there were still features. When you open the catalog page in general, all product specifications were taken from OPUS.

The logical next step is that we began to pull OPUS more seldom and made our base (more precisely, microservices with databases). The system as a whole was called Russian PUB.

Then they made an orchestrator, which can already store aggregates, that is, in fact - the collected data for the construction of pages. In the sense that when the user switches the page view from the cards to the lists, it is still the same unit, only the front is different.

That is, we have left the original OPUS now (it is still in France), but our almost complete mirror “sticks in” to it, which cuts the base into pieces, ready for assembly in the orchestrator. And the orchestrator collects and stores the units (or gets them quickly and starts to store them), which are needed by other systems. As a result, this part works as it should. From the original functionality of the French OPUS, there are about five percent. Soon we will completely replace it.

What was wrong with MoVe?

Nothing special, except that we decided to throw out all the code, because it:

1. It was ancient on the old stack.
2. He took into account the characteristics of each Leroy Merlin region in the chain of IFs.
3. It was read and maintained so difficult that the best method of refactoring was “write again and document it right away”.

What we did. Only we rewrote it not as a monolith, but began to make microservices for each individual function around. And then they smoothly took away part of the MoVe functionality with switching to microservice. And so - one by one, until the MoVe functionality is not completely over. That is, it still works, but somewhere in a vacuum and without data streams.

Since the platform we collected from the pieces, the project was called Lego.

Lego completely changed this middle. Yes, let's clarify: the real back is legacy bus, file systems, databases, and so on, almost that infrastructure level. Large applications around it and microservices of logic are middle. The presentation is already up front.

Why did you need to rewrite all this?

Because we lived with separate client bases for each instance for 15 years from the opening in Russia, and this did not suit anyone. There was no synchronization either. In other countries, still live.

The parent company from France made general logistics, we reused the Pics system - this is a single depository of checks, that is, client orders: one store sees orders from another store. But this did not completely solve the omnichannel order problem. Therefore, it was necessary to consolidate the base and do general processing. This is the main thing.

The second reason was the federal law on cash registers: with our deadlines for the development of a common for all countries system (and testing), we would have flown fines.

Approximately a similar version of the run-in in Brazil: they started there “Leroy Merlin” in general without the software of the parent company, and they did it. That was before the split decision. They, by the way, commit a lot to the investors , they have very fast development.

Pixys allowed to place an order only from the cashier, in fact. We changed the situation in three stages:

1. First, they made a mobile application for an employee, which greatly simplifies his life. On the basis of this, they began to build an ecosystem, where interfaces are divided with logic.
2. While everything was set up, Internet orders were hammered into the cashier.
3. They put microservices in turn, which replaced it all in the middle.

Why did you need to start with the app stores? Because we also have unique processes in comparison with France. For example, a person decided to buy six meters ten centimeters of a chain in a store. The seller cut off to him, gave a document, how much length there is and how much it costs. You go with this piece of paper to the cashier, you pay there. From the point of view of logic, the sale is not at the checkout, but the seller should be, but in fact it is at the checkout that the fun begins: there must be both a product and a piece of paper.

In the end, we are moving towards being a platform for placing orders: for example, now, for example, on top of our main system, there were services for buying the services of masters (I bought a kitchen — I ordered the installation from an external master, and we found it and gave a guarantee from myself) purchase directly from the supplier for a wider range), and soon there should be an affiliate program so that our blocks can be placed anywhere. Something like embedding Amazon stores into blogs, only more versatile.

How was the decision about the replacement made?

I step. Refine the business model.

We checked, and indeed: the model, as in Russia - low prices every day - is successful. "Leroy Merlin" in Europe is significantly more expensive, but it is in the Russian Federation that this is our niche: a hardware store, where there is definitely a product at the best price.

II step. Create a client script.

That is, to build processes, how we want to interact with us from the point of view of the client. That is a single vision, who we want to be in a few years and how it looks from the point of view of architecture.

III step. Build architecture.

Break this vision into concrete TK and architecture with higher detail. It turned out 110 projects that we have distributed for five years into five categories.

Then they formed profile teams. Most often these are their people plus a contractor. At first, they suffered greatly from this: when they went for food, they did not really understand how to digest such a large amount of changes. Then they began to make a common approach for the tasks and gradually increase the share of their development.

In those places where the error was critical, they worked according to NASA schemes, where the error is unacceptable is not an option at all. It's all about money transactions.

And where it was possible to fall, the main thing was to rise quickly, using an approach close to Google's SRE. Iteratively, with jambs, but projects could be implemented as soon as possible. And now we are doing so much, and this is very cool for development.

The third approach is innovation. Developed a sandbox of ideas to quickly make the first MVPs with internal resources that allow you to test quickly and cheaply. This is the real “try fast, fail fast”. This allowed getting the budget and powers to those who came up with a cool project.

The second important focus was in geo-development. Then opened at 20 stores a year (now a little slower). Six thousand employees. Many regions. It was necessary to rewrite the entire supply chain, quickly develop the processes of raising the infrastructure of shops.

In 2017, we decided to become a platform for construction orders: this is a promising strategy for several years to come.

For geography, we needed a large IT back office to grow the company and grow the supply chain. For omnikanal (general order) - another level of SLA on internal systems, realtime, microservices and synchronization between hundreds of subsystems. This is generally a different level of IT maturity. For the platform, the speed of change is also important.

When it first began, everyone thought that agile would save the world. In the presence of contractors, agile may not be as effective. Hence the desire to recruit 200 people in the IT department.

We looked at how quickly we can implement everything without a loss for the brand. Something could be written quickly, but did not have time to prepare the service. For example, if there is no stock information, then there is no possibility to pay online without a guarantee that the goods will be reserved. Lay out the chain of interdependencies into several. Now we already know that it is necessary to make cycles shorter, because the competences of the team are still important. Now we are sawing features in small pieces, we are collecting a connection, now only the current year is in the plans. Long-term strategy, but by features, - one year maximum, and many individual teams on products.