A US insurance leader approached us with an ambitious project implying a complete application revamp. The business application provides functionality for real estate title insurance and reinsurance which both client’s agents and partners use in their day-to-day work. The previous vendor started the project six years ago and by now it has grown significantly. However, the tech stack had seen few updates since the project initiation. Severe technical debt made it impossible for the previous vendor to ensure proper application support, let alone new features development. The previous partnership with the software development vendor became more of a burden for the client, as it would take the vendor unreasonably long to meet business demands. By the time the client handed the project over to us, the need for new functionality had reached a critical point. Several modules didn’t function properly, so the client wanted it fixed, too.
The pile of the technical problems that came with the project couldn’t be resolved overnight. The tech stack had not seen any significant upgrade in years, so the tech debt accumulated over time asked for a rigid approach to deal with.
The technological stack (both backend and frontend) was to be migrated to the latest releases. When Symfa joined the project, both backend and frontend were running on the unsupportable software versions, which was a source of potential security breach. The team was to improve/rewrite the code on the new tech stack. The application is also going to migrate to the cloud and the microservice architecture afterwards. Last but not least, the client is planning to expand the application functionality with new strategic features.
To summarize, the solution to the complex client’s problem lies in three consecutive steps:
To implement a wide scope of changes, together with the client, we shaped the following strategy:
Phase 1 — backend code revision + migration to the cloud.
Phase 2 — migration to microservices + frontend code revision and refactoring.
Currently, the project is in Phase 1. The application is running as two macroservices that later on are planned to undergo further decoupling. Each macroservice refers to a single separate module.
The application has been under development for six years and has grown massively complex for its relatively modest size. To migrate a single backend module, five developers have been working on code improvements and fitting it into the cloud infrastructure for five months now.
The application frontend was migrated to the cloud as is. In the following phase, the team will do a significant frontend code revision and refactoring, along with revising the existing app functionality and adding new modules.
Microservices isn't a one-fits-all solution. Despite all the fuss it has received recently, it is far from the best fit for many projects. As for the current application, it is still subject to future speculations within the project team whether a costly decoupling into microservices will pay off.
Microservices isn’t mainly a technological solution. Rather, it is an architectural approach embracing the whole organization. If a company has a set of digital services that represent all its business landscape, microservices can match its business needs.
Let’s consider a situation, where each business service in a company is represented by a monolith. It may hamper data transfer between the services and the company operation, in general. For example, one monolith supports five types of orders and provides some customer info; the other provides different customer info and supports warehouse operations. In a monolithic structure, two neighboring modules can’t freely communicate with each other. In order to get the information from a neighboring monolithic application, several painful integrations sometimes need to be performed. Such functionality as a rule implies multiple intermediate points (gateways, data buses, APIs). Thus, information interchange becomes a tedious labor-intensive process.
Microservices allow direct informational requests between the neighboring modules. This architectural approach implies that neighboring microservices can use properly documented APIs for an easy data interchange. Simply put, it enables granular information retrieval without intermediaries.
Such an approach eliminates intermediate points, frequent support requests, long project timelines and allows organic shift from waterfall to agile methodology. These are the major reasons why companies move to microservices and why our client is considering microservices migration on this project. However, with the complexity that microservices introduce, it is yet to be decided whether this particular project qualifies for the migration.
Our team will get back to you promptly to discuss the next steps