From monolith to momentum: How prioritizing user experience over technical perfection paid off.

To understand technical challenges of MOTORS, it is important to have a look at its rich merger & acquisition history: Founded in 2007 it became in 2019 part of the eBay classifieds – as part of Gumtree UK, and was sold in 2021 to O3 Industries and Novum Capital. Motors.co.uk has since rebranded as “MOTORS” under its new ownership and continues to offer advertising across eBay and Gumtree through a multi-year contractual agreement.
 
The focus of our MOTORS team was on enhancing the online automotive retail experience, specifically for car dealers. We have been working with MOTORS for a couple of years, starting in October 2021.

We operated with a mixed mode team model, with another partner from Novi Sad, blended with team members from MOTORS:
 

• Three ProductDock backend developers
• Two ProductDock Devops engineers (who are supporting the separate SRE team)
• Two .Net developers from our partner in Novi Sad

MOTORS’ monolith system faced challenges stemming from legacy services, internal ones and those inherited from the various company changes. In general, legacy systems tend to become slow over the years and are difficult to maintain, which makes them expensive. Working on a running system that is used by millions of users a month, we were well aware that we couldn’t just start from scratch and modernize everything at once. MOTORS followed a strategic approach, looking for what has the most impact.
 
An area identified for importance was the syndication services (the process of posting a vehicle listing to the MOTORS Website and its other partners such as eBay and Gumtree). Dealers had provided feedback that they would see syndication services to increase in speed, shifting to near realtime. We had to make sure the migration of our 5000 car dealers to a new syndication service would not cause issues or incidents, and sustain the existing functionalities.
 
Another challenge we faced was navigating the complexities of an ongoing merger and acquisition process. These phases introduce additional challenges, often leading to significant reorganizations that impact both team structures and technology strategies. For our team, this meant working in a constantly evolving environment where responsibilities and priorities shifted frequently, making it challenging to collect requirements and maintain continuity.
 
In regards to technology decisions, we needed to cover both cloud platforms, Google Cloud Platform (GCP) and Azure, since the services of the different syndication partners were hosted in those different providers. And we needed to ensure seamless integration and reliable operations across both providers.

Service rewrite

 
We started writing the microservice in the GCP cloud while the legacy system, monolith, is in the Azure cloud. To modernize the syndication part we used a common pattern for this use case: Strangler pattern (Strangler pattern is an incremental migration approach where a new system gradually replaces specific features of a legacy system until the old system can be fully retired). As the existing syndication framework was originally built in Vanilla Java it was decided to replace this code and rewrite it using microservices architecture with Java and Spring Boot running on Kubernetes as our container orchestrator. For the integration and asynchronous communication of the services we used GCP Pub/Sub, a messaging service that decouples services producing messages from services processing those messages. This was the first iteration. For a second iteration, MOTORS decided that services built and hosted on GCP should be lifted and shifted to Microsoft Azure, as Azure had been selected by the new organization as its preferred cloud infrastructure.
 

Migration from GCP to Azure

 
So the next migration part followed, where we moved the services to Azure. As we had containerized everything in the first iteration and used an event driven system, the GCP to Azure migration was not complicated. We used Kubernetes on Azure (adapted our Terraform infrastructure) and switched from GCP Pub/Sub to Azure Service Bus.
To complete the transition, we also introduced Azure Pipelines to replace the Jenkins and Spinnaker pipelines previously used on GCP, streamlining our CI/CD workflows.
 

Migration of the data

 
Finally the migration of the listing data to the new service followed: With the Azure setup in place we were able to migrate all car dealers and over 250,000 listings from the old service to the new one. There had been limitations with how much data could be migrated at once. We’ve solved that issue using batches of car dealers that could grow with every batch cycle since we knew after the first rounds that it’ll work. Together with our SRE (Site Reliability Engineering) team we introduced incident alerting and monitoring, using Prometheus and Grafana, to make our services robust. They helped us set up thresholds to get relevant alerts immediately and great monitoring dashboards. If you’re interested in the work of our SRE team, read the article about their work.
With this, the syndication part was completely removed from the legacy monolith system. The migration was seamless, with no noticeable downtime or actions required either for our account management team or from car dealers throughout the transition.
 
After everything finished we can proudly say that we significantly reduce the time it takes to post listings across multiple platforms: from hours to minutes achieving our goal of near real-time.

• Modernize large enterprise platform piece by piece: Strangler Pattern as a feasible approach to initialise the transition from a monolithic legacy system to a microservices architecture.
• Successful Cloud Migration: Executed a migration from GCP to Azure to implement scalable, reliable, and cost-effective cloud solutions.
• Increased Efficiency and reduced costs: Optimized system performance and addressed technical debt, thus avoiding opportunity costs.
• Dramatically Improved Syndication Speed: Reduced syndication time from hours to minutes.
• Thus enhanced Dealer Retention: Addressed a key business issue by streamlining the syndication processes.

• Event-Driven Architecture: Enables highly responsive and scalable systems. By reacting to events in real time and decoupling services, we gained much greater flexibility in evolving and extending our platform.
• Business needs versus software modernisation: There is always a tradeoff between “keep the system running” and “build a better system”. The first generates costs because there is always time and budget efforts required to support and fix legacy systems. While the second would avoid all those opportunity costs mentioned, prioritizing an improved system can lead to feature freezes, upfront investment costs, and potentially limited user experience. Ultimately, the decision hinges on the organization’s most critical business imperatives; in our case, improving car dealers’ experience by building a modern syndication service.
• Strangler Pattern: A pattern worth looking into for software modernisation is the Strangler pattern which we utilised to modernise the system piece by piece. Teams can release new functionality on the modern system while the legacy system still runs.
• Insights about Automotive Retail Platforms: Understanding the unique challenges of online car sales, including dealer management, inventory syndication, and customer experience helped us a lot to understand what we need to prioritise and why MOTORS’ management prioritised topics. Furthermore, the gained knowledge enabled us during the merger & acquisition phase to support the onboarding of new colleagues.
• Ability to adapt and improve: Monolithic systems lead to a lot of challenges especially when you as a mixed team are looking forward to starting with a diligent plan to replace the monolith by a nice and lean microservice architecture. And then life is what happened to us while we were busy making other plans: Performance issues with an impact on user satisfaction, and changes due to merger & acquisition activities had been very good reasons to not stick to a predefined plan. We are very proud and thankful that together with our team members from MOTORS we have been always able to adapt to the new circumstances, embrace change, and keep improving the product for our users – no matter what challenges come our way.