Why Enterprise Search Tools Break at Microservice Scale

Most enterprise search tools were designed for a world that no longer exists — a world where a company had a finite number of applications, each with stable documentation, owned by a stable team, accessible through a stable URL. That world died somewhere around the time the average enterprise crossed 100 microservices. By the time you hit 300, the documentation problem has stopped being a documentation problem. It is a retrieval problem.

I have led platform engineering and DevOps transformations at Fortune 500s for over twelve years — Pearson, Liberty Mutual, Comcast, Aetna, Gilead Sciences. In every one of them, the same friction surfaced as service counts climbed. The off-the-shelf enterprise search tools they had bought in 2014 could not answer a question a 2024 developer needed to ask: which of our 312 services owns this endpoint, who deploys it, and where is the runbook?

Why does microservice sprawl break enterprise search?

Three reasons. First, the documentation is fragmented across dozens of repositories, wikis, and dashboards — and a keyword search across all of them returns hundreds of false positives because every service has a README that contains the word “deploy.” Second, the institutional knowledge that ties services together — who calls whom, why we built a sidecar here and not there — lives in pull request descriptions, Slack threads, and architecture decision records that the search tool was never pointed at. Third, the rate of change is too high for human curation to keep up. A document indexed last week is already stale.

This is fundamentally a different problem than “the SharePoint search box does not work very well.” This is what happens when you cross a complexity threshold where no single human can hold the system map in their head. At that point, you do not need better keyword search. You need semantic retrieval across every surface that holds organizational knowledge.

I watched this play out in real time at Liberty Mutual.

In 2016 I joined Liberty Mutual to lead the build of a platform we called Fusion — Jenkins, Chef, Docker Datacenter, declarative Fusionfile configs that let teams define their sidecars, data layer, and pre/post deploy steps. By the time I left in late 2017, the platform was a Docker case study: 330+ services running in production, hundreds of deploys daily, dozens of teams shipping into the same fleet. What surprised me was not that we hit that scale. It was that nobody at Liberty could find anything anymore. A developer joining a team in 2017 had no way to discover which existing service already wrapped IBM DataPower the way they were about to wrap it again. The platform won. The search problem got worse.

That is the trap. Every successful platform engineering effort multiplies the number of artifacts that exist — services, configs, runbooks, ADRs, dashboards, incident reports — without proportionally improving the way anyone finds them. The platform team optimizes for throughput. The developer experience optimizes for shipping. The search experience stays whatever the company bought in 2014.

What does enterprise search actually need to handle today?

Five surfaces, minimum. Source code repositories with their READMEs and ADRs (GitHub or equivalent). Wiki content (Confluence, Notion). Documents (Google Drive, SharePoint, OneDrive, Dropbox, Box). Communications (Slack, Outlook, Teams). And ticketing (Jira, ServiceNow). A 2024 question — “why did we choose to put the rate limiter in the gateway instead of the service?” — can have its answer in any of those five. The right enterprise search tool reads all of them as a single corpus and returns a synthesized answer with source citations. We dug into this pattern in our piece on cross-platform search.

The other half of the requirement is freshness. In a microservice environment, a runbook from six months ago is suspect; a runbook from six weeks ago might already be wrong. Enterprise search tools that batch-index nightly are already too slow. You need continuous or near-continuous ingestion, and you need the search layer to treat newer documents with appropriate weighting. Our IT department page covers how this matters for incident response specifically, where a stale runbook can extend an outage by hours.

Why does the SaaS sprawl multiplier make this worse?

Microservice sprawl is not the only sprawl in play. The same enterprise that ran 330 services at Liberty Mutual also ran some absurd number of SaaS applications — we wrote about this in the SaaS tool sprawl search problem. The 2024 average enterprise uses 112 SaaS apps. Each has its own search bar. None of them talk to each other. The microservice fleet and the SaaS fleet compound into a search problem an order of magnitude worse than what either creates alone.

How RetrieveIT fits

RetrieveIT was built specifically for the “one searchable corpus across many systems” problem. It indexes the surfaces your platform-engineered fleet actually generates artifacts in — GitHub, Confluence, Slack, Jira, Google Drive, SharePoint, OneDrive, Dropbox, Box, Notion, ServiceNow — and runs semantic search across all of them with per-query permission checks. A developer asking “which service handles webhook retries?” gets back the relevant code file, the ADR explaining the choice, the Slack thread where the team debated it, and the Jira ticket where the original bug was filed — together, with citations.

We covered the closely related question of what HR organizations face in why HR knowledge bases fail at Fortune 500 scale. The shape of the problem is the same: you cannot fix retrieval at scale by adding another system. You fix it by making every existing system part of one searchable layer.

The pattern, restated

Every successful platform engineering transformation creates more artifacts than the previous tooling can index. By the time you have 300+ services, the search tool you bought to handle 30 is invisible to your developers. The fix is not a bigger search tool. It is a fundamentally different architecture — semantic retrieval, continuous ingestion, source-system permissions, and a single answer surface that spans every place organizational knowledge lives.