“So, where do you put IaC of your services?”
summary
Company runs AWS with ~280–300 production K8s nodes across dozens of EKS clusters and moves from a monorepo to keeping IaC next to each microservice because teams and ownership change rapidly. Uses Terraform + Spacelift for CI, exports shared outputs with SSM when needed, and builds a YAML service registry that auto-creates a pipeline per service. Modules live in a separate HTTP-backed boring registry. The result: fewer state-file handoffs and less platform-team bottleneck, at the cost of extra sharing workarounds.
AI-written summary · about
chapters (16)
- 0:00Introduction and speaker intro
- 2:28Agenda and problem overview
- 4:15Company background and scale
- 5:43Defining infrastructure as code
- 9:53Problem with team ownership shifts
- 11:41Option 1: Service repository
- 16:17Disadvantages of service repo
- 19:51Option 2: Monolithic repo
- 24:07Option 3: Team repositories
- 28:03Platform infrastructure placement
- 30:09Tier’s journey and lessons learned
- 31:35Service registry and automation
- 34:07Developer access and modules
- 37:59Quiz and reusable modules
- 39:04Summary and takeaways
- 40:07Q&A
related talks
20mProduction Grade IaC setup
48mMoving from spaghetti infrastructure to composable cloud environments
15mInfrastructure as a Code: Best Practices and Myths
50mInfrastructure-From-Code and the end of Microservices
23mA Journey to Automated Infrastructure
31mCommodified IaC using Terraform Cloud
14mThe IaC Tooling Multiverse and the Future of Platform Engineering
27mApplication-Driven Infrastructure