3 ms·

If you plan on being „cloud agnostic“, not using the services they offer like databases, you might as well stay in your own DC.

cjalmeida 8y ago
This is a non sequitur. You can, and should, leverage the flexibility of cloud computing without being too locked down to a single vendor. That’s one of the things tools like Terraform, Kubernetes or Mesos were designed for.
- MrBuddyCasino 8y ago
  Terraform doesn’t buy you anything. It supports multiple vendors, but you have to re-write all the code when switching. If the lowest common denominator is K8S/Mesos, while not using any of the cloud services, you’re doing it wrong.
  - joewee 8y ago
    Which would do you have to re-write? Your deployment code or your application code. If it’s the latter you’re not using the cloud correctly. If it’s the former, re-writing deployment scripts is much easy than physically migrating a DC which is think is the real comparison.
    - throwawayacct4q 8y ago
      I have built multi-cloud, totally cloud-agnostic deployments at my previous company with terraform, for really interesting reasons. At least for tf even if you are spinning up a VM and installing something like postgres on it (cloud agnostic, no managed services), rewriting is required because the order of operations can be different in infrastructure building, different modules, different vars, etc. You can use your code for one cloud as a template for the new one, but you do need to maintain a set of scripts for each cloud in my experience.
mmt 8y ago
I agree with my sibling-commenter that this is a bit of a stretch, and I also think that merely not using a cloud provider's integrated database offering (e.g. RDS instead of running ones own on EC2 with or without EBS) doesn't invalidate all the benefits. However, you do bring up an important point, which is a criticism I've always had for the term "infrastructure as code": Unless the underlying hardware is identical in performance, that code isn't really describing/commanding anything deterministic. This is especially true for databases or anything I/O-sensitive like message queues or stream processing. It would certainly make "cloud agnosticism" a much less trivial exercise. At the risk of sounding ad-hominem, I generally find that it is software engineers whose experience is primarily at higher levels of abstraction who under-estimate how much it matter (or, conversely, over-estimate how much software or "code" can just solve such problems). See also https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

cjalmeida 8y ago

This is a non sequitur. You can, and should, leverage the flexibility of cloud computing without being too locked down to a single vendor. That’s one of the things tools like Terraform, Kubernetes or Mesos were designed for.

MrBuddyCasino 8y ago
Terraform doesn’t buy you anything. It supports multiple vendors, but you have to re-write all the code when switching. If the lowest common denominator is K8S/Mesos, while not using any of the cloud services, you’re doing it wrong.
- joewee 8y ago
  Which would do you have to re-write? Your deployment code or your application code. If it’s the latter you’re not using the cloud correctly. If it’s the former, re-writing deployment scripts is much easy than physically migrating a DC which is think is the real comparison.
  - throwawayacct4q 8y ago
    I have built multi-cloud, totally cloud-agnostic deployments at my previous company with terraform, for really interesting reasons. At least for tf even if you are spinning up a VM and installing something like postgres on it (cloud agnostic, no managed services), rewriting is required because the order of operations can be different in infrastructure building, different modules, different vars, etc. You can use your code for one cloud as a template for the new one, but you do need to maintain a set of scripts for each cloud in my experience.

mmt 8y ago

I agree with my sibling-commenter that this is a bit of a stretch, and I also think that merely not using a cloud provider's integrated database offering (e.g. RDS instead of running ones own on EC2 with or without EBS) doesn't invalidate all the benefits. However, you do bring up an important point, which is a criticism I've always had for the term "infrastructure as code": Unless the underlying hardware is identical in performance, that code isn't really describing/commanding anything deterministic. This is especially true for databases or anything I/O-sensitive like message queues or stream processing. It would certainly make "cloud agnosticism" a much less trivial exercise. At the risk of sounding ad-hominem, I generally find that it is software engineers whose experience is primarily at higher levels of abstraction who under-estimate how much it matter (or, conversely, over-estimate how much software or "code" can just solve such problems). See also https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...