10 posts tagged with "Platform Engineering"

Different infrastructure underneath. One foundation for the blueprint you choose.

Here is a small thing that still delights me. Take the kind cluster running on your laptop, run one command, and it shows up in the same console as a production cluster on EKS: same deploy pipeline, same add-ons, same cost view. Not a simulation of production. The same blueprint running on the same foundation.

I want to explain why we built it that way, because behind that small trick sits our entire argument about how infrastructure should work for startups and mid-size companies. It starts with giving Kubernetes credit for what it actually standardized, and being honest about what it never did.

Requests are not waste: teams use them to preserve schedulable capacity for bursts, startup spikes, and reliability. They also determine how workloads fit on nodes, so more headroom than a workload needs can block consolidation or occupy capacity another workload could use.

AstroPulse shows requests beside time-averaged usage for every cluster, namespace, and application. The gap starts an investigation; it does not prescribe a new request.

Compare requested headroom with average use, then decide whether the gap is intentional.

Many startups begin with one application and a hosted deployment service. That is usually the right decision. The team can ship without first building networking, deployment automation, or an operations layer.

The requirements change as the company adds services, environments, enterprise customers, private networking, and infrastructure ownership. The team still needs a short path to production, but the applications now need to run in infrastructure the company controls.

AstroPulse gives growing engineering teams a repeatable path from code to production in infrastructure they control, without requiring them to build the platform themselves.

From code in the editor to a healthy application, with one platform reused across multiple services.

A personal note on where AI for operations is actually heading.

Over the past year a new category filled up fast. Depending on how you count, there are now more than a dozen credible tools that call themselves AI SREs. I have watched the space closely, partly because we are building in it, and partly because the speed of convergence is genuinely interesting.

Here is what nearly all of them do. They connect to your telemetry, your code, and your incident tooling. They correlate logs, metrics, and traces. When an alert fires, they form hypotheses, test them against the evidence, and post a likely root cause into Slack, often in under a minute. This is real progress. A few years ago none of it worked. Today most of it does.

When something breaks in production at an odd hour, the person on call has to do three things at once: understand what is happening, decide what to do about it, and be able to explain all of it the next day. Most AI incident tools help with at most one of these. They either give you more data to read, or they take action you cannot see and cannot account for afterward.

We spent the last several months building Nova's investigation engine around that gap. This post is about how we designed it, the models we borrowed from, and the trade-offs we made along the way.

Six months in as platform lead and you have a spreadsheet you haven't shown your manager. Eleven Kubernetes clusters. EKS for production. GKE for the ML team. Two on-prem clusters behind the firewall that predate your tenure. A handful of Kind clusters developers spun up locally. Each one has its own deployment pipeline, its own credentials rotation process, its own way of answering "is this service healthy?"

Your team isn't building features anymore. You're maintaining eleven slightly different versions of the same tooling.

astroctl infra k8s register --name my-cluster

Every AI agent demo looks the same. The model calls a tool, gets a result, and responds. Then you run it against real infrastructure, and the demo falls apart in ways the tutorials never mention.

We have spent over a year building Nova, an AI agent that operates real infrastructure for real teams. It is not a chatbot that wraps API calls. It investigates incidents, executes remediations, and composes across dozens of integrations. This post is about what we learned: the problems that made us rebuild entire subsystems, and the patterns that survived.

Platform teams carry operational knowledge that does not transfer easily. The debugging instincts, the service interdependencies, the deployment quirks: they accumulate over years and live in a few people's heads. When those people are unavailable, the gap shows.

We built Nova to put that knowledge into a system you can query. This post covers what the architecture looks like and what we learned building AI that actually operates infrastructure.