Hacker News Reader

Comment by zwkrt | Hacker News Reader

Sidebar: does anyone else get the feeling that infrastructure as code is just cloud vendor lock-in by another name? Especially since the output of the code ends up being wild unstructured JSON/YAML files with no spec or discernible schema.

My favorite is how in the Microsoft toolchain you can build a CI pipeline in a visual UI on the right that automatically updates the YAML file on the left. “We know you don’t want YAML, but we also know your boss says you need infra-as-code...”

View on HN

Infra-as-code is mainly just a method to force people to write things down, rather than the default of nobody writing anything down, and people just manually making changes that nobody else knows about, making it really difficult to manage changes. Even a bash script that creates an ec2 instance is infrastructure-as-code.

OTOH, I kind of hate Terraform now, because you can use it in a way that will surprise you and blow up, leaving a mess that you have to clean up manually. It's more "infrastructure as code" than Ansible, but Ansible will at least attempt to fix things that aren't "right". So everything that has a certain label is not by definition superior to all alternatives. (I actually hate both tools for different reasons, but they have their uses)

You might want to look into Terraform [1], which works across multiple cloud vendors, with pluggable open-source "providers" facilitating the communication with the backend cloud platform.

[1]: https://www.terraform.io/

Terraform is great but if you want to change to a different cloud provider you pretty much have to rewrite everything

Terraform is okay, if you don't value things like "loops that aren't an awful hack", but in 2019 Pulumi is significantly better and their cloud-agnostic implementation actually kinda works okay.

We should make an effort to redefine how we use 'infrastructure-as-code', because right now Pulumi/Troposphere/Azure PowerShell and Ansible/Terraform/etc. are indistinguishable when viewed that way, despite the former being much more useful.

Infrastructure-as-verisonable-flat-configuration-files should not be thought of as infrastructure-as-code.

Haven't heard of Pulumi before your comment but will be sure to check it out now :)

Pulumi would be perfect if the community edition was simply self hosted without support vs free with a single user only. At a stingy small org, I have no hope of ever using it instead of simply installing Terraform when the starter edition excludes secrets management and the API.

It's a bit rocky and I've been filing bugs to help, but S3 state support is strictly no worse than Terraform's and supports secrets just fine.

That's good to hear! Admittedly the main issue for us is convincing others that 1 user at $50/month is justifiable.

S3 support's free. It definitely works well enough.

> Terraform is great but if you want to change to a different cloud provider you pretty much have to rewrite everything

While true, the process is closer to a variable name refactor than to a complete re-write. With Terraform, you have the stack described in code and the resource names translate cleanly across cloud vendors. Certainly more so than a word doc describing infrastructure setup steps.

Yeah? If you build on top of popular open infra that is hosted by a variety of providers, it shouldn't be too hard. You can build on top of K8s, Postgres, and S3-alike APIs, then use Terraform to move across AWS, GoogleCloud and DO without having to rewrite a thing.

You still need to have pretty intimate knowledge of your stack provider though. Terraform is a way to formally express your infrastructure via code, but you still need to know how all of your components need to be configured and wired together. It doesn't give you any of that.

You’re using a cloud provider; you’re already locked in. But you’re also locked in like you’re locked in by your OS or your programming language or your ISP, which is to say: the whole point of cloud providers is to abstract away a certain set of things. You can look at it as lock-in, or as using a platform that enables you to solve the problems you care about. You can look at your OS as lock-in, or a tool that enables you to solve the problems you care about. If your goal is to provide cloud infrastructure quickly and easily and without building a data center, then lock-in doesn’t really matter. And if it does, there are more expensive, more appropriate options.

Lock-In is defined as, "an arrangement according to which a person or company is obliged to deal only with a specific company."

If you mean in terms on Kubernetes, the idea is identical JSON would work on AWS, GCP, Azure, Digital Ocean. If you want to go cloudless, you can run k8s on your own infrastructure. And if you want to run on your own infra, the need for configuration doesn't go away. Given how open the specification is for the JSON documents, I find it difficulty in characterizing it as lock-in. The configuration JSON is highly reusable in variety of contexts, with the examples I gave above.

How is the opaque visual UI better? IaC doesn't unlock you from a vendor but at least you have a reproducible config file you can check in and version.

I tried Terraform this weekend and it was awesome to use. Spinning up a new ec2 instance was very quick. Almost just as quick when you spin up multiple instances.

It supports "providers", which are interfaces to the different vendors (aws, foogle cloud, etc), and "provisioners", which are frameworks for configuring a running instance (chef? Docker? Zookeeper?)

Plausibly, if what I want is "start a kubernetes cluster with an ingress and a database", that's portable to every cloud provider. However, with terraform, you have to write platform-specific code to do this that isn't portable between providers.

No, the skills of your people are the lock-in.

Reply on news.ycombinator.com