3 ms·

Maybe I'm spoiled, but this seems like a solution in search of a problem. Is it truly common to have separate environments described by independent copy-pastes

by scubbo 5y ago

Maybe I'm spoiled, but this seems like a solution in search of a problem. Is it truly common to have separate environments described by independent copy-pastes of the conceptually-same code, rather than one configurable CDK construct or Terraform equivalent? If I heard "When someone makes a change to the code for one instance, they copy or merge the change to other instances. The process for doing this is usually manual, and involves effort and care to ensure that deliberate differences between instances are maintained, while avoiding unintended differences." rather than using a deployment pipeline, I'd run screaming.

3np 5y ago
You can still end up here with a stellar deployment pipeline. Let’s say you have servers on AWS, Scaleway and OVH, running separate instances of the same code, in staging/test/prod. They don’t provide the exact same abstractions and accesses for VPCs and VMs. Certainly not for PaaS workloads like containers.
- scubbo 5y ago
  Thanks for explaining! I appreciate the insight. Seem that I _have_ indeed, been spoiled (or, at least, coddled), because I've never worked on a multi-cloud environment, so have never had to consider such a case.
edgan 5y ago
Terraform leads to this pattern. Unless you can make your environments exact mirror images of each other, this is what you end up with. Almost no one does exact mirror images for cost reasons. Every environment would have to be at production scale.
- scubbo 5y ago
  The "this" in your second paragraph has an unclear referent. Are you saying that copy-pasted code definitions per-environment are necessary unless those environments are exact mirror-images? If so, that is untrue - CDK (and, I assume, any other IaC framework, with the appropriate terminology change) allows Constructs to be instantiated with different variables. For instance, you could have a Construct for your environment that accepts a `numServers` variable, and instantiate that Construct multiple times with different variables for beta, gamma, etc. Only one instance of the definitional code, but multiple instantiations.

by scubbo 5y ago

3np 5y ago

You can still end up here with a stellar deployment pipeline. Let’s say you have servers on AWS, Scaleway and OVH, running separate instances of the same code, in staging/test/prod. They don’t provide the exact same abstractions and accesses for VPCs and VMs. Certainly not for PaaS workloads like containers.

scubbo 5y ago
Thanks for explaining! I appreciate the insight. Seem that I _have_ indeed, been spoiled (or, at least, coddled), because I've never worked on a multi-cloud environment, so have never had to consider such a case.

edgan 5y ago

Terraform leads to this pattern. Unless you can make your environments exact mirror images of each other, this is what you end up with. Almost no one does exact mirror images for cost reasons. Every environment would have to be at production scale.

scubbo 5y ago
The "this" in your second paragraph has an unclear referent. Are you saying that copy-pasted code definitions per-environment are necessary unless those environments are exact mirror-images? If so, that is untrue - CDK (and, I assume, any other IaC framework, with the appropriate terminology change) allows Constructs to be instantiated with different variables. For instance, you could have a Construct for your environment that accepts a `numServers` variable, and instantiate that Construct multiple times with different variables for beta, gamma, etc. Only one instance of the definitional code, but multiple instantiations.