MICROSERVICES – Really Splitting The Vertical

At the early stages, software startups focus on speed rather than quality. After a startup has grown and its technology and business become mature, the company’s approach is shifting from speed to quality, which becomes their main differentiators on the market.

Through the looking glass

The early stage software startups develop few common traits:  

  • They focus on speed rather than quality. 
  • They test POCs (Proof of concepts) viability straight on the market. 
  • They often pivot to a new product. 

However, after a startup has grown and its technology and business become mature, the company’s approach is shifting from speed to quality, which becomes their main differentiators on the market.

Business model – a relevant example

One of our high-level clients that went through all the growing and funding stages, pivoted from startup to unicorn, from unicorn to mature stage, works in the retargeting advertising business. The main goal of their business is to provide online retailers with the means for display advertising to consumers who visited retailers’ websites.

The figure below is well summarizing this process.

Challenges

The client started with a managed service model. While their customers had access to a front office tool, which could be used to see some statistics about their campaigns’ performance, there were few actions for the final users to do. Instead, most of the actions were made by our client’s specialists on behalf of their customers using an additional back-office tool. The only final user’s interaction was to approve our client’s actions by using a front-office tool. The back-office and front-office tools were communicating. But the customers did not find the solution appealing for their business.

As the company was growing, a few business challenges emerged

  • To grow its customer portfolio, the company could not rely on its existing business model. To scale up, they needed to do adjustments and shift from managed service to self-service. For such capabilities offering, they have considered Google Ads and Facebook as examples.
  • Since new types of customers kept looming and asking for support, the company needed to add more and more business scenarios to the platform. Therefore, the business model had to be extended to in-app ads or to advertising on retailing platforms.

There were also a few technical challenges that had to be effectively addressed 

  • The front-office and back-office tools were big monoliths initially built by individual teams and, as more and more features were needed, they had to be adjusted accordingly. Their team was constantly growing, and various articles were added in. However, applications were still single repository monoliths. As a result, it became challenging to keep the sandboxes green and make releases without a rollback. Every time they have encountered a critical bug, a rollback became a must and a standard. But rolling back all the features previously developed became a constant bottleneck.
  • They migrated to the latest technologies for both backend and frontend. .NET technology was used for the backend development and deployed on high-level Windows machines. The goal was to migrate to the latest version of .NET Core, deploying on Linux, as that would have saved costs. On the frontend, the team migrated from AngularJS to Angular.
  • There was a need to scale the platform to support more and more customers. 

Solutions

As the business model transformations were imminent, the client company initiated a series of discussions regarding the technical changes.

Onboarding more teams to develop extra features into the front office tool was not the optimal scenario, therefore the final proposed solution was to transform the front office into a platform encompassing a few applications with the following features:

  • Act and look like a single application – even if deployed on separate servers.
  • Each application will manage one module of the platform (e.g. campaigns, budgets, ads, etc.).
  • Have the same look & feel – for improved user experience.
  • Single navigation bar – for improved user experience.
  • Use SSO (Single Sign-On) and a unified authorization system.
  • Deploy the applications under the same domain and use a reverse proxy to redirect from the master domain to the domain where each application will be deployed.

In future articles we will provide details on how each of the points above was implemented

The architecture of the platform in a nutshell: 

As you can see in the picture above, we have decided to use microservices to develop the platform and split the existing functionalities. The best solution was to split not only the backend section, but also the frontend, as they were both residing next to each other. Each application has a micro-frontend, a micro-backend, and a dedicated database. This way we achieved the full vertical split allowing a single team to take care of a specific vertical and fully develop a feature without being compelled to involve other teams.

The challenge of being on time 

Adjusting the development of an existing application is always more challenging than developing one from the scratch. It is well known that the business teams’ demands tend to expand during the development process within the same initial timescale. The urge and enthusiasm to go to market as fast as possible are understandable in such fast-paced and fast scaling environments, but we need to be mindful of the impact of the high level of pressure we add to the operational teams. In our case, the team chose to accept the challenge. We continued to develop new features whilst migrating to the micro-services. At that moment, we realized that we needed to be creative: we came up with a hybrid approach – we kept the old front-office application and the new micro-service applications side by side. As long as they had the same navigation bar and the same look and feel, the old front service application could be seen as one application.

The benefits of a new architecture 

What are the advantages of microservice systems:

  • It allows the teams to start new services from scratch and easily adopt new technologies on a micro-service. We decided to keep the same technology stack on all applications.
  • It allowed migration from dedicated Windows deployment machines to Mesos containers deployed on Linux. This way we saved costs.
  • We were able to scale the platform horizontally and deploy the applications easily on multiple datacenters.
  • We managed to split the teams more efficiently – each team got a sense of ownership on its own application.
  • We empowered the teams to develop faster and allowed them to release according to their pace. They chose small incremental releases: once or twice a week.

What are the disadvantages of microservice systems? 

Microservices are not a silver bullet to every problem nowadays, and there are a few things worth mentioning. Below are a few possible means:

  • From the frontend perspective, the migration meant that multiple SPA (Single Page Applications) were deployed. When the user switched from one module to another, he/she would have seen a small delay until the new SPA would have been loaded locally. For that, we decided to tackle this further by moving to a shell application that could dynamically load each of the modules without downloading again the whole java-script file.
  • The overall system complexity increased. This meant that the teams had to invest more time in monitoring, using tools like Grafana/Graphite for building dashboards alerts, Zipkin for tracing requests within the microservices environment, Kibana/Logstash for aggregating the logs.
  • The likelihood of potential service failures was increasing. Each team had to design their features keeping in mind that they should dedicate time also for cross-network calls.
  • Testing the platform – that was already a challenge from the start. To flex that, we decided to switch to contract testing instead and have each service tested in isolation. The stack of testing meant unit testing and contract in backend, unit and integration testing on frontend, UI with a mocked backend testing.
  • Silos between teams. As each team has full ownership of a module, with time, a silo may appear between teams, especially when the teams are distributed in multiple locations. This needs to be tackled from day one to make sure that the teams communicate relevant topics and follow and share the best practices. Moving for instance a person from one team to another within the same location is easy, as all the applications use the same patterns and the same technology stack.

You may also like...