Internal Developer Portal Blogs

In most teams, the question is no longer "Do we need an internal developer portal?" but "Do we really want to run backstage ourselves?"

Backstage proved the internal developer portal (IDP) pattern, and it works. It gives you a flexible framework, plugins, and a central place for services and docs. It also gives you a long-term commitment: owning a React/TypeScript application, managing plugins, chasing upgrades, and justifying a dedicated platform squad to keep it all usable.

That's why there are Backstage alternatives like Harness IDP and managed Backstage services. It's also why so many platform teams are taking a long time to look at them before making a decision.

Why Teams Start Searching For Backstage Alternatives

Backstage was created by Spotify to fix real problems with platform engineering, such as problems with onboarding, scattered documentation, unclear ownership, and not having clear paths for new services. There was a clear goal when Spotify made Backstage open source in 2020. The main value props are good: a software catalog, templates for new services, and a place to put all the tools you need to work together.

The problem is not the concept. It is the operating model. Backstage is a framework, not a product. If you adopt it, you are committing to:

• Running and scaling the portal as a first-class internal product.
• Owning plugin selection, security reviews, and lifecycle management.
• Maintaining a consistent UX as more teams and use cases pile in.

Once Backstage moves beyond a proof of concept, it takes a lot of engineering work to keep it reliable, secure, and up to date. Many companies don't realize how much work it takes. At the same time, platforms like Harness are showing that you don't have to build everything yourself to get good results from a portal. 

When you look at how Harness connects IDP to CI, CD, IaC Management, and AI-powered workflows, you start to see an alternate model: treat the portal as a product you adopt, then spend platform engineering energy on standards, golden paths, and self-service workflows instead of plumbing.

The Three Real Paths: Build, Buy, Or Go Hybrid

When you strip away branding, almost every Backstage alternative fits one of three patterns. The differences are in how much you own and how much you offload:

1. Build: Self-Hosted Backstage Or Fully DIY Portal

What This Actually Means

You fork or deploy OSS Backstage, install the plugins you need, and host it yourself. Or you build your own internal portal from scratch. Either way, you now own:

• The UI and UX.
• The plugin ecosystem and compatibility matrix.
• Security, upgrades, and infra.
• Roadmapping and feature decisions.

Backstage gives you the most flexibility because you can add your own custom plugins, model your internal world however you want, and connect it to any tool. If you're willing to put a lot of money into it, that freedom is very powerful.

Where It Breaks Down

In practice, that freedom has a price:

• You need a dedicated team (often several engineers) to keep the portal healthy as adoption grows.
• You own every design decision and every piece of technical debt, forever.
• Plugin sprawl becomes real, especially when different teams install different components for similar problems.
• Scaling governance, RBAC, and standards enforcement almost always requires custom code.

This path could still work. If you run a very large organization and want to make the portal a core product, you need to have strong React/TypeScript and platform skills, and you really want to be able to customize it however you want, building on Backstage is a good idea. Just remember that you are not choosing a tool; you are hiring people to work on a long-term project.

2. Hybrid: Managed Backstage

What This Actually Means

Managed Backstage providers run and host Backstage for you. You still get the framework and everything that goes with it, but you don't have to fix Kubernetes manifests at 2 a.m. or investigate upstream patch releases.

Vendor responsibilities typically include:

• Running the control plane and handling infra.
• Coordinating upgrades and security fixes.
• Creating a curated library of high-value plugins.

You get "Backstage without the server babysitting."

Where The Trade-Offs Show Up

You also inherit Backstage's structural limits:

• The data model and catalog schema still look like Backstage.
• UI and interaction patterns follow Backstage's rules, which may not fit every team's mental model.
• Deeply customized plugins or data models still require serious engineering work.

Hybrid works well if you have already standardized on Backstage concepts, want to keep the ecosystem, and simply refuse to run your own instance. If you're just starting out with IDPs and are still looking into things like golden paths, self-service workflows, and platform-managed scorecards, it might be helpful to compare hybrid Backstage to commercial IDPs that were made to be products from the start.

3. Buy: Commercial IDPs 

What This Actually Means

Commercial IDPs approach the space from the opposite angle. You do not start with a framework, you start with a product. You get a portal that ships with:

• A software catalog.
• Ownership and scorecards.
• Self-service workflows.
• RBAC and governance tools.

The main point that sets them apart is how well that portal is connected to the systems that your developers use every day. Some products act as a metadata hub, bringing together information from your current tools. Harness does things differently. The IDP is built right on top of a software delivery platform that already has CI, CD, IaC Management, Feature Flags, and more.

Why Teams Go This Route

Teams that choose commercial Backstage alternatives tend to prioritize:

• Time to value in weeks, not quarters.
• Predictable total cost of ownership instead of wandering portal roadmaps.
• Built-in governance and security rather than "we'll build RBAC later."
• A real customer success partnership and roadmap, as opposed to depending on open-source momentum.

You trade some of Backstage's absolute freedom for a more focused, maintainable platform. For most organizations, that is a win.

Open Source Backstage Vs. Commercial Backstage Alternatives: Real Trade-Offs

People often think that the difference is "Backstage is free; commercial IDPs are expensive." In reality, the choice is "Where do you want to spend?"

When you use open source, you save money but lose engineering capacity. With commercial IDPs like Harness, you do the opposite: you pay to keep developers focused on the platform and save time. A platform's main purpose is to serve the teams that build on it. Who does the hard work depends on whether you build or buy.

This is how it works in practice:

Backstage is a solid choice if you explicitly want to own design, UX, and technical debt. Just be honest about how much that will cost over the next three to five years.

Commercial IDPs like Harness come with pre-made catalogs, scorecards, workflows, and governance that show you the best ways to do things. In short, it's ready to use right away. You get faster rollout of golden paths, self-service workflows, and environment management, as well as predictable roadmaps and vendor support.

The real question is what you want your platform team to do: shipping features in your portal framework, or defining and evolving the standards that drive better software delivery.

Where Commercial IDPs Fit Among Backstage Alternatives

When compared to other Backstage options, Harness IDP is best understood as a platform-based choice rather than a separate portal. It runs on Backstage where it makes sense (for example, to use the plugin ecosystem), but it is packaged as a curated product that sits on top of the Harness Software Delivery Platform as a whole.

There are a few design principles stand out:

1. Start from a product, not a bare framework. Backstage is intentionally a framework. Harness IDP is shipped as a product. Teams can start using the software right away because it already has a software catalog, scorecards, self-service workflows, RBAC, and policy-as-code. You add to it and shape it, but you don't put the basics together so that anyone can use it.
2. Make governance a first-class concern. Harness bakes environment-aware RBAC, policy-as-code (OPA), approvals, freeze windows, audit trails, and standards enforcement into the platform. Instead of adding custom plugins later, governance and security are built in from the start.
3. Prioritize actionability over passive visibility. Harness IDP does not stop at showing data. Because it runs directly over Harness CI, CD, IaC Management, Feature Flags, and related capabilities, it can drive workflows: spinning up new services from golden paths, managing environments, shutting down ephemeral resources, and wiring in repeatable self-service runbooks. The result is a portal that behaves more like an operational control plane.
4. Use AI where it can safely take action. The Harness Knowledge Agent is based on real delivery data, such as services, pipelines, environments, and scorecards. It can answer questions about who owns what and what happened in the past. It can also suggest or start safe actions under governance controls. That is not the same as AI features that only give a brief overview of catalog entries.

When you think about Backstage alternatives in terms of "How much of this work do we want to own?" and "Should our portal be a UI or a control plane?" Harness naturally fits into the group that sees the IDP as part of a connected delivery platform rather than as a separate piece of infrastructure.

Migration Realities: Moving Off Backstage Is Not A Free Undo Button

A lot of teams say, "We'll start with Backstage, and if it gets too hard, we'll move to something else." That sounds safe on paper. In production, moving from Backstage gets harder over time.

Common points where things go wrong include:

1. Custom plugins and extensions: One of Backstage's best features is its plugin ecosystem. It also keeps teams together. Over time, you build up a lot of custom plugins, scaffolder actions, and UI panels that are closely linked to your internal systems. Moving those to a different portal often means rewriting them completely, checking for compatibility, and sometimes even refactoring them.‍
2. Catalog complexity: Backstage catalogs tend to grow into hundreds or thousands of catalog-info.yaml files, custom entity kinds, and annotations. Moving this to a commercial IDP means putting that structure into the new system's data model while keeping ownership, relationships, and rules for governance. Trust in the new portal is directly affected by an incomplete migration here.‍
3. Golden path and scaffolder differences: Your existing scaffolder templates are wired into specific CI/CD tools and habits. Moving them to Harness IDP usually means changing the templates so that they run Harness pipelines, Harness environments, and IaC workflows instead of jobs from outside. That refactor is usually worth it, but it is still a lot of work.‍
4. Developer UX and "who moved my cheese?": Developers get used to Backstage's interaction patterns and custom dashboards. Changing to a new IDP always causes problems with adoption. The only way to avoid a revolt is to run portals at the same time and slowly roll out new golden paths.‍
5. Parallel system complexity: Running Backstage next to a new portal uses up a lot of platform bandwidth and makes things confusing for users if timelines aren't clear. Commercial vendors like Harness can help with this by providing migration tools and hands-on help, but you still need to plan for a migration window, not just flipping a switch.

The point isn't "never choose Backstage." The point is that if you do, you should think of it as a strategic choice, not an experiment you can easily undo in a year.

How To Evaluate Backstage Alternatives With A Clear Head

Whether you are comparing Backstage alone, Backstage in a managed form, or commercial platforms like Harness, use a lens that goes beyond feature checklists. These seven questions will help you cut through the noise.

1. Time to first value‍
   
   • Can you deliver a useful portal (catalog plus a couple of golden paths) in weeks?
   • Who owns upgrades, patches, and production reliability?‍
2. Total cost of ownership‍
   
   • How many engineers will this realistically consume over 3 years?
     
   • Is that time spent on differentiated work or reinvention?‍
3. Governance and security maturity‍
   
   • Do you get RBAC, policy-as-code, approvals, and audit trails out of the box?
   • Can you express environment-aware rules without writing custom code for every edge case?‍
4. Data model and extensibility‍
   
   • How hard is it to model services, infra, teams, and dependencies in a way that reflects reality?
   • Can you evolve the model as your architecture and org change?‍
5. Automation and actionability‍
   
   • Does the portal only aggregate data, or can it drive workflows like service creation, environment provisioning, and deployment rollbacks?
   • How directly does it connect to your CI/CD, IaC, and incident tooling?‍
6. AI and "agentic" workflows‍
   
   • Is AI just summarizing what you already see on dashboards, or can it actually update environments, run pipelines, and enforce policies safely?
   • How well grounded is that AI in your real delivery platform versus a generic data lake?‍
7. Exit strategy and lock-in‍
   
   • If you have to move in three to five years, how portable are your catalogs, templates, and automation?
   • Are you comfortable tying your IDP to a broader platform (like Harness) to gain deeper integration and efficiency?

If a solution cannot give you concrete answers here, it is not the right Backstage alternative for you.

Why Harness IDP Belongs On Your Shortlist

Choosing among Backstage alternatives comes down to one question: what kind of work do you want your platform team to own?

Open source Backstage gives you maximum flexibility and maximum responsibility. Managed Backstage reduces ops burden but keeps you within Backstage's conventions. Commercial IDPs like Harness narrow the surface area you maintain and connect your portal directly to CI/CD, environments, and governance.

If you want fast time to value, built-in governance, and a portal that acts rather than just displays, connect with Harness.

At Harness, our mission has always been simple but ambitious: to enable every software engineering team in the world to deliver code reliably, efficiently, and quickly to their users, just like the world’s leading tech companies. As AI coding assistants accelerate application teams' ability to change code, traditional delivery processes are becoming a bottleneck, making DevOps excellence more important than ever. Today, the industry validated the critical nature of this work with a resounding vote of confidence.

We are incredibly honored to announce that TechStrong TV and DevOps.com have recognized Harness with three prestigious DevOps Dozen Awards.

While we are grateful for every accolade, this year’s wins are particularly special. They don’t just recognize individual features; they validate our complete vision for the future of software delivery, one that is platform-centric, AI-native, and developer-focused.

Here is a look at the categories Harness took home this year.

1. Best End-to-End DevOps Platform

This is the big one. Winning Best End-to-End DevOps Platform is a testament to the shift we are seeing across the entire market. Organizations are moving away from fragmented, brittle toolchains of "point solutions" and rigid all-or-nothing platforms toward modular platforms that meet them where they are.

Modern engineering teams need more than just CI or CD in isolation. They need a comprehensive platform that offers a best-in-class modular approach. Whether it is accelerating builds with Continuous Integration, governing deployments with Continuous Delivery, or optimizing spend with Cloud Cost Management, the real magic happens when these modules work together.

This award reinforces that the Harness Platform—with its unified pipeline orchestration, automated governance, and shared intelligence—is the standard for end-to-end software delivery.

2. Best Platform Engineering Solution: IDP (Back-to-Back Wins!)

For the second year in a row, Harness has been named the Best Platform Engineering Solution.

Platform Engineering is no longer a "nice to have." It is a necessity for scaling innovation. The Harness Internal Developer Portal (IDP) is designed to solve the critical challenge of developer cognitive load. By providing golden paths and self-service capabilities with automated guardrails, we allow developers to focus on what they love: creating new capabilities.

Winning this award two years running proves that our commitment to the developer experience is resonating deeply with the industry.

3. DevOps Industry Leader of the Year: Jyoti Bansal

Finally, we are thrilled to see our CEO and Co-founder, Jyoti Bansal, recognized as DevOps Industry Leader of the Year.

From founding AppDynamics to leading Harness, Jyoti has spent his career obsessed with solving the hardest problems in software. His vision for AI for Everything After Code is driving the industry forward, moving us from simple automation to true intelligent orchestration. This award recognizes not only his leadership at Harness but also his contributions to the DevOps community as a whole.

Forward Momentum

These awards from DevOps.com add to a year of incredible momentum, joining recent recognition from major analyst firms like Gartner and Forrester.

But we aren't slowing down. With our continued investment in AI agents, automated governance, and expanding our module ecosystem, we are just getting started.

To our customers, partners, and the Harness team: Thank you. These awards belong to you.

‍

A developer once told me, half-joking and half-frustrated, “I spend more time waiting than coding.” It wasn’t the dramatic kind of waiting, like an hour-long debugging session or a blocked deployment at midnight. It was the everyday waiting that creeps into a team’s workflow. Waiting for a repository to be created. Waiting for infrastructure. Waiting for a ticket to move from “To Do” to “In Progress.” Waiting for someone to approve a routine task.

Image description: a stick-person cartoon of developers playing swords. The caption reads: “The #1 programmer excuse for legitimately slacking off: my code’s compiling.” Source: https://xkcd.com/303/

None of these delays are catastrophic on their own, but they accumulate. Days turn into weeks. Friction becomes normal. Productivity quietly drops. And everyone just accepts it because “that’s how things work.”

This slow, ticket-driven model is what many teams refer to as Ticket Ops. It is one of the biggest obstacles to engineering velocity, but it often goes unnoticed because it’s simply the way things have always been.

But platform engineering teams are starting to ask a different question: What if developers didn’t have to wait at all?

That idea—a world where developers can move quickly without depending on a chain of manual steps—is the foundation of developer self-service. And inside the Harness Internal Developer Portal (IDP), that promise becomes real through Workflows.

Workflows aren’t just buttons or forms. They’re guided, automated pathways that help engineers onboard services, launch environments, and complete Day-2 tasks with confidence. They transform the daily experience of building software, reducing developer friction and helping organizations accelerate software delivery in a sustainable, scalable way.

The Real Cost of Waiting

To understand why Workflows matter, it helps to picture the start of a typical engineering task.

Imagine a developer preparing to build a new microservice. Before they write a single line of code, there’s a list of tasks to complete. They need a repo. They need pipelines. They need security baselines. They need the service registered in the catalog. They might need a Jira or ServiceNow ticket. They need to understand compliance requirements and infrastructure choices.

It’s not unusual for developers to spend several days just assembling the basics.

And even when companies use templates or documentation, reality rarely matches the ideal. Docs drift out of date. Scripts behave differently on different machines. Best practices live in people’s heads. Engineers copy something that “worked last time,” even if it isn’t correct anymore.

This is where Workflows step in. Instead of asking developers to manually navigate dozens of decisions and systems, Harness IDP gives them a clear, consistent way forward.

A Simpler Workflow

Imagine that same developer opening the Internal Developer Portal.

Instead of tackling a pile of steps, they see a simple entry point: Create a new service.
They click. They answer a few straightforward questions. Then they run the workflow.

What happens next feels almost magical:

A repository appears with a secure boilerplate. Pipelines are created automatically. Scorecards evaluate whether the service meets standards. The service registers itself in the catalog. Tickets are opened if required. Notifications go out. An environment may even be created so the developer can test changes immediately.

The developer gets a working service in minutes.
The platform team knows it was built the right way.
And the company gains a golden path that works the same every time.

This is the heart of Harness IDP Workflows: transforming complex, multistep engineering efforts into a guided, repeatable flow that improves developer productivity and streamlines the developer workflow.

(If you'd like to try this type of onboarding workflow, you can follow this tutorial.)

What’s Inside a Workflow

Although the developer experience is simple, the underlying structure is powerful. Each workflow is defined in a YAML file stored in Git, typically called workflow.yaml. It contains three essential parts.

The first part defines the inputs. These are the fields the developer fills in when starting the workflow. The second part describes the backend actions that run behind the scenes—everything from provisioning infrastructure to running pipelines or creating tickets. The third part outlines the outputs, such as links to environments, service URLs, or test results.

Because everything lives in Git, platform teams can review changes, maintain version control, and collaborate the same way they would for code. And when they are ready, they register the workflow inside Harness IDP so it becomes available for everyone.

If you want to explore the full YAML model and configuration options, check out our documentation. And, you can also customize how Workflows appear in the portal.

Golden Paths That Developers Actually Want To Use

The term “golden path” gets used a lot in platform engineering. In many organizations, it refers to a recommended approach documented somewhere in Confluence or Notion. But documentation alone doesn’t guarantee consistency. People interpret instructions differently. They skip steps. They fall back on what they already know.

Harness IDP turns golden paths into the way things actually get done. Because Workflows are automated and centrally defined, every developer follows the same standards without needing to memorize anything. Security guidelines, IaC best practices, compliance rules, and architectural patterns are all baked into the workflow itself.

Developers get a smooth, intuitive experience.
Platform teams get consistency and governance.
Leaders get confidence that the system is operating safely.

This shift is one of the biggest reasons companies adopt an IDP. 

Beyond Onboarding: Workflows for the Entire SDLC

Service creation is only one example of where Workflows shine. Companies also use them for operational tasks like restarting services, running scripts, creating feature environments, performing database maintenance, or handling access requests.

A workflow might deploy Terraform to provision infrastructure, call an API to update a SaaS system, or notify teams in Slack. Another workflow might help testers spin up preview environments whenever a pull request is opened.

These flows often replace a long history of manual steps that used to depend on one or two specialists. Instead of being bottlenecks, those specialists become the people who automate the workflow once, then support every developer who uses it.

This is how Workflows help organizations reduce developer friction and accelerate software delivery at scale.

Preparing for Environment Management

One of the most exciting areas where Workflows are becoming essential is environment creation. Developers often wait days for a new environment, especially in companies with heavy compliance requirements or limited infrastructure resources.

Beginning in January, Harness will introduce Environment Management, which extends self-service into the world of environments. With EM, developers will be able to spin up full-stack environments on demand, generate preview environments for every pull request, and automatically clean them up to control costs.

Workflows serve as the perfect front door for this capability. They guide developers through the process, enforce policy, trigger the right automation, and provide consistent output. Environment Management will handle the heavy lifting behind the scenes.

Self-service infrastructure becomes a natural extension of the platform, rather than a new system developers must learn.

Moving Toward a Better Developer Experience

Every engineering organization wants the same outcome. They want developers to move quickly, teams to follow best practices, and governance without slowing anyone down.

Harness IDP Workflows make this balance possible. They simplify the everyday experience of building software while giving developers intuitive, reliable paths to get work done. They help platform engineering teams scale their expertise without becoming blockers. And they help companies create sustainable, intelligent patterns that improve engineering health over time.

‍

Learn more: What Is a Developer Platform

Joining a new engineering team can be exciting, but it can also be overwhelming. You spend the first few days figuring out what each service does, where documentation lives, and who owns what. Even experienced engineers lose time switching between tools, looking for context, and waiting on answers.

Internal Developer Portals (IDPs) were designed to fix that problem. They centralize information about services, documentation, environments, and workflows so developers can work from one place.

The challenge is that most portals stop there. They display data but don’t help developers act on it. That’s where the Harness IDP Knowledge Agent comes in.

The Knowledge Agent lives inside the Harness IDP and serves as an AI-powered teammate. It helps developers find the information they need, understand how systems work, and take action faster. You can ask questions like, “Who owns the authentication service?” or “How can I improve my score?” and get relevant, trustworthy answers in seconds.

Why This Matters Now

The Harness & InfoQ webinar, Architecting the AI-Powered IDP, explored how developer time is really spent today. Research from Gartner shows that only about 30-40% of engineering time goes toward writing code. The rest, nearly 70%, is spent testing, securing, deploying, and maintaining systems.

That imbalance has real costs. Manual approvals, disconnected tools, and outdated scripts make software delivery slower and more expensive. Developers end up managing complexity instead of building products.

AI coding assistants promise efficiency, but they’re also widening the gap. According to the 2025 DORA State of AI-Assisted Software Development Report, AI improves individual productivity by 19%. However, organizational throughput improves only 3%, and delivery stability actually drops 9%.

Basically, this shows that teams are producing more code than ever, but delivery systems haven’t evolved to handle the extra load. The result is a growing delivery bottleneck, with more pipelines to maintain, more configurations to fix, and more friction across the software lifecycle.

Platform Quality is the Multiplier

The same DORA report points to a clear solution. Teams with strong, automated platforms gain both speed and stability from AI. Teams with scattered tools and manual workflows see the opposite, and AI magnifies inefficiency instead of solving it.

Harness research confirms this trend. Companies with mature continuous delivery practices are twice as likely to report faster release cadences when using AI. The takeaway is simple: platform quality determines whether AI helps or hurts.

A strong platform, built on reusable pipelines, consistent templates, and solid governance, is what allows AI to deliver real business value. That’s exactly what the Harness IDP Knowledge Agent helps teams achieve.

What the Knowledge Agent Does

The Knowledge Agent acts as the voice of your platform. It understands your services, pipelines, environments, and scorecards, and it uses that context to help you make faster, better decisions.

Ask about a service, and it tells you what it does, who owns it, when it was last deployed, and how it’s performing. Ask how to raise your service score, and it recommends specific steps based on your team’s best practices.

Instead of switching between dashboards, tools, and tickets, developers can ask questions right in the portal and get instant, actionable answers. It’s like having an expert teammate available whenever you need one.

How it Works

The Knowledge Agent is powered by Harness AI and built on a software delivery knowledge graph, which is a connected data layer that links information from across your engineering ecosystem.

The graph brings together build data, deployment events, test results, security scans, cloud cost reports, and monitoring insights. This context allows the AI to understand relationships between systems and services rather than pulling information in isolation.

Ask, “Where are the docs for this service?” and it searches internal wikis, TechDocs, README files, and Harness IDP documentation to find the most relevant information.

Ask, “Create a new Kubernetes environment in AWS,” and it identifies the right workflow, fills in parameters, and executes it automatically.

This combination of intelligence and automation transforms the Harness IDP from a static catalog into a dynamic platform that understands your organization and helps it operate more efficiently.

What Makes it Different

Many AI tools can summarize text or surface data, but the Harness Knowledge Agent is built directly into the Harness platform. That means it operates on live, trusted data from your services, pipelines, and environments.

It also respects your security and access controls. Developers see only what they’re authorized to view, and every answer includes transparent reasoning so teams understand how conclusions were reached.

This balance of accuracy, visibility, and explainability builds confidence. It’s not just an assistant, it’s a reliable partner that helps teams move faster with control and consistency.

From Dashboards to Intelligent Platforms

Developer portals typically evolve through three stages:

1. Static portals help teams find information.
2. Automated portals enable workflows and self-service actions.
3. Intelligent portals understand intent and complete tasks automatically.

The Knowledge Agent powers that final stage. It connects a knowledge graph, AI-driven workflows, and autonomous delivery into one intelligent interface.

With it, developers can ask for a new service with a database, and the portal handles everything, like provisioning infrastructure, configuring pipelines, applying governance, and verifying deployment health.

This evolution transforms a portal from a reference point into an active engine that drives real work.

A Practical Example

Imagine you’re new to a team and need to learn about the “authentication-service.” You ask the Knowledge Agent to explain it. It shows what the service does, who owns it, when it was last deployed, and its performance score.

Next, you ask how to improve reliability. The Agent reviews your scorecards and suggests adding monitoring, improving test coverage, and adjusting deployment approvals.

Finally, you ask it to start the workflow for monitoring. It executes the right pipeline, provisions the necessary resources, and reports success.

A process that might have taken hours now happens in minutes, without switching tools or asking for help.

Why it Matters

AI has changed how teams build software, but it hasn’t changed how they deliver it. Code creation is faster, yet delivery processes remain slow and fragmented.

Intelligent IDPs close that gap by connecting systems, surfacing insights, and turning context into action. They bridge development and delivery, reducing manual steps and helping teams ship faster and with confidence.

The Harness Knowledge Agent is the next step in that journey. It combines the power of automation with the intelligence of AI to make developer platforms more proactive, transparent, and efficient.

For developers, that means fewer roadblocks and faster onboarding. For platform teams, it means better governance and a scalable model for supporting the organization. For engineering leaders, it means seeing real ROI from AI investments.

Getting Started

The Harness Knowledge Agent is available now in Harness IDP for anyone who wants to try it.

If you already use Harness IDP, contact your account team to enable it. If not, you can request a demo to see how it works in action.

And to learn more about how platform engineering and AI come together, read Platform Engineering: Beyond the Trough of Disillusionment and Industry Reports Agree: DevOps is the Key to Unlocking AI’s Potential.

Harness is helping teams build the next generation of intelligent developer portals that are powered by AI, designed for scale, and ready for real-world engineering challenges. The Knowledge Agent is a first step in that evolution.

The Reality Check We Needed

If you've been following industry conversations recently, you've likely seen Mark O'Neill's pointed LinkedIn post referencing Jennifer Riggins' article in The New Stack, suggesting platform engineering is headed for Gartner's notorious "Trough of Disillusionment." The Gartner Hype Cycle graphic prominently displays platform engineering perched at that precarious precipice, with a big red arrow pointing downward.

‍

As someone who's been in the trenches with teams adopting platform engineering practices, I can't entirely disagree with this assessment—but I believe it represents a necessary and healthy evolution rather than a death knell.

Why Platform Engineering Is Facing This Moment

The challenges highlighted by industry experts resonate with what we're seeing across organizations:

1. Measurement disconnects: Organizations struggle to demonstrate ROI and business impact, focusing instead on adoption metrics like "number of code-completion suggestions accepted" rather than business outcomes.
2. The "build your own" trap: As Paula Kennedy from Syntasso noted, "Engineers are always going to engineer." This DIY tendency leads to unnecessary reinvention, fragmentation, and ultimately, cognitive load—ironically, the very thing platform engineering aims to reduce.
3. Adoption hurdles: Platform teams build solutions that developers don't want or need, creating sophisticated tools that sit unused while developers find workarounds.

These challenges aren't symptoms of a failing concept—they're growing pains of a maturing practice.

From Platform-as-Technology to Platform-as-Product

What separates successful platform initiatives from those heading toward disillusionment? In our experience working with hundreds of engineering organizations at Harness, the answer lies in the mindset shift from platform-as-technology to platform-as-product.

This shift requires three fundamental changes:

1. Measure What Matters to the Business

ROI calculations for platform engineering shouldn't be rocket science. When we work with customers implementing Harness Platform, we focus on concrete metrics that translate directly to business impact:

• Developer time reclaimed: How many hours previously spent on pipeline maintenance, deployment orchestration, and infrastructure provisioning are now redirected to feature development?
• Time-to-production acceleration: How much faster can teams deliver value from commit to production?
• Reliability and security improvements: How have error rates, rollbacks, and incident frequency changed since implementing platform capabilities?

These metrics create a clear line between platform adoption and business outcomes, making the value proposition obvious to leadership.

Industry standard metrics like DORA and SPACE can also provide good framework for what to measure. In both cases, you are generally not measuing direct business impact but leading indicators of business impact. Platform teams need to have executive buy-in before measuring that this leap from leading indicator to business impact is going to hit the mark for the people approving budgets.

2. Embrace Composability Over Building Everything

The "build versus buy" debate misses the point entirely. The most successful platform teams we work with have embraced composability—thoughtfully selecting best-of-breed tools and integrating them into a coherent developer experience.

Harness Platform was designed with this reality in mind. Rather than forcing teams to build everything from scratch or adopt a monolithic solution, our modular approach allows teams to:

• Start with their highest-value pain points (CI, CD, feature flags, etc.)
• Integrate seamlessly with existing investments
• Expand platform capabilities as needs evolve

This approach dramatically reduces time-to-value while still providing the flexibility engineers crave.

3. Design for Developer Delight, Not Just Adoption

One of the most revealing statements from the panel discussion was Leena Mooneeram's observation: "We're incredibly lucky. We work in the same company as our customers."

Yet many platform teams fail to leverage this proximity advantage. They build platforms in isolation, then wonder why adoption lags. Platform teams fall into one of the classic traps those of us who build tools for engineers are tempted with - "I'm a developer, I know what developers want." Famous last words. Do the hard work of spending time with your teams and seeing what they really need from your platform.

The most successful platform initiatives treat internal developers as true customers:

• Conduct user research to understand pain points
• Create clear documentation and self-service workflows
• Build feedback loops that drive continuous improvement
• Focus on developer experience as a first-class concern

Beyond the Trough: The Platform Engineering Renaissance

Every transformative movement in software engineering has faced its moment of disillusionment. DevOps experienced the same trajectory before emerging as an established, mainstream practice.

At Harness, we believe platform engineering is following this same pattern. The trough represents a necessary correction—a moment for the industry to move beyond hype and establish sustainable practices.

As organizations recalibrate their approach, we're already seeing the emergence of platform engineering 2.0:

• Platform teams with product management disciplines
• Clear business outcome measurements
• Composable architectures that balance flexibility with standardization
• Developer experience as a core design principle

Accelerating Through the Trough

For organizations navigating this transition, Harness offers a proven path forward. Our platform approach enables teams to:

1. Start where you are: No rip-and-replace required. Harness integrates with your existing tools while providing a path to modernization.
2. Deliver immediate value: Pre-built capabilities for CI/CD, feature flags, cloud cost management, and security mean you can show value in days, not months.
3. Scale with confidence: As your platform strategy matures, Harness grows with you, providing the governance and security capabilities enterprise organizations demand.

Conclusion: The Future Belongs to Those Who Build Experience

Yes, platform engineering is likely entering the trough of disillusionment. But this moment of correction is setting the stage for something more valuable and sustainable. We have done the early trailblazing and found that platform engineering really works. The success stories are too plentiful to ignore. However, we have also seen enough stumbles that we are learning to be a bit more careful and disciplined in our approach. We know where the pitfalls are. What a great time time.

By focusing on business outcomes, embracing composability, and truly centering developer experience, platform engineering will emerge from this trough stronger and more impactful than ever.

The organizations that use this moment as an opportunity to refine their approach—rather than abandoning their platform efforts—will be the ones who realize the true promise of platform engineering: delivering business value at the speed of software.

Spreadsheets vs IDP Scorecards for Service Health & Initiative Tracking

As organizations increasingly adopt microservices and DevOps practices, managing the health of services and tracking engineering initiatives has become a crucial challenge. While spreadsheets have long been the go-to tool for tracking and monitoring, their limitations become glaring as teams scale and the complexity of systems grows. Enter scorecards in Internal Developer Portals (IDPs)—a powerful alternative that revolutionizes how service health and initiatives are monitored.

Here’s why you should consider scorecards in your IDP instead of sticking with spreadsheets:

Centralized Visibility for Distributed Teams

In modern engineering environments, multiple teams often own various services. Scorecards in an IDP provide centralized and consistent visibility into service health, making it easy for every team member to see relevant metrics and statuses.

Spreadsheets, on the other hand, often get siloed, requiring manual sharing and updates. With an IDP, you ensure that every team operates from the same source of truth without the overhead of maintaining shared links and permissions.

Real-Time Updates vs. Stale Data

Scorecards are often integrated directly with monitoring tools, CI/CD pipelines, and incident management systems. This ensures real-time updates, reflecting the current health of your services and progress on initiatives.

In contrast, spreadsheets are static and rely on manual updates, making them prone to delays, inaccuracies, and inconsistencies. A stale spreadsheet can lead to poor decision-making during critical incidents.

Automation Eliminates Human Error

Scorecards leverage automation to populate data, track progress, and highlight anomalies. This reduces the risk of human error, such as incorrect data entry or forgetting to update a field—common pitfalls with spreadsheets.

For instance, a scorecard can automatically display the uptime of a service or the percentage completion of an initiative based on real-time inputs from your tools, freeing engineers to focus on solving problems rather than updating records.

Enhanced Collaboration and Contextual Insights

Scorecards in an IDP provide a collaborative environment, allowing teams to add comments, links, or notes alongside metrics. They also enable drill-down capabilities for context—like linking directly to monitoring dashboards or incident logs.

Spreadsheets are limited in this regard. Adding contextual information is cumbersome, and navigating large, complex spreadsheets can become a frustrating experience for teams.

Customizable Metrics and Dashboards

IDP scorecards can be tailored to display metrics that matter most to your organization, such as service-level objectives (SLOs), deployment frequency, or incident resolution times. They often allow customizable dashboards, letting teams focus on their priorities.

Spreadsheets lack dynamic visualization capabilities, requiring manual effort to create charts or dashboards that may still fall short in conveying actionable insights.

Scalability and Integration

As organizations grow, the number of services and metrics they need to track increases exponentially. Scorecards scale seamlessly with your IDP, integrating with existing tools like Harness, Kubernetes, Jenkins, Datadog, or PagerDuty.

Spreadsheets struggle with scalability. Managing hundreds of rows and columns across multiple sheets can lead to performance issues and confusion, especially as teams change or expand.

Actionable Insights Through Trends

Modern IDPs with automated scorecards can help show when metrics breach thresholds or when initiatives fall behind. They can help to surface trends and historical data to guide long-term decision-making.

While spreadsheets can store historical data, identifying trends can require manual intervention or complex scripts that are difficult to maintain.

‍

Developer Experience and Efficiency

Scorecards enhance developer experience by providing a one-stop shop for metrics, insights, and action items within the same platform they use for other engineering tasks. This reduces context-switching and improves efficiency.

Spreadsheets, being external tools, require developers to toggle between platforms, disrupting their workflow and reducing productivity.

Conclusion: Elevate Your Service Health Tracking with IDP Scorecards

Spreadsheets served their purpose in the past, but as engineering teams grow and systems become more complex, their limitations become a bottleneck. Scorecards in an Internal Developer Portal offer a scalable, real-time, and collaborative solution tailored to the needs of modern software teams.

By adopting scorecards, you can empower your teams to focus on building and maintaining resilient systems while staying aligned on strategic initiatives. Ditch the spreadsheets and embrace the future of service health tracking—your developers (and your bottom line) will thank you.

‍

To see a brief video about Scorecards in Harness IDP, Click Here: YouTube !

Read the docs or Harness IDP here: Internal Developer Portal !

Ready to take your service health tracking to the next level? Click Here to explore how Harness Internal Developer Portal with scorecards can streamline your operations!

Request a demo

‍

‍

Evaluating Internal Developer Portals: A Comprehensive Guide

With the rise of complex, distributed software architectures and the shift toward faster, more reliable releases, internal developer portals (IDPs) have become invaluable. These portals centralize tools, services, documentation, and processes, improving productivity, standardization, and development velocity across teams. However, not all IDPs are created equal, and choosing or optimizing the right one requires a strategic approach. Here’s a guide on how to effectively evaluate an internal developer portal to ensure it meets your organization’s needs.

1. Define Your Goals and Objectives

Before you dive into the specifics, take time to outline why your organization needs an internal developer portal. Some common goals might include:

• Reducing onboarding time for new developers
• Increasing the speed of feature delivery
• Enhancing developer experience (DX)
• Centralizing tools, documentation, and best practices
• Improving communication across teams

Once you have a list of clear goals, create specific criteria based on these needs. For instance, if developer onboarding is a primary focus, your IDP should emphasize accessible documentation, easy-to-navigate interfaces, and self-service functionalities.

2. Usability and Developer Experience

A key aspect of any successful IDP is its usability and the experience it provides developers. Here are some factors to consider:

• Intuitive Interface: A clean, user-friendly interface can dramatically reduce friction, making it easier for developers to find resources, documentation, and tools.
• Personalization and Customization: Look for features that allow users to personalize their view, bookmark frequently used resources, and adjust settings according to their workflow.
• Documentation and Self-Service: Developers should be able to find what they need without external help. The portal should feature comprehensive, searchable, and easily accessible documentation and resources.

An effective way to measure usability is by conducting usability tests or gathering feedback from developers during trial periods. Tracking usage metrics such as page visits, search queries, and navigation patterns can also offer insight into the portal’s intuitiveness and accessibility.

3. Integration with Existing Tooling

One of the primary functions of an IDP is to bring together the tools, services, and workflows developers need. Therefore, evaluate the portal's integration capabilities carefully:

• API and Plugin Support: Check for compatibility with your organization’s core tools, from version control systems like GitHub or GitLab to CI/CD pipelines and monitoring tools.
• Authentication and Permissions: Does the portal support Single Sign-On (SSO) or other authentication protocols like OAuth? Consider how it handles permissions to ensure secure and appropriate access to resources.
• Modular Extensions: Look for the ability to add plugins or extensions so that as your toolchain evolves, your portal can adapt to meet new requirements.

A well-integrated IDP reduces the need to switch between multiple tools, helping developers stay in their flow and increasing overall productivity.

4. Support for Self-Service Infrastructure

Empowering developers to manage and provision resources themselves can significantly reduce dependencies on operations teams. Evaluate whether the IDP provides:

• Automated Provisioning: Can developers provision environments or resources directly from the portal? A robust self-service model streamlines development by allowing developers to spin up or tear down environments as needed.
• Infrastructure as Code (IaC) Support: Many organizations use IaC tools like Terraform or CloudFormation. An IDP should support these tools, enabling developers to deploy infrastructure changes through the portal itself.
• Security and Compliance Checks: Self-service can pose security risks if not managed properly. Look for portals that allow automated compliance and security checks as part of their self-service offerings.

5. Search and Discoverability

IDPs centralize a lot of information, from documentation and code repositories to operational dashboards. To prevent information overload, the portal must prioritize effective search and discoverability:

• Powerful Search Functionality: Evaluate the search features. An effective IDP should offer intelligent search capabilities, ideally with autocomplete, filters, and contextual results to help developers quickly find what they need.
• Tags and Metadata: Adding tags, metadata, or labels can enhance discoverability, especially in larger organizations where teams might use different terminologies.
• Documentation Management: If documentation is scattered across multiple teams and formats, your IDP should centralize it in an organized, easily navigable structure.

6. Observability and Metrics

Tracking the impact and usage of an IDP is essential for continuous improvement. Look for portals that provide built-in analytics to assess engagement, identify bottlenecks, and monitor performance:

• Usage Metrics: Metrics like page views, active users, time on page, and search terms provide insight into how developers interact with the portal.
• Operational Metrics: Does the IDP offer insights into CI/CD success rates, deployment frequency, or lead time for changes? These metrics can indicate where developers are experiencing friction in the workflow.
• Feedback Mechanism: A feedback loop allows developers to report issues or request features. This could be as simple as a feedback form or as complex as a dedicated feedback portal.

This data helps you measure whether the portal meets its intended goals and provides a basis for iterative improvements.

7. Scalability and Performance

Consider your organization’s growth trajectory and assess whether the IDP can scale accordingly. Important factors to evaluate include:

• Concurrent User Support: As your organization grows, so will the number of users. Can the portal support a large number of concurrent users without performance degradation?
• Response Times: Page load times and search speeds are critical. A slow portal can negatively impact developer productivity and adoption.
• Adaptability for New Tools and Workflows: Ensure the portal’s architecture supports modular upgrades and future expansion so it can continue to meet your evolving needs.

8. Security and Compliance

Since an IDP often integrates with various internal systems, security should be a priority. Consider these factors:

• Access Controls: Role-based access controls (RBAC) or attribute-based access controls (ABAC) are essential for managing who can see and access specific tools and documentation.
• Audit Logging: The portal should keep logs of user activity, which can be essential for compliance and troubleshooting.
• Data Encryption and Compliance Standards: Check if the portal complies with security standards like SOC 2, ISO 27001, or HIPAA, especially if it stores or manages sensitive information.

Final Thoughts: Prioritizing Continuous Improvement

Evaluating an internal developer portal is not a one-time task. After the initial setup, it’s crucial to establish a process for continuous improvement based on developer feedback, usage data, and evolving organizational needs. By regularly revisiting your criteria and adjusting as necessary, you can ensure that your IDP continues to enhance productivity, standardize processes, and empower developers to do their best work.

An internal developer portal is an investment in your developer experience, but with thoughtful evaluation and ongoing refinement, it can transform how your teams build and deliver software.

‍

For more information about Harness IDP, click Harness IDP here

Read the docs for Harness IDP

Sign up to get a demo of the Harness IDP 

Request a demo

‍

5 Best Practices for Building Effective Internal Developer Portals

In modern software development, Internal Developer Portals (IDPs) have emerged as a powerful tool for centralizing resources, streamlining processes, and enhancing collaboration across teams. They are a critical part of enabling developer productivity, reducing bottlenecks, and fostering a culture of autonomy. Building an effective IDP can transform how teams operate, but it requires careful planning and execution. Our last blog covered some pitfalls you may experience, and how to avoid them. Below are five best practices to ensure your IDP delivers maximum value to your organization.

1. Prioritize Developer Experience (DX)

The primary users of an internal developer portal are developers, so Developer Experience (DX) should be at the heart of your design. An IDP should be intuitive, fast, and easy to navigate. By focusing on DX, you reduce the friction developers face when trying to find services, documentation, and tools. It should be persona-driven. Here’s how to enhance DX in your IDP:

• Create a clear, well-organized interface: Structure your portal in a way that guides users logically through their workflows.
• Provide self-service capabilities: Developers should be able to provision services, access APIs, or spin up environments without having to rely on other teams.
• Use feedback loops: Actively solicit feedback from your developers to understand where pain points are and make continuous improvements.
• Developer-centric views: Each developer should only see what they are required to see. This can vary from developer to developer, even on the same team.

2. Integrate Across the Toolchain

One of the core functions of an IDP is to centralize tools, services, and processes. However, it’s important that this centralization doesn’t result in a fragmented experience. Developers use various tools (CI/CD pipelines, version control systems, cloud services, monitoring tools, etc.) throughout the software development lifecycle. Your IDP should offer seamless integration across all these platforms to streamline the developer workflow.

• API-first architecture: Ensure your IDP integrates with your existing DevOps tools and platforms via APIs.
• Single sign-on (SSO): Use SSO so developers only need to authenticate once to access the resources they need.
• Consistent user interface: Regardless of the underlying tools or systems, maintain a consistent user experience to minimize the learning curve.

3. Enable Discoverability and Documentation

The ability to quickly discover services, tools, and documentation is crucial in an IDP. Developers often waste valuable time searching for the right resources, and poor discoverability leads to frustration. A successful IDP allows developers to easily search, explore, and understand available resources. Learn about the Catalog Ingestion API’s in the Harness IDP : Catalog Ingestion APIs.

• Metadata and tagging: Implement metadata and a tagging system that enables developers to search and filter by categories such as APIs, microservices, or repositories.
• Comprehensive documentation: All services and tools listed in the portal should have well-maintained, accessible documentation. This could include API references, tutorials, and examples.
• Search functionality: Incorporate robust search capabilities so that developers can locate resources quickly and efficiently.

4. Foster Collaboration and Knowledge Sharing

An IDP isn’t just a tool repository—it’s also a collaboration hub. Developers across teams should be able to share insights, document solutions, and contribute to a collective knowledge base. This improves communication between teams and helps avoid siloed knowledge.

• Encourage contributions: Allow developers to add, update, or suggest changes to the documentation and resources in the portal.
• Social features: Integrate features like comments, ratings, or tagging to facilitate community-driven knowledge sharing.
• Version control and history tracking: Maintain a log of changes to resources or services, enabling teams to track updates and understand the evolution of tools over time.

5. Focus on Automation and Governance

Automation is key to improving developer efficiency, and an IDP can be a powerful vehicle for that. Automating repetitive tasks—like environment provisioning, testing, or deployment—frees developers to focus on high-value work. Additionally, strong governance mechanisms ensure that tools and processes follow best practices and maintain consistency across the organization.

• Automated workflows: Offer pre-built automation templates for common tasks like setting up a microservice, deploying to a specific environment, or running security checks.
• Governance policies: Enforce governance rules by integrating compliance checks, security policies, and best practice standards within the IDP.
• Role-based access control (RBAC): Ensure that only authorized personnel can access, modify, or provision certain resources to maintain security and consistency.

Conclusion

Building an effective Internal Developer Portal is an ongoing effort that requires balancing usability, integration, automation, and collaboration. By focusing on these five best practices—prioritizing Developer Experience, integrating tools seamlessly, enabling discoverability, fostering collaboration, and emphasizing automation with governance—you can create a portal that truly enhances developer productivity and drives innovation.

Your IDP should evolve alongside your development practices, becoming a central hub that accelerates and simplifies the way your teams work. With the right approach, it becomes much more than a tool—it becomes an enabler of developer success.

‍

To find out more about Harness IDP, and request a demo, be sure to click here

Introduction

Harness believes in the power of Backstage as the go-to open source framework for powering Internal Developer Portals. With its robust plugin model and strong presence in the market, Backstage has proven to be a valuable tool for many organizations. However, as a framework rather than a ready-to-use solution, Backstage poses many adoption challenges in terms of completeness and maintenance. This is where Harness steps in, offering a full-featured Internal Developer Portal product, an enterprise-grade solution built on top of Backstage to address these pain points and elevate the developer experience at a significantly faster pace than self-managed Backstage.

Backstage Adoption and Usage Challenges

‍

While Backstage offers great potential as a flexible framework for Developer Platforms, getting it up and running smoothly isn't always easy. It's not like installing a ready-made solution; instead, it needs careful setup to match what your developers need. Its strength lies in its plugin system, which helps solve developers' problems, forming the core of a good Developer Portal.

‍

But even with its strengths, customizing Backstage to fit your developers' exact needs can be tough. Making a Developer Portal that suits your team might mean lots of coding work, especially for making user interfaces in React and typescript. If your team doesn't have skilled DevOps engineers or experienced front-end developers with React expertise, you might find it hard to overcome these challenges.

‍

Also, developing such a complex product requires a skilled team which requires significant investment. To use Backstage well, you need dedicated DevOps engineers, senior developers, and a good product owner. Without them, you might struggle to make the most of Backstage as your Developer Portal solution. Harness IDP takes away those building parts from your side and offers a latest version of the backstage with enterprise grade features. 

‍

Mitigating Challenges and Enhancing Backstage's Capabilities

Workflow Automation with Scaffolder

One of the key areas where Harness adds value is in workflow automation, particularly with the Scaffolder functionality. While Backstage provides basic automation for component registration, Harness IDP extends this by offering more generalized developer automation. Leveraging the Pipeline automation workflow engine, developers can enjoy self-service capabilities, reducing wait times and improving time to market.

‍

‍

Streamlined Administrative Experience

Managing Backstage can be cumbersome, requiring manual editing of files and tracking changes. Harness IDP simplifies this process by handling hosting, upgrading, and patching, while providing an intuitive administrative interface. This alleviates the administrative burden and allows platform teams to focus on higher-value tasks.

‍

‍

Robust Governance Features

Harness IDP comes equipped with robust Role-Based Access Control (RBAC) out of the box and seamlessly integrates with Single Sign-On (SSO) providers like Okta. Access to automation can be finely governed by permissions, ensuring security and compliance without the need for extensive configuration.

‍

Proprietary Scorecards for Progress Tracking

As part of the Harness IDP solution, Scorecards offer a unique capability to track organizational initiatives and progress across teams and services. Whether it's achieving specific test coverage targets or migrating to newer versions, Scorecards provide visibility and accountability.

‍

Embracing Innovation without Compromise

Uncompromised Security

Unlike loading every community plugin into the catalog, Harness IDP takes a cautious approach. Community plugins undergo rigorous review before being made available, ensuring safety and reliability for users. While this may introduce slight delays for less popular plugins, it ultimately prioritizes security.

Balanced Customization

While users retain a significant degree of customization power, Harness IDP ensures a balance between flexibility and stability. Unlike running a completely open-source project where any change is possible, the enterprise solution offers a curated environment for efficient development without compromising stability.

Harness' commitment is clear: to provide the latest features of Backstage alongside a superior administrative experience and innovative features that empower developers. By bridging the gap between Backstage's framework and enterprise needs, Harness IDP delivers a comprehensive solution for seamless development experiences.

Checkout the Latest IDP Update

Request a demo

Learn How Internal Developer Portals Boost Team Collaboration

Software development is ever-changing, and so are the tools and methodologies developers use. While microservices are the recent buzz and discussions on mono vs polyrepos are ongoing, monorepos have been a staple for a long time. These monolithic repositories, which house code for multiple projects in a single location, have their merits. They simplify dependency management, make code reviews efficient, and offer a unified versioning system.

However, the rise of Cloud Native tools and technologies has shifted the focus towards microservices, influencing tools like Backstage. Backstage, an open-source developer portal, has become a favorite for many organizations, especially those leaning towards microservices. But what about those still using or transitioning from monorepos?

‍

Monorepos, while beneficial in many ways, come with their set of problems for backstage/Internal Developer Portal use case:

Plugins: Tools like Backstage have plugins, such as GitHub insights, that are designed with the assumption that a single repo corresponds to a single software component. In a monorepo setup, this can lead to inaccurate results, as multiple components might reside in the same repository.

Here's where the Harness Internal Developer Portal comes in. While it's true that our primary design has been microservice-first, and monorepos might seem like an afterthought, the IDP is equipped to handle both. The Harness Developer Portal is versatile enough to cater to both microservices and monorepos, ensuring no organization is left behind in their development journey.

How IDP takes special care of monorepos

This Harness Internal Developer Portal aims to enable organizations to handle monorepos as efficiently as microservices, especially given the challenges they present. Here's How:

1. Location Flexibility with catalog-info.yaml: One of the standout features of the Harness Internal Developer Portal is its ability to recognize the catalog-info.yaml file, irrespective of its location in the repository.In a monorepo, the YAML definition can be placed anywhere, offering immense flexibility in structuring. Fun fact - we love monorepos here at Harness and our [harness-core](Link to Harness Core) is managed using a monorepo.
2. Localized Documentation: With monorepos, documentation can reside within specific sub-directories, ensuring that related code and its documentation are closely knit. Backstage even offers a plugin to facilitate this, emphasizing the importance and ease of this setup.
3. Simplified Service Onboarding: When onboarding new services, there's no need to create entirely new repositories. Instead, new directories can be created within the existing monorepo.
4. Path-Aware Scorecard Checks: Scorecards in a monorepo are aware of specific paths. This means that as long as the backstage.io/source-location is configured correctly to include the sub-path where a particular project resides, everything functions seamlessly. Also the ability to verify Library version and whether a file exists or not, ensures that each project within the monorepo is treated as a distinct entity, with its checks and configurations.

Conclusion

In conclusion, monorepos offer a flexible and efficient approach to software development. With the ability to place YAML definitions anywhere, keep documentation organized, streamline service onboarding, and have precise path-aware checks, tools like Harness Internal Developer Portal make managing monorepos simpler and more effective. Whether you're a large enterprise or a growing startup, embracing these advantages can significantly enhance your development workflow.

Try out Harness Internal Developer Portal (IDP), we've got a wealth of resources to help you dive deeper. Please reach out to us for a demo. For a comprehensive understanding, our release blogs detail the latest features and updates. And if you're more of a visual learner, our video tutorials, and documentation offer step-by-step guides to get you started. Dive in and discover the transformative power of Harness IDP!

Harness Platform Continues to Expand to Address Key Customer Needs in Modern Software Delivery 

San Francisco– Sept 21, 2023– At the {unscripted} conference, Harness, the Modern Software Delivery Platform® company, today announced four new product modules on the Harness platform. Each module is aimed at advancing the state of software delivery and developer experience, and includes Harness Code Repository, Harness Internal Developer Portal, Harness Infrastructure as Code Management, Harness Software Supply Chain Assurance.

Harness Code Repository 

Harness Code Repository is a premium module based on open source Gitness^TM (launched today) and tailored to meet the demands of enterprise teams and organizations. Gitness is a developer-friendly, open source Git platform created to address common obstacles in traditional software development workflows. Read more in the Gitness press release here. Harness Code Repository provides additional enhanced features and capabilities for Gitness, including: 

• Collaborative code reviews to foster collaboration and knowledge sharing, for higher code quality and fewer errors
• Advanced governance with branch protection to ensure stability by preventing unauthorized or risky changes from being merged into critical branches, reducing the chance of introducing bugs or vulnerabilities
• Policy enforcement powered by OPA to ensure code complies with predefined organizational standards and best practices, reducing manual intervention and human error 
• Seamless integrations tailored for the development process on the Harness platform help streamline the development process by connecting code repos with other development and deployment tools to improve efficiency and collaboration, which accelerates  the software delivery pipeline 

Harness Code Repository will be available in beta next month.

Harness Internal Developer Portal (IDP)

With the rapidly emerging trend of Platform Engineering teams who seek to streamline developer experience for their organizations, developer portals are becoming a “must-have” for large engineering organizations. According to Gartner®, “By 2025, 75% of organizations with platform teams will provide self-service developer portals to improve developer experience and accelerate product innovation.” ¹

Answering that demand from Harness customers, the Harness Internal Developer Portal (IDP) helps organizations accelerate new service onboarding, simplifying the often complex and time-consuming process of setting up infrastructure, configuring frameworks, establishing CI/CD pipelines, and more. Harness IDP is built on the Backstage.io platform, providing critical governance features out of the box and a simplified management experience. 

Harness IDP includes:

• Self-service automation enables developers to create new services quickly, eliminating up to days or weeks of waiting time 
• The Software Catalog unifies essential service information, such as builds, deployments, alerts, and health metrics, into a single pane of glass called the Software Catalog 
• Discoverability of tools enhances collaboration and communication within organizations by providing easy discoverability of internal services, APIs, and tools, which helps prevent duplication of efforts and enables efficient knowledge sharing 
• Scorecards enable platform engineers to gauge service maturity and encourage the adoption of best practices from DevOps, development, and security perspectives—effectively gamifying the quest for excellence in software development 

The result is that developers spend less time being blocked and more time innovating. Visit harness.io/products/internal-developer-portal to learn more.

Harness Infrastructure as Code Management (IaCM)

Companies are using Infrastructure as Code (IaC) to define infrastructure requirements, configurations, and dependencies, and to manage resources in a more efficient and repeatable way. However, customers are still finding that most IaC solutions are labor intensive, create errors, and come with limited visibility and guardrails. Harness Infrastructure as Code Management (IaCM) addresses these challenges and adds automation and security.

Harness IaCM provides:

• An advanced pipeline for IaC automation, simplifying code management from Pull Request (PR) to provisioning. Streamlining the process speeds up the creation, testing, review, and deployment of infrastructure changes, significantly improving efficiency
• Automatic drift detection and remediation continuously monitors the infrastructure for deviations, ensuring all changes are done in the right process 
• OPA-based infrastructure policies to enforce security and compliance standards. These policies, defined as code, are applied automatically during the provisioning process, reducing the risk of misconfigurations and vulnerabilities 
• Provides the PR process for reviewing infrastructure changes, making it more efficient and error-resistant by allowing developers to understand the impact of their changes before merging the code 

Harness IaCM helps organizations achieve the benefits of self-service infrastructure management, mitigate risks associated with manual processes, and optimize operational efficiency, resulting in more secure, compliant, and efficient infrastructure management. Get started with Harness IaCM today at harness.io/products/infrastructure-as-code-management. 

Harness Software Supply Chain Assurance

Modern applications are being built with an exponentially growing number of open source components, each of which introduces new vulnerabilities that can put the application’s consumers at risk. For these reasons, the software supply chain has become the focus of cyberattacks that are increasing in both number and sophistication. According to Gartner, “By 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021.” ²

Recent supply chain attacks, such as log4j and SolarWinds, underscore the importance of open source governance and ensuring software artifact integrity in alignment with standards like Supply Chain Levels for Software Artifacts (SLSA). In the United States, Executive Order 14028 mandates SBOMs, provenance verification, policy enforcement, and rapid zero-day vulnerability response to enhance supply chain security. 

The Harness Software Supply Chain Assurance (SSCA) module comprehensively addresses these requirements by providing:

• Deep visibility and control over open source software components, allowing organizations to monitor and enforce policies based on component versions, licenses, suppliers, and more
• Streamlines the generation of SBOMs in various formats, enabling secure sharing and storage. Users can sign and validate SBOMs with their private keys 
• Enables governance by setting up policies to block harmful or risky components, such as log4j, in an organization’s supply chain 
• Ensures software integrity by generating and verifying attestations, following SLSA specifications and mandates listed in Executive Order 14028 
• Strengthens software development with DevSecOps practices, further letting software producers effectively ship secure software artifacts to their consumers 

Learn more about Harness SSCA at harness.io/products/software-supply-chain-assurance.

"The four new modules we are launching today represent a significant leap forward on our mission to enhance efficiency, foster collaboration, and fortify security throughout the software delivery lifecycle,” said Jyoti Bansal, CEO and cofounder of Harness. “These new innovations are the latest way we are providing developers and organizations with the tools and capabilities to help them achieve their software development goals.”

Harness additionally announced two new industry-wide communities:

• FinOps Excellence: A community-driven initiative to bring together leaders working in cloud cost management globally. This initiative provides a forum for leaders working on managing cloud cost initiatives within their organizations to come together and collaborate to discuss challenges and exchange best practices. Controlling cloud costs is a developer-led initiative, and Harness is at a unique position to drive and facilitate conversations where “efficient” software delivery is key. In the last few months, a growing cohort of experts from some of the largest banks, consumer/retail, telecom, IT, and insurance companies have met to further the conversations about cloud cost efficiency. You can learn more or request an invitation at linkedin.com/company/finops-excellence.

• Engineering Excellence Collective™: An industry-wide consortium of 300 senior engineering leaders working together to solve some of the most pressing challenges in the industry. Read more in the press release here.

¹ Gartner, Innovation Insight for Internal Developer Portals, By Manjunath Bhat, Mark O’Neill, Oleksandr Matvitskyy, Published 1 February 2022. 

²Gartner, Emerging Tech: A Software Bill of Materials Is Critical to Software Supply Chain Management by Mark Driver, Published 6 September 2022. 

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

About Harness

Harness is the leading end-to-end platform for complete software delivery. It provides a simple, safe, and secure way for engineering and DevOps teams to release applications into production. Harness uses machine learning to detect the quality of deployments and automatically roll back failed ones, saving time and reducing the need for custom scripting and manual oversight, giving engineers their weekends back. Harness is based in San Francisco. Please visit www.harness.io to learn more.

Learn about Targeting Rule

Note: Harness Internal Developer Portal has graduated from Beta to Public Preview and then GA. Please see the more recent announcement.

__LINK_1__‍
Discovery

In October 2022, when we launched the Backstage-Harness integration for our customers - we started talking to customers who were building their Internal Developer Portal on their own. Months into their journey, many of them complained about the struggles a Platform Engineering team goes through when building an IDP ground up which also includes self managing the hosting and operations aspects. While the trend suggests that IDPs will be everywhere, we couldn’t ignore the challenges our customers were facing in this journey. A successful IDP requires an investment of 3-5 engineers to get an early Proof of Concept, even when using a popular open source project like Backstage. It takes significant effort to set up basic enterprise features like service onboarding pipeline, user and group management, access control, secrets management, audit trails, and more. With Harness IDP, these features are a core part of our platform and are shipped out of the box.

Today, we are proud to go Beta with a handful of customers who need an IDP but find it challenging, costly and time consuming to manage it themselves or find a good alternative. Our IDP is powered by Backstage, the de-facto platform for building developer portals. We want to thank the community for building the software and we are committed to upstream contributions as we move forward.

But let’s back up a second, what is an IDP really? What problems does it solve? And what features does Harness IDP have?

Problems companies are facing today

Let’s start with the problems. The pain starts on day 1 with developer onboarding where it takes too much time and too many tickets to have developers commit, build, test code while also learning the process to get their features to production. It doesn’t get any easier even for more experienced engineers. In today’s cloud-based, decentralized, microservices environments, it’s challenging to manually track all software dependencies and things that need to happen every time changes need to be rolled out from dev-to-test-to-prod. Most organizations use a complex collection of infrastructure (cloud VM, Kubernetes, databases and more), frameworks (code, API, serverless and more) and tools (CI/CD, security scanners, monitoring and more) across different layers of the software stack. This internal maze of technologies creates unnecessary overhead, duplicates effort and hurts developer productivity. As a result, developers end up doing nonessential work to manage the cognitive overhead. Developer productivity and happiness requires removing roadblocks, and tool complexity is one of those roadblocks.

Now let’s take a look at how we are planning to solve these problems using Harness IDP.

Streamlining new service onboarding

How much time does it take for a developer in your company to create a new service? We have heard various answers from days, weeks to months. Lack of automation and standards result in fragmentation of technology choices. Inter-team dependencies make it really difficult to innovate fast.

In Harness IDP, as a developer, you can create a new backend service, API, or a website by submitting a few details as configured by your platform engineering. On the other hand, as a platform engineer, you can orchestrate the onboarding of services by creating pipelines in the Harness Pipeline Studio.

Developers focus on what they do best, which is writing features, while platform engineers focus on creating software templates, automating processes, and enforcing standards.

A catalog of all software components

Imagine a world where you wake up in the morning, get to a single page which can tell you everything you need to know about your running software - its builds, deployments, alerts, errors, etc. And if you want to use a service owned by another team, you get to see its dependencies, documentation, API reference, owner information and much more!

Technical Documentation and Search

With Harness IDP, all your technical documentation written in markdown is made available right alongside the software homepage in the catalog. The docs-like-code (https://www.docslikecode.com) approach ensures that docs are treated just like code, they live alongside the code and are updated in the same Pull Request by engineers. It also helps other developers find the documentation without going anywhere.

And with the Search functionality available not only on documentation, but across all the software components you have registered, you can quickly find what you need. This is so much better than “rumor-driven-development” isn’t it? Usually that involves asking a question on the #engineering-help channel and waiting for the handful few to notice and answer.

Extensibility through plugins

The number one reason Backstage is the best developer portal platform out there is its plugin architecture. There are hundreds of plugins available in the marketplace which integrate Backstage with third party providers and enhance the portal. We have built our own plugins and integrated with a curated list of Backstage plugins which you can enable and use.

Sign up for Beta

Harness IDP is currently available to a limited set of customers. We want to work closely with our customers and evolve in more use-cases suited for a Developer Portal. To get started, send an email to idp-interest@harness.io for a demo and we’ll get you started. To learn more, checkout the documentation at developer hub.

Request a demo

‍

Checkout Harness Internal Developer Portal

Learn more: Developer Portal Scalability Best Practices, Internal Developer Platform vs Internal Developer Portal, Effective governance strategies for internal developer portals