From Monolith to Microservices

To tackle this monolith, we initially began exploring how the codebase was built. It had a high level of complexity with too many features baked into the all-in-one code, as well as thousands of unit tests. Without consistent APIs, many nonstandard integrations, or one-offs, had been deployed.

Tight coupling of integrations existed at every level, including on modules and datastores, without boundaries. For functional test cases, quality took a big hit. Lot of gaps were present and band-aid fixes often led to further quality issues.

For the second step, we examined how the codebase was operating. A single runtime of this application revealed problems around scalability, availability, performance, and resiliency. Vertical and horizontal scaling limits resulted because it was an all-or-nothing scenario.

The availability of modules was impacted since everything was run as a single deployment. Resiliency was also impacted because of the inability to isolate an issue if something went wrong, bringing down the whole system. In addition, lengthy release cycles negatively impacted both team productivity and organization scale.

It was a herculean effort to manage releases, with lots of engineers committed to building, testing, and deploying. From the security perspective, tightly coupled integration, along with the age of the code and the health of the code base, was making it more difficult to quickly adapt to new security standards and models.

Source: medium.com