Brainboard.co

Four words diagnose almost every failed apply: "unauthorized," "not found," "already exists," "timeout." Each one points somewhere different. This article walks through the full debugging sequence, from reading the error to state surgery.

As AI takes on more infrastructure tasks, how does the engineer’s role change? What becomes easier, where do new risks emerge, and which skills become more valuable? Join us for a technical deep dive into Kubernetes, the impact of AI on infrastructure management, and what engineers need to learn to work confidently with both. We’ll discuss: • Kubernetes today: Why operating it remains challenging and where teams spend their time. • AI in infrastructure operations: Its potential for configuration, troubleshooting, scaling, and cost optimization—and its limitations. • Trust and control: How to validate AI-generated changes, set permissions, and keep humans accountable for production. • The learning challenge: How engineers can use AI while developing the fundamentals needed to debug systems and question its recommendations. • The evolving engineering role: What changes for DevOps engineers, SREs, and platform teams as automation expands. A practical conversation for engineers building and operating cloud infrastructure. Bring your questions, experiences, and lessons from the field. 🎙️ About the speaker Jérôme was part of the team that built Docker, where he spent 7 years running the SREs behind their entire infrastructure and tens of thousands of containers. Since then, he's trained engineers on containers and Kubernetes all over the world, and maintains one of the most widely used open-source container curriculums out there. Join us on September 17th! EST: 12 pm—1 pm 🇺🇸 CET: 18:00–19:00 🇪🇺 IST: 22:30–23:30 🇮🇳

You can vibe-code cloud infrastructure with a few prompts, but production-ready AKS still needs precision. So we turned a Microsoft's enterprise AKS reference architecture into a deployable Brainboard template. Built to MS standards, Terraform already written, deployable as-is: Core cluster • Hub-spoke network topology: separate VNets for hub (shared services) and spoke (AKS workloads) • Multi-node pool cluster (system and user node pools) • Workload identity (OIDC) enabled • Application Routing add-on (managed NGINX ingress) • Cilium network policy with eBPF data plane • Azure Policy integration • Container Registry: Premium SKU with private endpoint support Security • Azure Firewall: Premium tier • Application Gateway with WAF (OWASP 3.2) • Azure Bastion for remote access • Key Vault: centralized secrets, CSI driver integration, private endpoint support • Private endpoints (optional) for ACR and Key Vault • Workload identity: Microsoft Entra ID integration for pods Data services • Cosmos DB: Core SQL API and MongoDB API accounts • Azure Cache for Redis: Premium tier with SSL enforcement • Service Bus: Premium tier Monitoring • Log Analytics workspace + Container Insights • Managed Prometheus and Grafana (optional) DevOps • Flux GitOps (optional; configurable) • CSI Secret Store driver: secret injection from Key Vault Every optional component is a feature flag: private endpoints, Prometheus and Grafana, Flux, OIDC, managed NGINX, Cilium/eBPF. Flip them and the Terraform follows. Try Brainboard for free and access the template 👉 https://lnkd.in/ei8a9N-q

An Azure DDoS architecture: diagram and Terraform, one template. Two variables to fit it to your network. No app code changes, no downtime to enable. What's in it: internet → Azure DDoS Protection → Application Gateway with WAF → Linux Web App. One deliberate chokepoint, so malicious traffic gets dropped at the earliest layer and nothing downstream burns compute on it. Two decisions baked in: 1/ Placement. DDoS protection can sit at the virtual network level or the public IP level. The template exposes both: traffic pattern and cost decide. 2/ Boundaries. Internet-facing components and the application tier live in separate resource groups, so the security boundary is visible on the diagram itself. Grab the template in the first comment.

RBAC in Brainboard goes down to the object level. Every object carries its own access control, and you set it per role from one configuration screen: enable or disable access to any object, for any team or member. So when several teams share one infrastructure, everyone builds on the same canvas and only the roles you choose can run the deployment. The clip walks through the config.

Brainy now follows your rules. Write its instructions in markdown and scope them at organization, project, environment or architecture level. Set your conventions once at the top, override them only where an architecture needs something else. Request access via the link in the comments.

Three new providers: vSphere, Nutanix, Infoblox. Brainboard now supports all three. Your hybrid, on-prem and specialized network estates get designed, generated and managed in the same place as your public cloud.

We love hearing from two voices on the same team: the practitioner writing the Terraform, and the lead accountable for the results. A tool that only convinces one of those two voices doesn't stay in the stack. Their words below. Full case study in the comments.

Before AWS and Azure, there was Pivotal Cloud Foundry. Senior Cloud Architect and Published Author Lalit Kale has shipped on all three, and he opened engineered as our first guest. In this clip, he explains why he signed up: a series where the community brings its best and pays it forward. That's the bar for every episode. He also mentioned he's been a Brainboard user since the beta days. Kind words we don't take for granted 💜 The full conversation is a deep dive on event-driven architecture. Watch it via the link in the comments, and subscribe to Engineered while you're there!