3 ms·

what does that even mean? Let me give you a trivial example: GCP gives you a lot of flexibility with CPU and memory when creating a VM. Let’s say your workload

what does that even mean? Let me give you a trivial example: GCP gives you a lot of flexibility with CPU and memory when creating a VM. Let’s say your workload is ideally suited to some weird combo, like 5 cores and 13G or something. On GCP that’s what you provision and that’s what you pay for. AWS and Azure offer fixed sizes, so you have to round up to 8 and 16 (and pay for it). So if you want to be cloud-agnostic there’s one cool but very basic feature you just can’t use. Once you start digging into this stuff this keeps coming up: something that’s efficient (cheap) in one but not in another means: do I do it the same and pay more, or do I diverge and accept that I’ve got 2 configurations for this feature now, and save some money. Multiply this by 1000 special cases and then you find that trying to make one size fit all is a wild goose chase. All Terraform really offers is doing this in similar syntax for the subset of each cloud’s features that Terraform knows about, and extending Terraform yourself for anything it doesn’t. Yes, I would rather use the native thing for each cloud, even CloudFormation. ARM Templates and DSC are actually quite nice once you get used to them!

parasubvert 7y ago
The wild goose chase part I see as a major exaggeration. It's interesting, I use BOSH + Terraform all the time, wherein BOSH exposes GCP's CPU/memory flexibility, the various Azure NIC/LB/availability set options, AWS' different disk types, etc. Those differences can be modularized, so that 95% of your configuration templates are identical across clouds, and the last 5% maps to specifics. I'm sure it's not all that different from Terraform w/ modules, though my main problem with Terraform is that it doesn't constrain you into a "do the right thing" path, it's too easy to create a mess. Anyway, IMO these kinds of differences really aren't hard to handle and it's valid to prioritize cloud-independent configuration if that's what you want/need. It allows the main configuration and installable software to be cloud-independent, dramatically easing testing. We're seeing this drive with the flocking to Kubernetes which enables cloud-independent networking, storage, and compute. I think differing opinions on this are normal/fine, but i have to wonder why the single-cloud proponents use words like "snake oil" as if to completely discredit a different set of priorities.

parasubvert 7y ago

The wild goose chase part I see as a major exaggeration. It's interesting, I use BOSH + Terraform all the time, wherein BOSH exposes GCP's CPU/memory flexibility, the various Azure NIC/LB/availability set options, AWS' different disk types, etc. Those differences can be modularized, so that 95% of your configuration templates are identical across clouds, and the last 5% maps to specifics. I'm sure it's not all that different from Terraform w/ modules, though my main problem with Terraform is that it doesn't constrain you into a "do the right thing" path, it's too easy to create a mess. Anyway, IMO these kinds of differences really aren't hard to handle and it's valid to prioritize cloud-independent configuration if that's what you want/need. It allows the main configuration and installable software to be cloud-independent, dramatically easing testing. We're seeing this drive with the flocking to Kubernetes which enables cloud-independent networking, storage, and compute. I think differing opinions on this are normal/fine, but i have to wonder why the single-cloud proponents use words like "snake oil" as if to completely discredit a different set of priorities.