DEV Community: Yuvraj

Why Your IDP Fails at Adoption (and How to Fix It)

Yuvraj — Tue, 08 Sep 2026 13:10:18 +0000

Backstage's user base has quadrupled to roughly 2,200 companies. Adoption still plateaus at around 10% of developers per company. Something other than "not enough tooling" explains that gap.

You shipped the internal developer platform. Leadership signed off, the platform team spent two quarters building it, the launch email went out with a Loom demo attached. Six months later, half your engineers still file Jira tickets for infrastructure and avoid the portal you built for them.

If that sounds familiar, the data says it's a pattern, not a one-off. Platform engineering maturity research from platformengineering.org puts the scale of it in numbers: 40.9% of platform engineering initiatives can't demonstrate measurable value in their first year, and 29.6% of platform teams don't measure success at all. The gap sits in strategy, before any tool gets chosen.

Cycloid is one of the platforms that structures itself around exactly that sequencing problem: provisioning first, catalog second. What follows is the failure pattern behind low IDP adoption, drawn from that research plus how platform teams that fix it actually operate.

Why This Keeps Happening in 2026

Platform engineering isn't a hard sell anymore. Every platform team pitch deck has the same slide: golden paths, self-service, reduced cognitive load, faster onboarding. Leadership signs off and approves the budget. Then the platform team builds a catalog, a searchable index of services, owners, and docs, and bolts a provisioning workflow onto it as an afterthought, if at all.

That ordering is the problem. A catalog tells developers what exists. Provisioning lets them use it. The ROI comes from the second half, and most platforms never get there before the goodwill runs out.

Three data points illustrate why:

- Platforms that try to solve everything at launch fail 78% of the time. The ones that start with a single high-pain workflow, usually environment provisioning, don't.

- 76% of engineers report that software architecture cognitive burden hurts their productivity; 52% flag context switching between tools as a primary drain. A portal that adds a new tool to switch to, without removing steps elsewhere, compounds the problem.

- Self-hosted Backstage instances typically need 3–15 FTEs to maintain, with teams spending 30–40% of platform engineering time on plugin upkeep instead of building the golden paths that would move adoption.

(Cycloid's guide to internal developer platforms walks through the full breakdown behind these numbers, including where the catalog-versus-provisioning split shows up in practice.)

Low usage often gets read as developer resistance. In most cases it's simpler than that: the platform optimized for the wrong milestone, a launched portal instead of three fewer days of waiting each week.

Four Reasons IDP Adoption Stalls

1. Trying to launch with everything at once

Ambitious platform teams tend to scope the v1 roadmap around the ideal end state (full service catalog, every cloud, every environment type, RBAC for every team) rather than the one workflow developers hit most often. The result is often a platform that's 80% built and 10% adopted. Teams that instead pick the single most painful, most frequent workflow, almost always environment or infrastructure provisioning, and nail that first tend to see measurable traction 2–3x faster than teams chasing full coverage from launch.

2. The platform doesn't have a product owner

Only 32.9% of organizations have a dedicated Head of Platform role, and that gap tends to show up in what platform teams choose to build. Without someone accountable for adoption or developer feedback loops, teams run purely by engineers can end up shipping features nobody asked for while the unglamorous work (onboarding flows, documentation, in-app nudges) that drives usage gets skipped. Teams with a dedicated platform product manager see 2.3x higher internal adoption than engineer-only teams, and organizations with a Head of Platform report 40% less misalignment between platform investment and the business outcomes leadership cares about.

3. The catalog ships, the automation behind it doesn't

This tends to be the most common failure mode, and one of the least discussed. The portal looks finished. Developers can search for services, see who owns what, read the docs. But when they try to provision something, they're often still filing a ticket and waiting three to five days for a platform engineer to run the Terraform by hand. The interface changed; the bottleneck usually didn't. Developers tend to notice within a week and quietly go back to whatever workaround they used before the platform existed.

4. Adoption isn't measured, so the problem isn't caught early

Without lead time, provisioning time, deployment frequency, and failure rate captured before the platform ships, it's hard to prove the platform is working, and just as hard to catch early that it isn't. Close to a third of platform teams skip this measurement step entirely. The result is that leadership often hears "adoption is a problem" for the first time at the annual budget review, months after the point where it could have been fixed.

What Actually Fixes Adoption: A Provisioning-First Playbook

The teams that break the pattern tend to do the same handful of things, in roughly this order:

Start with the one workflow developers hit weekly, not the platform they want in eighteen months. Environment provisioning is usually it. If developers can spin up an environment in minutes instead of days, that alone changes how they talk about the platform internally, and internal word of mouth drives most voluntary adoption.

Make golden paths the default, not an opt-in. A golden path is a pre-approved template, with security, tagging, naming, and cost policy baked in, that a developer fills out like a form instead of a Terraform module they need to understand. Infrastructure-as-code variables become something a developer can self-serve without reading the underlying HCL.

Put someone's name on adoption. Whether it's a formal Head of Platform or a designated owner, someone needs to treat the platform like a product with users, not an internal tool with a maintenance backlog. That person's job is retention, not just uptime.

Instrument before you launch, not after. Capture provisioning time, ticket volume, lead time, and deployment frequency before the platform goes live so the before-and-after story is real, not anecdotal.

Keep governance invisible. Policy-as-code enforced automatically at provisioning time removes developers from approval queues, instead of adding a review step they wait on. Guardrails should feel like defaults, not gates.

Organizations that get this sequence right report provisioning time dropping from three to five days down to around fifteen minutes, deployment updates arriving roughly 40% faster, and operational overhead cut by close to half. That's the gap between a platform people tolerate and one people choose to use.

Where Cycloid Fits, and Where It Doesn't

Since Cycloid built its research around this exact failure pattern, it's worth naming where the platform itself lands on the spectrum, limitations included.

Cycloid fits teams whose adoption problem matches a specific shape: the catalog works, but provisioning still bottlenecks on the platform team. It's built as a unified self-service portal and orchestration layer rather than a catalog-first product, matching the provisioning-first sequence the adoption data points to. A few specifics worth knowing:

What it does well:

- StackForms turns infrastructure-as-code variables into forms, so developers provision environments without touching raw Terraform, cutting typical provisioning time from days to minutes.

- Golden paths ship as pre-approved deployment templates with security, tagging, and cost policy enforced by default, governance that skips the human approval loop.

- Native multi-cloud governance across AWS, Azure, GCP, and on-prem, plus built-in FinOps and GreenOps observability (pre-deploy cost estimation, carbon tracking), so cost and sustainability aren't a separate tool bolted on later.

- An open-source foundation (TerraCognita, InfraMap, TerraCost) that avoids hard vendor lock-in, a real concern for teams who've watched catalog-only tools become a second silo.

- Cycloid reports typical rollouts landing in around three weeks rather than the multi-year timelines associated with fully custom Backstage builds, with customers citing roughly 50% faster project delivery and 40% lower infrastructure costs and carbon emissions after adoption. (Figures as reported by Cycloid; verify against your own environment before budgeting around them.)

Where it's a worse fit: teams that specifically want Backstage's plugin ecosystem depth and have the 3–15 FTEs to run it, or teams whose real gap is a software catalog and service ownership map rather than provisioning automation. A catalog-first tool solves "developers can't find who owns what" more directly. The provisioning-first gap Cycloid is built around is a different problem: developers who already know what they need and still wait three days to get it.

For a wider view of the category, Cycloid also maintains a running comparison of the top internal developer platforms, worth cross-checking against your own shortlist, and a longer breakdown of platform engineering for enterprise environments specifically, for teams evaluating this at larger scale.

Catalog-First vs. Provisioning-First, at a Glance

	Catalog-first platforms	Provisioning-first platforms (e.g. Cycloid)
First thing developers touch	Service directory, docs, ownership map	A form that provisions real infrastructure
Typical time-to-value	Months, after catalog and integrations mature	Weeks
Governance model	Manual approvals, ticket queues	Policy-as-code, enforced at provisioning
Maintenance load	3–15 FTEs common (plugin ecosystem)	Lower: orchestration, not a plugin marketplace
Where adoption stalls	Provisioning still bottlenecks on platform team	Catalog and discoverability can lag if not built out

Who Should Actually Use This Playbook

Platform teams six to twelve months post-launch with flat or declining active usage. The fix usually isn't a relaunch. Audit whether provisioning is still manual behind a nice UI, and fix that first.

Teams about to start an IDP build from scratch. Resist the urge to scope the full catalog. Pick the one workflow with the most Jira tickets against it and solve that end-to-end before anything else ships.

Organizations without a platform product owner. Decide who's accountable for adoption metrics before evaluating any tool. A better platform with no owner drifts the same way a worse one did.

Teams already deep into a Backstage build with the FTE budget to sustain it. This playbook still applies. Sequence provisioning automation ahead of catalog polish rather than assuming a tool swap will fix it.

Frequently Asked Questions

Why does IDP adoption plateau even after a successful launch?

Because a launched portal and a used portal are different milestones. Most platforms ship a catalog, developers browse it once, but provisioning still runs through tickets and manual Terraform behind the scenes. Developers notice within a week and go back to their old workaround, so adoption plateaus around the fraction of developers who tried it once out of curiosity.

What's the single biggest fix for stalled IDP adoption?

Sequencing. Build provisioning automation for one high-frequency workflow, usually environment provisioning, before investing further in the catalog. Teams that lead with a working golden path see measurable traction 2 to 3 times faster than teams that launch with full catalog coverage and no automation behind it.

Do we need a dedicated Head of Platform to fix adoption?

Not necessarily a formal title, but someone does need to own adoption as a metric. Organizations with a Head of Platform report 40% less misalignment between platform investment and business outcomes, and teams with a dedicated platform product manager see 2.3x higher internal adoption than engineer-only teams.

How do we know if our adoption problem is the catalog or the automation behind it?

Watch what happens after a developer finds a service in the catalog. If they can provision it themselves in minutes, the catalog is doing its job. If they still file a ticket and wait days for a platform engineer to run infrastructure-as-code by hand, the interface changed but the bottleneck didn't, and that's the fix to prioritize first.

What should we measure before launching an IDP, not after?

Provisioning time, ticket volume, lead time, and deployment frequency, captured before the platform goes live. Without a baseline, it's hard to prove the platform is working and just as hard to catch early that it isn't. Close to a third of platform teams skip this step and only hear about adoption problems at the annual budget review.

Is a provisioning-first platform like Cycloid a fit for every team?

No. It fits teams whose catalog already works but where provisioning still bottlenecks on the platform team. Teams that specifically need Backstage's plugin ecosystem depth, and have the 3 to 15 FTEs to maintain it, or whose real gap is service ownership mapping rather than provisioning automation, are usually better served by a catalog-first tool.

The Bottom Line

Low IDP adoption often looks like a developer-experience problem and turns out to be a sequencing one. Teams build the visible half of the platform (the portal, the catalog, the docs) and delay the invisible half that removes waiting time from a developer's day. A lot of platform-buying conversations focus on which tool to pick. The ones that end up with real adoption numbers tend to spend more of that time on build order instead.

Cloud Resilience Explained: Key Strategies for Maintaining Uptime and Performance

Yuvraj — Wed, 26 Aug 2026 12:35:13 +0000

TL;DR

Cloud resilience is a system's ability to keep functioning or recover quickly when something inevitably breaks, a failed zone, a bad deployment, a provider-wide outage. The stakes are higher than the industry assumed a year ago: AWS and Azure both suffered major outages within ten days of each other in October 2025, and ITIC found over 90% of mid-to-large enterprises now report a single hour of downtime costing more than $300,000. This guide covers what cloud resilience actually requires: redundancy, auto-scaling, monitoring, backup and disaster recovery, chaos engineering, and the infrastructure governance that keeps those from quietly decaying.

Getting Started: What Cloud Resilience Actually Means

Cloud resilience is a system's ability to keep functioning or recover quickly and predictably when something breaks. That's a deliberately broader definition than "high availability" or "disaster recovery" alone, since resilience covers both: staying up in the first place, and coming back cleanly when staying up wasn't possible. A resilient system doesn't assume failure won't happen. It assumes failure will happen, on a schedule nobody controls, and is built to absorb it without becoming a multi-hour incident.

That distinction is worth being precise about, since a lot of teams conflate resilience with redundancy alone: more servers, more regions, and stop there. Redundancy without monitoring doesn't catch a failure early. Redundancy without tested backups doesn't guarantee a clean recovery. Redundancy without governance of the underlying infrastructure tends to decay quietly until the exact moment it's needed and fails. This piece covers the six strategies that make cloud resilience real in practice, not just architecturally assumed:

Redundancy across zones and regions
Auto-scaling and load balancing
Continuous monitoring and observability
Backup and disaster recovery planning
Chaos engineering and resilience testing
Infrastructure governance that keeps the other five honest

Why Cloud Resilience Is Urgent Right Now

The cost of getting this wrong is well documented and consistent across independent surveys:

Over 90% of mid-to-large enterprises now report a single hour of downtime costing more than $300,000 (ITIC's most recent Hourly Cost of Downtime Survey)
41% report costs between $1 million and $5 million or more per hour
Roughly one in five major outages now exceeds $1 million in total cost (Uptime Institute's Annual Outage Analysis)

These numbers move every year, but they've moved in the same direction for a decade: up.

What's changed more recently is how visible provider-level failure has become. On October 20, 2025, AWS's us-east-1 region, still its busiest by a wide margin, went down for several hours after a DNS race condition in the internal automation behind DynamoDB corrupted a critical endpoint record. Because so many AWS services depend on DynamoDB internally, and because us-east-1 hosts a meaningful share of AWS's own global control plane, the failure cascaded well beyond DynamoDB itself, ultimately affecting 141 separate AWS services.

Nine days later, on October 29, Microsoft Azure had its own major incident: a configuration change to Azure Front Door bypassed the safety validation meant to catch exactly that kind of change, triggering a global connectivity failure that lasted eight hours and twenty-four minutes and took down Azure Portal, Teams, Outlook, Xbox Live, and Azure AD along with it.

Two of the three largest cloud providers had major, public, multi-hour outages within the same ten-day window. A cyberattack caused neither. Both were caused by the ordinary failure modes resilience engineering exists to catch: an automation bug in one case. This configuration change slipped past its own safety check in the other.

Strategy One: Redundancy Across Zones and Regions

Redundancy is the most familiar resilience strategy and the easiest to get partially right: running multiple instances across availability zones so a single zone failure doesn't take the whole application down. The gap shows up when redundancy exists on paper but isn't actually distributed the way an architecture diagram implies.

A concrete recent example makes this specific rather than abstract. In May 2026, a cooling system failure in a Northern Virginia data center knocked out power to AWS racks in a single availability zone, us1-az4, for roughly seven hours. Coinbase was among the companies affected, along with FanDuel and CME Group's trading infrastructure. The detail worth sitting with: this wasn't every AWS customer in the region; it specifically hit customers running single-AZ workloads in that one zone. Multi-AZ deployments in the same region, whose traffic could fail over automatically, largely rode through the same incident without customer-facing impact.

Multi-region redundancy addresses a different failure class, the kind that hits an entire region's control plane rather than a single zone, which is exactly what happened in AWS's October 2025 incident. A few numbers worth knowing on this front:

86% of organizations report adopting a multi-cloud strategy specifically for resilience, not cost or feature access
81% of organizations say they'd face severe or critical disruption from a seven-day outage at a single cloud vendor (Cloud Security Alliance)

Nobody's outage has lasted seven days yet. The exposure is the point, not the historical maximum.

Strategy Two: Auto-Scaling and Load Balancing

Redundancy handles failure. Auto-scaling and load balancing handle load, and the two problems look similar from the outside (a service becomes unavailable) but have different causes and different fixes. A traffic spike that isn't matched by capacity produces the same customer-facing symptom as a failed server: requests time out or get dropped, without any component actually failing.

Auto-scaling groups that respond to real-time demand, paired with load balancers that automatically route traffic away from unhealthy instances, turn what would otherwise be a manual, alert-driven scramble into something the infrastructure handles on its own. The design detail that separates resilient auto-scaling from fragile auto-scaling is the health check itself:

Shallow health check: confirms the instance is running, nothing more
Deep health check: confirms the instance is actually serving requests successfully

A load balancer using only the shallow check can keep routing traffic to an instance that's technically alive but failing every request, a worse outcome than no redundancy at all, since it looks healthy on a dashboard while actively breaking for users.

Strategy Three: Continuous Monitoring and Observability

Redundancy and auto-scaling only work if something notices when they're needed. Monitoring and observability are the detection layer underneath every other strategy on this list, and the industry-wide trend here is genuinely encouraging: the Uptime Institute's tracking shows median time to recovery improving from 78 minutes in 2020 to 53 minutes in 2025, largely attributed to better monitoring and automated response replacing manual, alert-driven investigation.

The two terms get used interchangeably but answer different questions:

Monitoring tells you a threshold was crossed: CPU is at 95%, error rate spiked
Observability lets you ask why, tracing a request across services to find where it actually failed

A single monolith emitting a handful of metrics can often get by on monitoring alone. A system split across a dozen microservices, each with its own failure modes, generally can't diagnose an incident from metrics alone; it needs the tracing and log-correlation observability tooling that provides.

Strategy Four: Backup and Disaster Recovery Planning

Every strategy above reduces how often something breaks or how fast it's noticed. Backup and disaster recovery planning is about what happens when prevention and detection both fail anyway, which they eventually will. Two metrics actually define a disaster recovery plan:

RTO (Recovery Time Objective): how long recovery is allowed to take
RPO (Recovery Point Objective): how much data loss is acceptable, measured in time since the last valid backup

Both numbers are meaningless until they're tested against a real restore, not just documented in a runbook nobody's executed. A backup that's never been restored is a hypothesis, not a recovery plan. The gap between "we have backups" and "we've confirmed these backups actually restore correctly, within our stated RTO, on infrastructure that matches production" is exactly where most disaster recovery plans quietly fail the one time they're actually needed.

Strategy Five: Chaos Engineering and Resilience Testing

The four strategies above are all things a team builds and then hopes work correctly during a real incident. Chaos engineering exists to close that gap by deliberately testing failure in a controlled window, rather than waiting for production to test it involuntarily.

Tabletop exercises: discussion-based, walking through "what happens if this region goes down" as a conversation. Cheap and useful for testing the human process: who gets paged, who has authority to declare an incident, what the communication plan is. Can't catch a misconfigured health check or a bad auto-scaling threshold, since nothing actually breaks.
Fault injection: actual failure, deliberately triggered, killing an instance, blocking traffic to a specific dependency, or simulating a full availability zone failure using a tool like AWS Fault Injection Simulator or Gremlin, with a defined blast radius and an automatic stop condition if the experiment starts causing more damage than intended.

The gap fault injection catches is a specific one: the difference between what an architecture diagram claims and what the infrastructure actually does when tested.

Strategy Six: Infrastructure Governance That Keeps the Other Five Honest

The first five strategies all assume the infrastructure underneath them is accurately represented somewhere, that the redundancy in the architecture diagram matches what's actually deployed, that the backup policy applies to every resource it's supposed to, that the auto-scaling group everyone's counting on hasn't quietly drifted out of its intended configuration. That assumption breaks down constantly in real environments, and it's the strategy most resilience guides skip entirely.

Infrastructure as code is supposed to guarantee that assumption holds, since the deployed state should always match what's declared in code. In practice, IaC coverage decays: a resource is created directly via the console during an incident and never makes it back into Terraform, or a configuration is changed manually to unblock something urgent, and the change is never reconciled. Enterprises frequently discover that only 60-80% of their actual cloud footprint is codified, and the uncodified remainder is exactly where drift accumulates fastest, precisely the resources least likely to have the redundancy, backup coverage, or monitoring the other five strategies assume exist everywhere.

This is where resilience stops being purely an architecture question and becomes a continuous verification question: not "did we design this to be resilient" but "is it still actually configured that way right now, this week, after six months of incremental changes nobody tracked centrally."

How Firefly Supports Cloud Resilience in Practice

Firefly's Cloud Resilience Posture Management (CRPM) is built directly around Strategy Six's core problem: verifying that resilience assumptions still hold against live infrastructure, continuously, rather than trusting an architecture diagram that was accurate the day it was drawn.

CRPM scores an environment against built-in resiliency policies under the Governance dashboard, missing snapshot policies, S3 buckets without Object Lock, RDS clusters skipping final snapshots on deletion, the specific configuration gaps that turn a routine failure into a prolonged outage. That score updates continuously.
Cloud Asset Inventory scans continuously across AWS, Azure, GCP, and Kubernetes. Hence, a resource created outside Terraform during an incident appears tagged as Drifted or Unmanaged rather than silently existing outside every resilience assumption the team makes. Drift detection compares directly against the live provider state, not just a state file.
CAIRS (Cloud Application Infrastructure Recovery) rebuilds into a clean, isolated region or account using immutable, versioned IaC snapshots when recovery is actually needed, rather than restoring straight back into whatever caused the original failure. Every restore generates Terraform and routes it through a pull request rather than directly mutating the cloud.

For teams that want to check resilience posture without waiting for an incident to force the question, AI SRE answers questions like "which of our production applications would fail to recover cleanly right now" by cross-referencing Inventory, Governance, and Backup & DR data directly.

Where Should You Start With Cloud Resilience

Checking whether the resilience already assumed to exist actually holds against live infrastructure is a faster, more honest starting point than debating which new strategy to add next. An architecture diagram showing multi-AZ redundancy doesn't answer whether that redundancy still applies to every resource six months after it was drawn. Explore Firefly's Governance dashboard to see that gap measured against a live environment.

FAQs

What is cloud resilience?

Cloud resilience is a system's ability to keep functioning, or recover quickly and predictably, when something breaks, whether that's a failed availability zone, a bad deployment, or a provider-wide outage. It covers both staying available in the first place and recovering cleanly when that wasn't possible.

What's the difference between cloud resilience and high availability?

High availability focuses specifically on minimizing downtime through redundancy and failover. Cloud resilience is broader: it includes high availability but also covers disaster recovery, monitoring, testing, and the infrastructure governance that keeps all of those assumptions accurate over time, not just the initial architecture.

How much does downtime actually cost?

ITIC's most recent Hourly Cost of Downtime Survey found that over 90% of mid- to large enterprises report that a single hour of downtime costs more than $300,000, with 41% reporting $1 million to $5 million or more per hour. The Uptime Institute separately found that roughly one in five major outages now exceeds $1 million in total cost.

What is chaos engineering and is it worth doing?

Chaos engineering deliberately injects failure into a system within a controlled window with a defined blast radius to test whether resilience assumptions actually hold, rather than waiting for production to test them involuntarily. It catches the gap between what an architecture diagram claims and what the infrastructure actually does, which tabletop exercises and code review alone can't surface.

Why does infrastructure governance matter for resilience specifically?

Because redundancy, backups, and monitoring all depend on infrastructure remaining configured as designed, that assumption decays constantly as manual changes, incident fixes, and console-created resources accumulate outside of IaC. A resource that drifted out of its intended configuration six months ago has none of the resilience the original design assumed.

How does Firefly specifically support cloud resilience?

Firefly's CRPM continuously scores an environment against resiliency-blocking configurations; Cloud Asset Inventory and drift detection catch resources that fall outside IaC coverage before an incident finds them first, and CAIRS rebuilds into a clean, isolated environment from immutable snapshots when recovery is actually needed, with every restore routed through a reviewable pull request.