61–70 of 124 posts
this is great, but I would argue the biggest issue with infrastructure as code is this: the structure and syntax for AWS is entirely different from Azure is entirely different from GCP. Instead of abstracting to CSS, I would argue modeling what Bytecode did in java for multi-operating system, we should do for infrastructure of code. That way, you could easily replicate in different environments, free yourself from ve…
Earlier quoted context omitted.
You can do that through abstraction. You “include” your Terraform Azure Provider or Terraform AWS Provider. At the end of the day, your module needs to know what it’s interacting with but not the higher level of abstraction. We have done it at my work to make it cloud agnostic just in case we need to go to another CSP
> We have done it at my work to make it cloud agnostic just in case we need to go to another CSP Have you actually tested migrating Cloud Providers with your cloud-agnostic infrastructure?
I don't think the author has tried Pulumi, which can do exactly this kind of thing.
The CSS like IaC language idea was not what I was expecting. It seems ok, but I was hoping for something deeper. What I mean is that I have always felt like there is tension or a mismatch between IaC and the underlying services in a more general sense. I’ve used CDK, Pulumi, Terraform, and CloudFormation and you can argue the merits of each. But they all kind of suck in the sense that you are programming a machine th…
I took it as a clumsy (yet somehow descriptive) analogy.
> I believe that infrastructure as code languages and tool assisted generators that we currently use are good, and they are taking steps in the right direction, but most of them are trying to patch over underlying complexity in a way that is fundamentally unscalable. Sure, I can get behind this. Yesterday I was trying to figure out how to give a name to EC2 instances generated by AWS-managed autoscaler group that’s c…
> “there’s no way it has to be like this.” It really doesn't, but alas: worship at the altar of unnecessary cloud complexity or be cast out to the on-prem Elysian field.
Earlier quoted context omitted.
You can do that through abstraction. You “include” your Terraform Azure Provider or Terraform AWS Provider. At the end of the day, your module needs to know what it’s interacting with but not the higher level of abstraction. We have done it at my work to make it cloud agnostic just in case we need to go to another CSP
How did you approach testing this? Anything to watch out for when defining abstractions? I'm following Crossplane's abstraction model.
Contract tests are used
Then we have test resources that get created, validated then instantly destroyed.
If we don’t have access to the CSP, then we can only go as far as contract tests. I can’t integrate with it live such as GCP.
Starting to look into Terratest.
My problem with the current IAS systems is the state storage. It should not be needed! Instead, the IAS tool should introspect the systems it's managing and build the necessary state on the fly.
This does not work. Say I have resource A with property X=1 I define in IAC. Someone comes along and modifies X=2 outside of state. With your way, the IAC tool would see that change and think it was naturally part of the desired state, whereas stored state will catch the drift. And before anyone says “well dont modify outside of IAC” I say 1) that’s often impractical and 2) sometimes automation can modify resources o…
Second, this is still fine. Don't make changes outside of the IAC control. And if you do make them, retro-fix the IAC files until there is no diff with the actual state.
Third, IAC should have an option to ignore some changes.
> Also, dynamically creating state creates all sorts of concurrency issues, which is another nice thing about stored state, you can put a lock on it.
In my experience, this is not a big issue in practice. Production deployments should be done through some kind of CI/CD, and it naturally serializes builds.
However, nothing stops you from adding locking without doing the full state management.
this is great, but I would argue the biggest issue with infrastructure as code is this: the structure and syntax for AWS is entirely different from Azure is entirely different from GCP. Instead of abstracting to CSS, I would argue modeling what Bytecode did in java for multi-operating system, we should do for infrastructure of code. That way, you could easily replicate in different environments, free yourself from ve…
"This is what I want from infrastructure as code and I have yet to see it." If you sit down with the terraform specifications for an AWS instance, a GCP instance, and an Azure instance, and start trying to write that harmonization, you will rapidly discover why for yourself. Even just trying to specify a network setup and putting an instance on the public internet is impossible to harmonize, without making something…
- Minimal amount of Terraform to deploy Kubernetes (which is different for each cloud provider)
- Helm (or similar) for deploying to Kubernetes
But then you have Kubernets to deal with.