Hacker News Reader

Comment by itronitron | Hacker News Reader

anyone care to take a stab at defining what the author means by 'infrastructure code' ?

Infrastructure as code is starting to be a big thing. Lets say you want to provision a new AWS EC2 instance, you could go into the UI and click around to do it, but at a large company, that's probably not the best idea. That's not really scaleable and leaves a lot of room for human error.

You could instead use something like terraform, which allows you to write code specifying your requirements and then run that code. This allows other devs to review your code, takes a lot of human error out of the equation, and is much more sustainable.

When he says infrastructure code, I think he means code that keeps the infrastructure running.

Some examples that come to m would be terraform files, dockerfiles/docker-compose files, jenkinsfiles, bash scripts, etc. Basically, code that keeps the servers running.

So a JCL then?

The largest code base I worked on (a map reduce based billing system), also had for the time early 80's a fairly complex set of JCL that could compile and build all the systems module's on dev and also push it out to the 15-16 or so live systems.

This also handled all the glue that held together the map reduce.

It’s not procedural. You write what you want your infrastructure to look like in the case of CloudFormation yaml or JSON.

The first time you run your template it creates all of your infrastructure and is usually smart enough to figure out dependencies.

After you make changes to your template and run it again it knows based on the changes in your template whether it can modify the existing resources or whether it needs to delete and recreate your resources.

Procedural certainly can be "Infrastructure as code." It just isn't the most modern way to do it, due to additional complexity and the potential to be more error prone. I'd certainly prefer CloudFormation over writing a bunch of python/boto code, but it could be done.

Interestingly, Dockerfiles brought back a bunch of procedural configuration management. We had migrated to ansible for all our server-level configuration. But as we've adopted docker/containerization in recent years, simplifying our applications (now separate containers, rather than severs on common servers) has such a reduced level complexity such that simple docker files with `apt-get install foo` are much preferred.

Most people probably think of Terraform[0] or Fugue[1] here, but it also includes the more venerable likes of CloudFormation[2] and OpenStack Resources[3], both writeable in Troposphere[4].

It also includes any random mess of shell scripts and the like that manage the lifecycle of infrastructure.

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

[1] https://www.fugue.co/

[2] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

[3] https://docs.openstack.org/heat/latest/template_guide/openst...

[4] https://github.com/cloudtools/troposphere

The first sentence links to gruntwork.io[0] where 29 different tools/projects are listed. Seems to be provisioning and configuration for existing services (most of them Amazon, from the looks of it). There are several Hashicorp projects as well, including Vault, Nomad.

[0]: https://gruntwork.io/infrastructure-as-code-library/

It's code that provisions or configures VMs, containers, cloud resources like RDS, etc. Usually this is accomplished using tools like Terraform, Ansible playbooks, SaltStack, Kubernetes, and the many other similar tools.

Code that defines what your servers/services are, what they should contain, where they should be put, how they should interact.

E.g. a simple plan in Terraform gives you the possibility to say how many of what instances should be up in given zones.

Edit: every piece of tool used here is used for infrastructure, controlling them is infrastructure code: (it's massive!) https://landscape.cncf.io/format=landscape

Reply on news.ycombinator.com