Skip to main content
Welcome. This site supports keyboard navigation and screen readers. Press ? at any time for keyboard shortcuts. Press [ to focus the sidebar, ] to focus the content. High-contrast themes are available via the toolbar.
serard@dev00:~/cv

Infrastructure as Code: My Journey

From Bash scripts to PowerShell modules — how I learned to stop worrying and love the automation.

The Problem

Every developer knows the pain: "it works on my machine." Over the years, I've encountered this problem in many forms, from inconsistent development environments to flaky CI pipelines. The root cause is always the same: infrastructure that isn't reproducible.

My Approach

My motto has always been "anything-as-code". If it can be automated, it should be. If it can be versioned, it must be.

The Evolution

Diagram

At Qwant, I built an entire Software Factory that integrated Dev, CI, QA, CDel, and CDep problem-spaces. The key insight was applying KISS and DRY principles not just to application code, but to the infrastructure itself.

At BIM&CO, I took this further by extracting core features into distributable tasks, making systems scalable by design.

The Module Mindset

My second motto — "you better make it a module" — drives how I structure everything. Each concern gets its own module:

DevPoSh (boilerplate)
├── Vagrant Module      → VM lifecycle (via [BinaryWrapper](#content/blog/binary-wrapper.md))
├── Packer Module       → Image building (via [BinaryWrapper](#content/blog/binary-wrapper.md))
├── Docker Module       → Container orchestration (via [Docker Compose Bundle](#content/blog/wrapping-docker.md))
├── Traefik Module      → Reverse proxy config
└── InfraDev Module     → Ties it all together

Each module provides specific cmdlets and completers, making the developer experience smooth and discoverable.

Lessons Learned

  1. Start with the developer experience. If your IaC isn't easy to use, nobody will use it.
  2. Module boundaries matter. Clear separation of concerns in infrastructure code is just as important as in application code.
  3. Document with code, not docs. Well-named cmdlets and tab-completers are the best documentation.
  4. Test your infrastructure. If you can test your app, you can test your infra.

What's Next

I'm currently working on bridging the gap between my PowerShell-based stack and Kubernetes, with the end goal of adding support for .NET Aspire. The idea is to have a seamless pipeline from local development all the way to production orchestration.

This article reflects my personal experience and opinions on infrastructure automation. Your mileage may vary, but the principles are universal.