Helgi Thorbjoernsson

Platform teams spend months fighting infrastructure drift. Formae's answer: stop managing state files. Let reality be the state. The approach feels obvious now. After a decade of Terraform dominance, Platform Engineering Labs just dropped formae. It's the first major IaC innovation in years. Here's what makes it different: 🔍 Automatic discovery - Maps existing infrastructure regardless of how it was created 📝 No state files - Reality itself becomes the state 🔄 Two modes - Reconcile for alignment, patch for incremental changes ⚡ PKL language - Replaces HashiCorp Configuration Language The timing matters. Cloud sprawl is real. Infrastructure drift breaks things. Toolchains feel fragile. Formae tackles these head-on with agent-based architecture. It decouples state management from clients. Works whether you used Terraform, manual ops, or legacy scripts. Early feedback looks promising. System Initiative's CEO called the approach "smart". codecentric highlighted reduced cognitive load. But let's be real. Terraform has massive ecosystem support. Community knowledge runs deep. Formae needs to prove its automatic discovery beats familiar workflows. The Functional Source License balances open access with business sustainability. Smart move for a startup entering dominated space. Success depends on whether "reality as state" solves more problems than it creates. What's your take? Does automatic infrastructure discovery outweigh ecosystem maturity? #InfrastructureAsCode #PlatformEngineering #CloudInfrastructure 𝐒𝐨𝐮𝐫𝐜𝐞: https://lnkd.in/gGDJC3T6

3

2 Comments

I thought this was a good and very reasonable talk by Eleanor Millman on how to prioritize projects for a platform engineering team: https://lnkd.in/gaYtUHRH A few insights I took from it: - Unlike product features which can be more directly tied to revenue, platform engineering work is a couple steps removed. But that doesn't mean it's unimportant! Far from it, platform engineering projects can make everyone at the company more efficient, able to produce higher quality software, etc. - While "urgency" is always going to be a factor, you don't want to just be putting out fires, you want be able to prioritize work which is "high impact" ... even if that impact isn't felt immediately. - Good rule of thumb: prioritize "highest impact for lowest effort". - The talk has some ideas on what factors to choose for impact, and how to blend them. For instance "speed of development" is one factor, "cloud cost optimization" might be another. The weighting of different impact factors can change over time, depending on the needs of the business. I would say that a lot of companies don't have much methodology here but I can really see the value in codifying it. You can always change the methodology or the weighting if it's spitting out results that don't pass the smell test or you really feel it is leading the company astray. Clarity can give the org more freedom to put resources behind projects that would otherwise never be taken on. When things are unclear, prioritization still happens implicitly, but the decisions tend to be a lot more random and fear-based and the org is worse off as a result.

14

3 Comments