loading...
Cover image for Infrastructure as Code: A beginner's perspective

Infrastructure as Code: A beginner's perspective

fedekau profile image Federico Kauffman ・6 min read

Originally published in WyeWorks blog.

A couple of months ago, I came to realize I might actually like DevOps. I wasn’t sure what to do, so I talked to the VP of Engineering at WyeWorks. Following that conversation, we found a way for me to work in a DevOps position for several months and try it out.

I left the project I was working on at that time and was given a month to learn some basic stuff so that I would be somewhat useful in a DevOps job. And that’s exactly what I did. Beginning January 2nd of this year, I’ve been reading up on and doing DevOps work 5 days a week, 7 hours a day.

In this post, I’m going to discuss my perspective on IAC (Infrastructure as Code), what problems it solves, and how it can be implemented. I will also share some resources for further learning, as well as briefly present Terraform, an IAC tool.

What does Infrastructure as Code mean?

As the name might suggest, IAC is about writing code that describes your infrastructure, similar to writing a program in a high level language. It allows you to automate the process of provisioning infrastructure using tools that are proven to work.

How does it help you?

IAC allows you to automate, test, and reuse code pertaining to the infrastructure you are working on. You also have the option to version control your infrastructure code and check it alongside the code that will be managed. You can likewise review and test code, and generally-speaking follow all the good practices you would normally with your codebase.

You might be thinking: Ok, that all sounds great, but can you please give me a concrete use case?

I can give you two. 😁

Case 1 - Simple web app_1, app_2, app_3, ..., app_n

Imagine you are working for a company that builds basic web apps for its clients. So, what does a basic web app require? A web server and a database (I am oversimplifying) should come in handy. Every time you gain a new client for a web app, you visit AWS (or whatever cloud provider you use) and, after clicking around some, you end up with 2 VMs: one for running your app, and another for the associated database.

Oh wait, I forgot, you’ll want at least two copies of this infrastructure: one for production and one for staging.

Now that you have two copies of the same infrastructure, you can start deploying the code for that client.

Two months go by and you have another client that needs the same infrastructure, so there you go again, clicking around in AWS to get that up and running.

Instead, utilizing IAC, you can have a module that does all the heavy lifting for you. When it’s time, you run that bit of code and in a couple of minutes you are good to go. Need to update all client infrastructure at once? No problem, just update the module, run it, and you’re all set!

If you have been doing this by hand in AWS, then you can probably already see the benefits of having IAC. But if you don't believe me just yet, read the next use case.

Case 2 - Going crazy with a complex app

You came up with a great idea - a really cool web app - and it all started off simply enough, but now you have a lot of clients that rely on that app. In this case, one web server and a single database won’t be enough.

You begin by adding a load balancer and another web server, and you document the process. Some time goes by and you need to add another server, so you follow the process in the document and you're done.

The following month, you realize that running only one database server is not enough and you add a replica.

Then, you need to move some of the workload off the main servers, which means you need a message queue and a server to run workers. You do it all by hand but forget to update the documents.

Some months go by and you get to a point where you need to add more queues and workers, but since you forgot to update the document the last time around, it’s not so easy to do it in the same way. You get it done, and it works, but now the queues and workers have slightly different configurations. This is known as configuration drift.

Later, you decide to add some caching levels to your app, and since you require Redis/Memcached, you’ll have to add more servers for those services. You’ll also need to configure S3 for your static files, a CDN to serve those worldwide, and Route53 for your DNS.

By this time, the company has grown and it’s time to create IAM roles and users for the new developers, then give them the correct access rights.

You also want increased reliability, so you look to allocate more servers in different datacenters. Finally, you go nuts and close the company.

The conclusion of this last example is admittedly a bit catastrophic, but imagine trying to maintain that number of servers manually. That would not scale well.

Should you be utilizing IAC?

As with everything in tech, the answer to this question is it depends. I personally can't imagine a project that would not be bettered through the use of IAC. In my opinion, if you have a chance to incorporate it, you should give it a try and find out for yourself!

Perhaps if you are already using something like Heroku for really simple apps, implementing IAC would create too much overhead. However, if your Heroku project grows beyond a certain size, you may benefit from this kind of tool as well. Take a look at Terraform: Heroku Provider, as an example.

Terraform

Terraform is an IAC tool from Hashicorp that solves problems presented by the previous cases and more. As they say on their site,

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.

For example, you have a load balancer with 5 VMs attached to it. Run the following simple code to return to that same state every time.

resource "aws_elb" "frontend" {
  name = "frontend-load-balancer"
  listener {
    instance_port     = 8000
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }

  instances = ["${aws_instance.app.*.id}"]
}

resource "aws_instance" "app" {
  count         = 5
  ami           = "ami-408c7f28"
  instance_type = "t1.micro"
}

That’s awesome! Imagine how many times you would have had to click to do all that by hand. Definitely quite a few!

Utilizing code similar to this, I was able to recreate the second case I presented earlier in just one week, which is pretty amazing! I’m sure it would have taken me at least twice as long to do it manually.

Conclusion

Your infrastructure is as important as the code it runs, so I recommend that you treat it the way it deserves to be treated; you should complete reviews, versioning, tests, and so on.

Managing infrastructure by hand is difficult, even if you are disciplined and document everything. After all, you are only human - you could forget something someday, and that day you will regret not using IAC tools.

You can get started by managing something simple in your app with an IAC tool, then gradually migrate other things over.

If you have the opportunity to use Terraform or any other IAC tool, consider it a great way to improve how you manage your infrastructure. It can enable you to do great things quickly!

If you have questions or comments, please post them below!

Resources

  • Infrastructure as Code: Managing Servers in the Cloud by Kief Morris. Link
  • Terraform: Up & Running By Yevgeniy Brikman. Link

Posted on by:

fedekau profile

Federico Kauffman

@fedekau

CTO at Streaver. Passionate Software Engineer. Host and Co-organizer of the Montevideo JS meetup

Discussion

pic
Editor guide
 

Terraform is a fantastic tool, makes getting up and running with semi complex infrastructures very easy. I've been pretty of a team that introduced it to a business with great success. I love how it can just work out the differences between a current setup and the changes you've made and only apply the differences.

Have you looked into containerisation with docker/kubernetes/etc?

 

I have been learning about kubernetes, it is awesome! You could use both tools in conjuction, provision with Terraform and deploy with containers and kubernetes.

 

That's cool, would love to read another article about using those together then :)

 

I also started down the DevOps part for nearly a year now. My reaction back then was pretty much like you said: how can anyone not be thrilled with having the entire infrastructure as a simple text file you can change and store?

Kinda sad though that sometimes DevOps get abused and turned on its head i.e one person/team taking care of it while the development team carrying on with just coding and stuff. I'm hoping I could change that in my organization for the coming years :)

 

Hopefully you will! Good luck 🤞

 

In my opinion, any infrastructure that's not going to be thrown away very quickly (and even then I'd argue that codifying it is still probably better) should be expressed as code. I once worked somewhere where everything was provisioned by someone clicking through the AWS control panel and it was an enormous mess. The repeatability of infrastructure expressed as code is invaluable, not to mention the documentation aspect of it.

You mentioned at the start things like, "DevOps position" or "DevOps job", and I'd have to assume you left your current organisation to do that. DevOps is a culture not a job title or a team within a company. Either everyone is doing DevOps or no one is. I guess that's something to take up with WyeWorks... :)

Developers should have full operational responsibility for the code they write, and that has to include the infrastructure it runs on. Infrastructure as code is a great tool for achieving that.

 

I've been there too, AWS is too complex to be clicking on it! Regarding DevOps I agree on what you said ☺

 

I love IaC. It has really changed the way I code, and I don't like it when I have to go back and work on some of our older code that doesn't take advantage of it.

In our organization, we use a mix of Terraform and AWS CloudFormation (we're moving towards being a mostly AWS shop). We've also been developing our own abstraction on top of CloudFormation called Handel, which abstracts away all of the IAM permission wiring for us, because that always seems to be the hardest part of IaC in AWS. It's really been fun to watch as IaC has started to change how all of our developers work - many of them can't imagine doing anything without it!

 

Totally agree 👍

 

If you want to get started with Terraform, you can check out my article on here, or at olicole.net/blog/2017/07/terraform... :)

 

Great article. It would be awesome to give some example good practices of how to do common tasks - esp. stuff like migrating/replicating databases

 

Great idea 💡. I will try to write more about this topic, so you might see something like that in the future ☺