By The Guest: Julian Fischer, Founder and CEO at anynines
Legacy code is every engineering team’s nightmare. You inherit a codebase built on deprecated APIs, face the choice between massive refactoring or starting fresh, and hope you make the right call. Julian Fischer, Founder and CEO at anynines, just made that call for Cloud Foundry application management.
At KubeCon, he announced CF AppStage—a complete rewrite of Stratos UI built on the modern Cloud Controller v3 API and Backstage framework. The decision wasn’t impulsive. anynines tested the assumption internally: would rewriting from scratch be more efficient than refactoring legacy code? The answer was yes.
CF AppStage is now blazingly fast, production-ready, and available immediately for anynines license holders. This is a case study in technical decision-making when legacy infrastructure holds you back.
The Stratos UI Problem: Built on Deprecated APIs
Fischer frames the challenge clearly: “The issue with Stratos UI in the context of managing Cloud Foundry apps is that this tool has a legacy code base. It’s based on the Cloud Controller version two API of Cloud Foundry, which has been deprecated.”
This is a common problem in enterprise software. Stratos UI was built years ago when Cloud Controller v2 was the current API. It worked well for its time and became the standard interface for managing Cloud Foundry applications. But Cloud Foundry evolved. The v3 API introduced significant improvements—better performance, more granular resource models, enhanced security patterns. The v2 API was officially deprecated.
For Stratos UI, this created technical debt. The tool still works, but it’s built on APIs that Cloud Foundry maintainers no longer actively support. Every new Cloud Foundry feature that relies on v3 API capabilities can’t be fully exposed through Stratos UI. Performance optimizations in the v3 API don’t benefit Stratos users. Security enhancements remain inaccessible.
Organizations running Cloud Foundry face an uncomfortable choice: continue using aging management interfaces or undertake the painful work of modernization. Many defer the decision because both options seem expensive. Refactoring Stratos UI to use v3 APIs means touching every part of the codebase. Replacing it entirely means finding or building an alternative.
The Refactor Versus Rewrite Decision: Testing the Assumption
Fischer describes anynines’ decision process: “Internally, we’ve tested the assumption: would it be much more efficient to just rewrite that thing from scratch based on Backstage? And we did, and it turned out to be the right assumption.”
This is disciplined engineering decision-making. Rewriting from scratch is often considered engineering hubris—Joel Spolsky’s famous essay “Things You Should Never Do” argues that rewrites are almost always mistakes. Existing code, even messy code, embodies years of bug fixes, edge case handling, and hard-won knowledge. Throwing it away risks reintroducing solved problems.
But Fischer’s team didn’t make an emotional decision. They tested the assumption. They likely built a proof-of-concept using Backstage, implemented core Stratos UI functionality against the v3 API, and measured development velocity. The data showed rewriting was more efficient than refactoring.
Why? Legacy codebases accumulate architectural decisions that made sense years ago but constrain current development. Stratos UI was architected around v2 API patterns. Retrofitting v3 API support means working against those architectural assumptions. Every feature requires workarounds and compatibility layers. Progress is slow and frustrating.
Starting fresh with Backstage provided a modern foundation. Backstage is an open source platform for building developer portals, created by Spotify and now a CNCF project. It has plugin architecture, active community development, and modern frontend patterns. Building on Backstage meant anynines could focus on Cloud Foundry-specific functionality rather than rebuilding basic UI infrastructure.
CF AppStage: The Stratos UI Replacement Built for Modern Cloud Foundry
Fischer positions CF AppStage as a direct replacement: “CF AppStage is Stratos UI or Pivotal Apps Manager replacement that is built on the Cloud Controller v3 API, is blazingly fast, and it’s making good progress.”
The “blazingly fast” claim is notable. Legacy UIs often suffer performance problems because they make inefficient API calls or lack proper caching. By building directly against the v3 API from the start, CF AppStage can leverage performance optimizations that weren’t available in v2. The architecture is designed for speed rather than adapted for it.
CF AppStage also replaces Pivotal Apps Manager, which was the commercial interface VMware provided for managing Cloud Foundry applications. After Broadcom’s acquisition of VMware, many organizations are looking for alternatives to VMware-branded tooling. CF AppStage gives Cloud Foundry operators a viable option that isn’t tied to commercial platform vendors.
The “making good progress” phrasing suggests CF AppStage is production-ready but still actively evolving. anynines isn’t claiming feature parity with a decade of Stratos UI development. They’re claiming the core functionality works, performs well, and is ready for real use. Additional features will come based on user feedback and demand.
Backstage as the Foundation: Why This Framework Choice Matters
The decision to build on Backstage reveals strategic thinking beyond just solving the Stratos UI problem. Backstage isn’t a Cloud Foundry-specific tool—it’s a general framework for building internal developer portals. By adopting it, anynines positions CF AppStage within the broader developer experience ecosystem.
Organizations building internal developer platforms increasingly use Backstage as the central interface. It provides a unified view of services, documentation, CI/CD pipelines, and infrastructure. If Cloud Foundry application management is built as a Backstage plugin rather than a standalone tool, it integrates naturally into these broader platforms.
This also future-proofs the investment. If Cloud Foundry usage declines within an organization but Backstage remains the standard interface, CF AppStage functionality doesn’t become orphaned. It’s already part of the platform developers use daily. The transition from Cloud Foundry-centric workflows to Kubernetes-centric workflows can happen gradually without forcing users to learn entirely new interfaces.
For anynines, building on Backstage also means they benefit from community innovation. As Backstage evolves, CF AppStage automatically gains new capabilities—better authentication patterns, improved accessibility, enhanced visualization options. anynines doesn’t have to rebuild these foundational features.
Available Now Under anynines Data Service License: Immediate Access
Fischer emphasizes availability: “It’s also available under the anynines data service license. So if you have license credits with us, you can use that in your Cloud Foundry right away.”
This is smart go-to-market strategy. CF AppStage isn’t a separate product requiring new procurement processes. It’s included in anynines’ existing credit-based licensing model. Organizations already using anynines data services or Klutch can immediately deploy CF AppStage without additional contracts or budget approvals.
This lowers the adoption barrier dramatically. Cloud Foundry operators frustrated with Stratos UI can try CF AppStage immediately. If it works well, they migrate their teams. If they encounter issues, they provide feedback to anynines. The tight feedback loop accelerates product development and ensures CF AppStage solves real user problems rather than hypothetical ones.
The credit model also aligns economic incentives. anynines isn’t trying to maximize per-seat licensing for CF AppStage. They’re building it as part of a comprehensive Cloud Foundry modernization offering. Organizations that adopt CF AppStage become deeper users of the anynines ecosystem, consuming more credits across multiple products.
The Broader Cloud Foundry Modernization Story
CF AppStage is one piece of anynines’ larger Cloud Foundry modernization strategy. They’re helping organizations navigate the post-VMware, post-Broadcom reality where commercial Cloud Foundry support has become expensive and uncertain. Their approach isn’t to abandon Cloud Foundry but to modernize it—update aging components, integrate with modern tooling, and provide operational support that doesn’t depend on vendor relationships.
This strategy makes sense because Cloud Foundry still runs massive amounts of enterprise infrastructure. Organizations can’t simply turn it off and migrate to Kubernetes overnight. They need a path forward that preserves existing investments while modernizing incrementally. Replacing Stratos UI with CF AppStage is exactly this kind of incremental modernization—visible improvement without ripping out core platform components.
The Backstage foundation also signals where anynines sees Cloud Foundry fitting into future platform architectures. It’s not the entire platform anymore. It’s one component among many—Kubernetes clusters, data services, CI/CD pipelines—all managed through a unified interface. This multi-platform reality is what a9s Hub addresses with Klutch for data orchestration and now CF AppStage for application management.
Technical Debt and the Courage to Rewrite
Fischer’s announcement is also a lesson in managing technical debt. Legacy code doesn’t improve with age. The longer you defer modernization, the more painful it becomes. Stratos UI built on deprecated APIs will only get harder to maintain as Cloud Foundry continues evolving.
anynines made the hard decision to rewrite rather than patch. This requires courage because rewrites are risky. They consume resources, introduce new bugs, and might not deliver expected benefits. But by testing the assumption first—building proof-of-concepts, measuring development velocity, validating architectural choices—anynines de-risked the decision.
The result is a modern tool built on current APIs and frameworks. CF AppStage won’t accumulate the same technical debt as Stratos UI because it’s architecturally aligned with how Cloud Foundry works today. When Cloud Foundry introduces new features, CF AppStage can adopt them without fighting legacy architectural decisions.
For other organizations facing similar legacy code challenges, Fischer’s story provides a playbook: test the rewrite assumption with proof-of-concepts, choose modern frameworks with active communities, focus on core functionality first, and release early to gather feedback. Don’t let perfect be the enemy of good enough.
What This Means for Cloud Foundry Operators
For organizations running Cloud Foundry, CF AppStage represents a meaningful improvement in application management. They get a faster, more modern interface built on current APIs. If they’re already anynines customers, they can deploy it immediately without new licensing negotiations. If they’re not, CF AppStage becomes another reason to consider anynines’ comprehensive Cloud Foundry offerings.
The Backstage foundation also means CF AppStage fits naturally into broader internal developer platforms. Organizations don’t have to maintain separate interfaces for Cloud Foundry versus Kubernetes. Everything can live in Backstage, providing developers a single pane of glass for all platform interactions.
This is the future of Cloud Foundry operations—not isolated from modern platform engineering practices, but integrated into them. CF AppStage is anynines’ bet that Cloud Foundry has a long runway ahead, but only if it modernizes to work alongside rather than against current platform trends.
