April 26, 2021 was another day in tech. The world was just starting to settle into a new normal with remote work, and internal developer portals like Backstage were gaining traction as companies sought more organized ways to manage their applications and infrastructure.

I found myself deep in the weeds of setting up an internal developer portal for our team. It’s been a while since I’ve really dug into the nitty-gritty of platform engineering, and it felt good to get back into the thick of it. The goal was simple: make development easier by providing a central hub where developers could find everything they needed about our applications.

I dove right in, setting up Backstage using its documentation as my guide. It’s always exciting when a tool has decent docs; I found myself going through them with a fine-tooth comb to ensure nothing was missed. However, as I started to configure and customize the portal, things quickly deviated from the plan.

One of the first issues I encountered was around managing our microservices. Our application landscape was a bit sprawling, with services written in various languages: Java, Python, Go, and a few others. Backstage’s support for different languages seemed adequate, but not without some fiddling to get everything to play nicely together.

Another challenge was integrating our CI/CD pipeline, which was based on Jenkins and Kubernetes. Getting the data from Jenkins into Backstage wasn’t straightforward. I had to piece together several APIs and use a bit of scripting to make sure the data flowed correctly. It’s those moments where you realize how much of a gap there can be between theory and practice.

The complexity of our stack didn’t help either. We were using different service discovery mechanisms, storage backends, and a mix of container orchestration tools (Kubernetes was just starting to become ubiquitous, but it wasn’t the only one). Trying to unify all this under Backstage required a lot of cross-tool integration work.

On top of that, there was the question of SRE roles and how they fit into our organization. As more teams adopted these roles, I had to ensure that Backstage could support not just developers but also site reliability engineers who needed visibility into system health, logs, and metrics.

One particularly frustrating moment came when we ran into a bug in one of the dependencies. The error messages were opaque at best, and fixing it required digging through a mess of code. It’s times like these that make you realize how much effort goes into maintaining robust systems even as they evolve.

Despite the challenges, I found some silver linings. Working on Backstage gave me an opportunity to explore new tools and technologies. For instance, eBPF started gaining more attention this year, and it felt like a fun side project to toy with in my free time outside of work. Maybe next time I’ll try integrating some eBPF into our stack.

The month also saw plenty of tech news that echoed the broader industry sentiment. Google’s API copying case brought up interesting debates about fair use, while “They introduce kernel bugs on purpose” highlighted the sometimes questionable practices in software development. These stories provided a stark reminder of the real-world implications of our choices and how they can affect both users and developers.

In the end, Backstage turned out to be more than just a tool for organizing our internal resources. It became a reflection of the broader tech landscape—full of challenges, but also opportunities for growth and innovation. As I look back on this experience, it’s clear that platform engineering is far from being a solved problem, but with the right approach, we can make significant strides in making development more efficient and enjoyable.

---

That was my day-to-day reality for April 26, 2021. The tech world was buzzing with activity, but at its core, it was all about navigating the complexities of our evolving infrastructure to support the needs of developers.