4 ms·
> But using cloud APIs directly was great for us This is fine, I've done it extensively myself for some of the bleeding-edge cloud stuff, but the importance of
by jrsdav 5y ago
> But using cloud APIs directly was great for us
This is fine, I've done it extensively myself for some of the bleeding-edge cloud stuff, but the importance of things like tracking state, managing hierarchical resource dependencies, or retry/back-off logic shouldn't be tossed aside simply because there are gaps in what's available in the Terraform providers. Especially where change management is important (basically any enterprise company).
I'd caution others reading this against abandoning something altogether and writing bespoke IaC tooling simply because the stable approach doesn't cover every (bleeding) edge case.
You'll spend a lot of time reinventing the wheel, and while it's fine for certain situations (like when you only care about desired state, not known state, for instance), you'll move faster (and likely safer) by sticking with tools like Terraform for the bulk of your infra, and augmenting here there with cloud APIs/SDKs when needed.
- dharmab 5y agoYes, we did have to implement our own state tracking, retries/recovery, etc- but since we were focused on a limited subset of the cloud API, this was pretty easy.
- Thaxll 5y agoSo you re-implemented terraform but worse most likely. Also you could have added those missing features and re-use the TF engine, it's very simple to include new API of an existing provider.
- dharmab 5y agoNo, we used an entirely different architecture/paradigm not possible with tf, and had capabilities tf doesn't attempt to provide (such as coordinating migrations with both cloud and application APIs, or managing capacity while upgrading 10000s of CPU cores worth of compute).