"Modular" Is Not Microservices: Spotting a Rebranded Monolith Before You Buy One

Fourth part of a series of articles that tries to cut through the fluff in insurance core system marketing and to align terms for core system buyers. 

In this 4-part series

1. Cloud-Native — Read here

2. Configurability — Read here

3. API Counts — Read here

4. Microservices — Current article

Every insurance core vendor's architecture slide now shows neat little boxes: product, policy, claims, billing, etc. The boxes have gaps between them, meant to suggest modularity or microservices. Boxes on a diagram are free, while building microservices is not (and most of the industry hasn't paid the price).

What microservices are, and why an insurer should care

Microservices means the core is composed of independently deployable, scalable, replaceable services, each owning a business capability and its own database schema, talking to the others through well-defined APIs. These microservices are broken down into appropriate granularity based on business domain responsibilities. Simply providing 2–3 monolithic applications does not constitute a microservices architecture.

Why should an insurance CEO or CTO care about what looks like an engineering preference? Because nearly all commercial promises made by a vendor depend on it downstream:

• Evergreen upgrades. When services are decoupled, vendors can update core modules seamlessly. Customizations live either as isolated peripheral microservices or lightweight plugins bound to small, discrete services. Because the impact scope of change is minimized, core platform upgrades become routine, non-disruptive events. In a monolith there is no real boundary between the vendor's core modules and your customisations. That is why monolithic upgrades are eighteen-month projects, and why so many insurers are stranded on outdated versions.

• Dynamic scaling. Quote traffic spikes during a campaign; renewals batch overnight; claims spike during a pandemic or after a natural disaster. While some functions are CPU-intensive, some are memory-intensive. When services scale independently, you pay for what you use. A monolith scales as an indivisible block, if your underwriting module is under load while your renewal batch module sits idle, you still pay to scale both.

• Maintainability. A multi-million-line monolithic codebase imposes a massive cognitive burden on engineering teams. Microservices drastically reduce onboarding time and maintenance costs: developers only need to understand the bounded context and API contract of some microservices rather than the entire monolithic application.

• Fault isolation. Resilience and fault tolerance are critical. A quotation service failing should degrade new business processes, not take down policy endorsement or product management. In a monolith, everything shares everything, including failures. Microservice architecture inherently provides the foundation for limiting the “blast radius”, while also enabling the implementation of advanced features such as graceful degradation.

• Replaceability and extension. Each microservice is a self-contained unit with its own API boundary (its own “shell”). It lets your team (or your system integrator) add and swap capabilities without an open-heart surgery on the core. This also reduces vendor lock-in and long-term optionality.

Speed-to-market, upgradeability, resilience, optionality, and so on — these are all downstream benefits of this one architectural decision.

Where the marketing is often quite liberal

Microservices can't be verified from a single slide. That’s why a familiar vocabulary has evolved to imply them without the inconvenience of building them: "Modular." But modules that compile into one deployable, share one database and ship on one release train are not microservices. That is a monolith with a well-organised folder structure but without the key benefits of microservices.

Some vendors claim to build microservices, but it usually just happens around the edges for the latest developments. A vendor may add a new rating or analytics service, while the main policy, billing and claims still live in a handful of giant deployables, meaning 90% of core business functionality still lives in 10% of services. The whole platform is then presented as "microservices architecture". Ask where the core business logic lives, not how many services exist.

Credit where due, because the honest examples deserve naming. Socotra built its platform on a true microservices architecture from day one (same as Peak3). BriteCore is, to our knowledge, the only previous-generation player bold enough to pursue a genuine multi-year comprehensive architectural refactoring to transition to microservices. 

Both prove that this can be done properly, and doing it properly is rare and expensive. When a vendor claims a decades-old platform quietly became microservices without an architectural transformation of that scale, then your spidey senses should be tingling.

What to probe as a buyer

An architecture diagram is a good start, but nothing more. Here are the questions that reveal whether the architecture delivers or just looks good on a slide.

• Show me the deployment methodologies: How frequent are deployments, and what deployment strategies (e.g., rolling deployment or blue-green deployment) are used? How does the rollback operation work? True microservices yield frequent, non-disruptive deployments driven by robust DevOps automation.

• Show me your microservices inventory: Does each microservice have data ownership and its own API specifications (e.g., some samples on swagger)? Does each microservice strictly own its database schema, or do multiple services directly read and write to a shared, monolithic database?

• Show me how you govern microservices architecture: How do distributed tracing, cache partitioning, logging and monitoring, inter-service communication and dependency management, configuration management, etc. work?

Why this matters in the agentic AI era

Microservices used to define how fast human engineers could change the system. Now they determine whether AI agents can interact with it or build upon it at all. Agents extending the core (writing new plug-ins and modules, the deepest level of what we've called an AI-native core [link when published]) need clear service boundaries. 

An AI agent can productively understand, refactor, and write tests for an isolated microservice, whereas feeding it a multi-million-line monolithic codebase leads to context exhaustion and low-quality outcomes. This makes microservices the natural foundation for an AI-driven software development lifecycle (AI SDLC).

Furthermore, agents operating the business or configuring the business need capabilities exposed as clean, independently scalable services. These are natively enabled by an API-native microservices architecture. Agent interfaces like MCP and CLI are only ever a surface expression of what lives underneath.