
Infrastructure as Code, Part One - based2
https://crate.io/a/infrastructure-as-code-part-one/
======
royjacobs
What I find unfortunate about infrastructure-as-code tooling is that a lot of
the tooling isn't actually using code, but instead uses esoteric configuration
languages. Indeed, the article refers to Terraform with its custom syntax.

Imho tools should use actual code (whether it's TypeScript or Kotlin or
whatever) instead of reinventing constructs like loops and string
interpolation.

Thankfully these tools are getting more popular, because frankly I can't stand
configuring another Kubernetes or GCP resource using a huge block of
copy/pasted YAML.

~~~
amq
Could you name some of those code-based tools?

~~~
ryanworl
[https://www.pulumi.com/](https://www.pulumi.com/)

------
mverwijs
Nice piece. Looking forward to Part II.

What I am missing (often, in these type of articles as well as in actual
production environments) is the fact that if you develop (infrastructure)
code, you also need to test your (infrastructure) code. Which means you need
actual infrastructure to test on.

In my case, this means network equipment, storage equipment and actual
physical servers.

If you're in a cloud, this means you need a seperate account on a seperate
creditcard and start from there to build up the infra that Dev and Ops can
start deploying their infra-as-code on.

And this test-infrastructure is _not_ the test environments other teams run
_their_ tests on.

If that is not available, automating your infrastructure can be dangerous at
best. Since you cannot properly test your code. And your code will rot.

~~~
stingraycharles
I found that Kubernetes + minikube (or a variant of that) is a fairly
straightforward way to handle this. Teams / developers can easily set up a
local testing environment, product owners can QA that way, etcetera.

This of course depends on your level of lock-in with various cloud
environments.

~~~
pm90
IaC tools often handle more than kubernetes, but agreed that k8s is a
fantastic way to get reproducible behavior which is absolutely imperative for
testing.

This is kinda why I love Google Cloud and don't see myself moving to another
cloud provider until they match GKE. I want all developers to throw everything
into GKE, and Operations manages only the VPC's, firewalls etc. Developers get
complete ownership over compute (and networking within the cluster) while
broader network management can still be managed by an operations team.

------
cpach
Nice article! What Crate advocates here might be common sense to a lot of
people here on HN, but I can assure you that there are lots of people in
leading positions out there who has no clue about this paradigm. Hopefully
some of them will read this article.

~~~
1_player
I might be one of those people that doesn't completely grok IaC yet. I
understand the necessity of configuration tools such as Ansible, I wouldn't
live without it, but in the case of my company (~15 apps, 20 servers) I still
don't understand the use case of orchestration tools such as Terraform.

All our servers configuration is managed through Ansible, apps are
containerised and run on Kubernetes (on CoreOS, so even less configuration
required), apps are deployed automatically with CI scripts.

Why would I need to describe the hardware/infrastructure as code? I create
VPSes manually, once in a blue moon, and they just get added to our K8S
cluster, using the same Ansible template. It takes 2 minutes from VPS creation
to adding the new node to the cluster. It'd be nice to describe in code the
exact hardware provisioning, but that can be done easily with a couple lines
in the internal documentation. And actually, having heterogenous server sizes
might be a feature, to be able to schedule less demanding apps on less
powerful and cheaper servers.

What benefit would Terraform give me? Not being snarky, I just don't know how
to fit it in our process.

~~~
pm90
\- _Scalability_ since you're a small shop, it doesn't seem a huge deal to
have to setup networking and other scaffolding manually. But as your company
grows and more teams join, will you provision these things for every team by
hand? What if they want to experiment with different networking
configurations?

\- _Disaster Recovery_ : Imagine for whatever reason your VPC is completely
destroyed, all your VM's are gone. You still have data backed up (you do
backups don't you? :)). Your company has to inevitably be down for some time,
but how long would it take to restore everything? Terraform can reduce this
from days/weeks to minutes; all configuration is there in code, is
reproducible. Even if you don't/can't use terraform itself, you still have
captured all your infra config information in code and not just in a Google
Doc/Evernote/Post it notes.

\- _Audit Trail_ : You want to empower developers to make changes to
infrastructure without opening a ticket and asking you to do it. But if they
don't open a ticket, it might make your compliance story much harder. If they
do open a ticket, you now have a huge ticket backlog so you hire more
engineers .... kinda relates to the point about scalability. Using Terraform,
and enforcing infra changes through terraform, you have a super simple audit
story, and will know exactly who made the changes, when they were made, for
what reason etc.

\- _Infra Convergence_ : Its a fact of life that you need to make temporary
infra changes for fixing fires, hotfixes, super important custom customer
request etc. If you allow your infrastructure to be cluttered with these one
off changes, it will be messy, developers won't give a shit when making new
changes, and often everyone will have permissions over everything. Using
terraform, every time you make changes to infra, you discover these manual
changes and either revert them (if they're one offs) or commit them to code
(if they're meant to be permanant)

I'm a new user to terraform, and it certainly has its problems (its still 0.*
for chrissake). But... it has been a very useful tool when used correctly and
with discipline.

------
oogali
_You spend the rest of the day investigating what went wrong. Eventually, you
figure it out. Somebody logged on to the third machine last week and manually
updated some of the software. These changes were never propagated to the other
servers, or back to the staging environment, or dev environments._

I'm sorry -- how many people are still doing this in 2019?

~~~
detaro
Many, especially for tweaks after installation.

------
LaserToy
I’m sorry, but infrastructure as a code is a fake news.

Most popular tools offer infrastructure as a config with some horrible and
limited scripting language (in some cases even JSP doesn’t look like a
horrible idea - hello helm). Declarative VS Imperative Holywar is getting a
bit old (like any other tech war).

~~~
alkonaut
The best language is “the one you know” which is why I think pulumi looks like
the best answer so far.

