Seth Vargo, Director of Technical Advocacy at HashiCorp, will talk at ASAS about Graph Theory and Infrastructure as Code. Benny Cornelissen, Infrastructure Architect at Avisi and user of HashiCorp tools, sat down with Seth and asked him all about his work as Director of Technical Advocacy, creating workflow tools at HashiCorp, and the importance of guiding principles for a product company. Seth and Benny had a really interesting talk, so the interview is quite long. Therefore we made two versions: a short version (estimated reading time: 7 minutes) and a long version (estimated reading time: 25 minutes). Decide for yourself!
This is the short version. Are you dedicated? Let's take you to the long version!
Short version: You are Director of Technical Advocacy at HashiCorp. What exactly is that?
I have been at HashiCorp for 3 years now. I'm employee number 4, so I built a lot of these tools and still work on a lot of them. However, as the company evolved, we hired more people who are specialised in different areas. We have people working on Terraform full-time. Me being a generalist and working on everything didn't really scale.
At the same time, we're an Open Source company, and a lot of our early success was driven by community. Our founders, Mitchell (Hashimoto, red.) and Armon (Dadgar, red.) were very active in that community, speaking at conferences, etcetera. This evolved into a full-time advocacy role. What I do is about 20% engineering, 80% speaking at conferences, teaching workshops, meeting with customers, and working with our product teams to help prioritise and identify areas where the products should improve.
You built Consul Template shortly after joining HashiCorp. Was it difficult to build a new product so quickly after joining?
That's actually a pretty funny story. When I first joined I would have called myself a Ruby developer that does public speaking. I didn't know anything about Golang, the language HashiCorp writes all of their tools in. My introductionary assignment was to write what is now Consul Template, in a language that I didn't know, with a tool that I wasn't familiar with, with basically no resources. They had never onboarded anyone before, they had no idea what they were doing (laughing). Nowadays we have very well-defined procedures.
It definitely was a bit stressful. I was dealing with multiple things. The language itself was something I wasn't familiar with. I didn't know where to look for things, or Google with a language called 'go'. If you Google for 'go array', you get no results for what you want. I learn through example, so that was quite frustrating. I asked for a lot of help, which was interesting as well. In my previous role, I was the expert and didn't really need to ask for help, and now I was in a position where I felt kind of dumb.
Consul Template became one of the main 'glue' tools between all of the HashiCorp tools. The de facto way to pull information from Consul or Vault onto the filesystem. It's kind of crazy to think that this tool that I wrote in a language that I didn't know, that interacted with another tool that I didn't know anything about, has actually become one of our flagship tools. That's really cool.
During your talk at ASAS we will probably get to see a bit of Terraform. For those people that don't know Terraform, can you explain how Terraform is different from other well-known tools like Puppet, Ansible, or Chef? What can people expect from your talk?
Terraform is a tool for managing infrastructure as code. When you think about infrastructure, Terraform can manage everything that has an API, and it provides lifecycle management for those resources. Puppet, Chef, Ansible, and Salt manage a machine. It installs Apache, the user, and some config files. That's really not Terraform's responsibility, it doesn't do that machine layer. It's managing your infrastructure. How do those 10 instances that you provisioned with Chef get connected to a load balancer? And how does that load balancer get connected to a DNS entry? That's what Terraform helps you model, in a single text file.
And by capturing that in a text file, you can enable Github pull-requests, code reviews, automatic reporting, a lot of features you'd associate with traditional software engineering. You can bring that to Terraform. Terraform also separates the planning phase from the apply phase. When you're dealing with thousands of machines, and you want to change something, you want to see the result of that roll-out, before you do it. Terraform's plan phase shows you what is going to happen, before it happens.
The last pillar that separates Terraform from the other solutions is the graph theory, which is something I'm actually going to spend a lot of time talking about in my talk. The graph theory is how Terraform uses the mathematical construct of a graph to model these complex relationships between infrastructure and infrastructure providers. And by using this graph, we get amazing parallelization. We can couple resources across cloud providers, and we see more and more users running across clouds. Terraform composes those resources across clouds, in a single text file.
Also, because Terraform uses this graph plugin model, we can manage anything with a API. One of my favorite examples is that you can manage Github repositories and permissions using Terraform. You can manage your DNS. You can submit Kubernetes jobs. Anything that has an API. That's why I think Terraform really enables Infrastructure as Code, being able to compose all of these resources together, collaborate on these changes, and ultimately easily roll-out production or production-like infrastructures.