👋 Hi there, I’m Suraj

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. ...

In my last blog, I shared my experience and point of view on Platform Engineering. (click here to read previous blog post on Platform Engineering through my lens) In this post, I want to share what a week in the life of a Platform Engineer can look like, based on my own experience and what I’ve heard from other platform folks too. Take this with a pinch of salt. Every organisation is different. Their needs are different, and their platform is different too. ...

I stepped into Platform Engineering in 2019, before the term had the hype and buzz it has today. Before that, I was a software engineer working in the Kubernetes space, mostly building CLI tools. I genuinely loved it. Writing Go, shaping developer workflows, making day-to-day tasks simpler, that part was fun. But something kept bothering me. Most of my work was focused on local clusters or limited environments. I wanted to keep doing what I enjoyed (building tools), but also learn what happens when Kubernetes meets real production: infrastructure, reliability, deployments at scale, operational pain, and all the invisible decisions that make systems stable. ...