Blogs

This is the final post in the Backstage Tech Insights series. Over the past eight posts, we went from “what is Tech Insights?” to setting up plugins, retrievers, checks, scorecards, custom retrievers, and production troubleshooting. Here is everything we covered, with links to each post. The series Introduction to Backstage Tech Insights: What Tech Insights is, why it matters, and how it fits into your developer portal. Covers the core concepts: fact retrievers, checks, and scorecards. ...

In the previous post, we built a custom fact retriever to check Kubernetes annotations on running deployments. By now you have a working Tech Insights setup: fact retrievers collecting data, checks evaluating it, and a frontend displaying results. But running Tech Insights in a development environment is one thing. Running it reliably in production is another. This post covers the issues you’re most likely to hit, and how to run Tech Insights reliably in production. ...

Over the past six posts, we set up Tech Insights end to end using the built-in fact retrievers. These retrievers gave us facts covering metadata completeness, ownership, and TechDocs, and you have seen them in the UI through scorecards and service maturity. That’s a solid foundation. But those facts only tell you about Backstage entity metadata and TechDocs. They inspect catalog metadata such as metadata.title, metadata.description, spec.owner, and annotations. That’s all they can see. ...

In the previous post, we set up scorecards to display pass/fail check results on entity pages. Scorecards are great for binary compliance, but sometimes you want a more nuanced view. Service Maturity gives you that. Instead of a flat list of pass/fail results, it introduces maturity rankings and categories into your quality checks. Teams can see where their service sits on a progression and what they need to do to reach the next level. ...

In the previous post, we defined checks and verified them through the API. But the only way to see check results right now is by curling the backend. That’s not the best way, is it? In this post, we’ll install the frontend plugin so check results show up directly on entity pages in the Backstage UI. Step 1: Install the frontend plugin Install the frontend plugin from your Backstage root directory: ...

In the previous post, we set up the built-in fact retrievers and verified that facts are flowing. We now have acts being collected for every entity in our catalog. Facts on their own are useful, but they become much more valuable when you evaluate them. Checks do exactly that. A check takes one or more facts and evaluates them against a condition. The result is a simple pass or fail. Installing the check engine To evaluate facts, we need a check engine. The Tech Insights plugin provides a backend module called plugin-tech-insights-backend-module-jsonfc. The name jsonfc stands for JSON Fact Checker. Under the hood, it uses json-rules-engine, a lightweight library for evaluating rules defined as JSON objects. This means you can define all your checks as JSON-based rules directly in app-config.yaml without writing any custom code. ...

In the previous post, we installed the Tech Insights backend plugin. Now it is time to make it do something useful. Fact retrievers are the data collection layer of Tech Insights. They gather information about your catalog entities and store it as structured facts. Without fact retrievers, there is nothing for checks to evaluate. What is a fact retriever? A fact retriever is a function that: Runs on a defined schedule (e.g., every 15 minutes, every hour) Iterates over entities in the catalog Collects specific data points about each entity Stores those data points as facts Once facts are stored, checks can evaluate them. ...

In the previous post, we looked at what Tech Insights is and why it is useful. Now let’s get it running. This post walks through the backend installation and configuration of the Tech Insights plugin. Prerequisites Before you start, make sure you have: Node.js and Yarn installed A working Backstage instance Access to the Backstage codebase If you do not have a Backstage instance yet, the official getting started guide is the best place to begin. ...

If you are running Backstage as your internal developer portal, you have the software catalog in place, you can easily discover services but you have probably dealt with this question at some point: How do we know if our services are following the standards we agreed on? Maybe you want to check whether every service has a README. Maybe you want to ensure all services have CI configured. Or perhaps you want to verify that a particular annotation is present on the components or their Kubernetes resources. ...

I recently came across a simple but surprisingly rich concept in Go: padding. It is the space the compiler inserts between fields so each value aligns with the architecture’s expectations. Once you see how much wasted room can live between the fields, you start to appreciate how a small reordering can shrink both the in-memory size of a struct and the amount of memory you move around. Why padding exists at all Go lays out struct fields according to each type’s alignment requirement. The compiler inserts padding bytes between fields so the next field starts at the proper boundary. This alignment keeps the CPU happy but can leave gaps between fields or push later fields forward so the entire struct ends up bigger than the sum of its fields. ...