Spotify is introducing a Kubernetes monitoring tool that’s designed around the needs of service owners, not cluster admins. The tool is part of Backstage, an open platform for building developer portals.
The philosophy behind Backstage is simple: improve developer experience by reducing infrastructure complexity.
As popular and widespread as Kubernetes has become, all of the tools to date have been geared toward the needs of cluster admins. These tools add unnecessary complexity to the workflows of the typical developer building, testing, and deploying services.
Backstage Kubernetes gives developers back control of their services by providing a more focused and consistent experience. Backstage provides a single standard for developers to monitor their Kubernetes deployments, regardless of the underlying cloud infrastructure.
A core feature of Backstage is its service catalog, which aggregates information about software systems together inside a single tool, with a consistent, familiar UI.
By navigating to a service’s overview page in Backstage, users can see everything they need to know about the service: what it does, its APIs and technical documentation, CI/CD progress — and now detailed information about its presence on Kubernetes clusters.
Kubernetes in Backstage can be configured to search multiple clusters for services. It will then aggregate them together into a single view. So if users deploy to multiple clusters they will no longer need to switch kubectl contexts to understand the current state of their service.
The list of deployments in the Backstage Kubernetes plugin includes:
- Automatic error reporting: Instead of trying different kubectl commands to figure out where an error occurred, Backstage will automatically find and highlight errors in Kubernetes resources that are affecting service.
- Error reporting screen in Backstage Kubernetes plugin
- Autoscaling limits at a glance
Since Backstage communicates directly with the Kubernetes API, it’s cloud agnostic — it doesn’t matter how or where users are running Kubernetes. Users always get the same familiar view of their deployments, whether they’re:
- Deploying to clusters on AWS, Azure, GCP, or another cloud provider
- Using an unmanaged or managed Kubernetes service (like OpenShift, etc.)
- Migrating from one cloud provider or service to another
- Testing on a single local machine or deploying to a dozen clusters in production
For more information about this news, visit https://backstage.io/.