Jam Notes #3: Integrating Terraform with Kubernetes

Contributions by Michael Levan and Chad Crowell

Welcome to our note series on our weekly Jam sessions, where we cover relevant DevOps topics with rotating guest speakers.

To save you time and energy, we’ll be uploading each Jam session topic’s notes, along with helpful tips.

For the week of May 12th, we covered Integrating Terraform with Kubernetes.

We talked with Michael Levan and Chad Crowell about their thoughts on which tech stacks to use, the implications of Kubernetes on enterprises, and best practices.

Join our Slack to stay in the loop about our future weekly Jam Sessions on DevOps topics.

1. Which IaC tech stack do you use or recommend?

Chad: Use a tech stack that allows you to simplify things that require less maintenance and human interaction. Automate as much as you can so you can work on more programming tasks. Write declarative code (instead of imperative) and have the system figure it out, so use tools like Terraform and Kubernetes.

Michael: What the old generalist used to be is the new niche. Now you have to have 8–10 tools. My tech stack right now is containerization like Docker, Kubernetes, Terraform, and I focus on AWS over Azure. My take is, don’t focus on the platform, focus on the technology because at some point Terraform, Kubernetes, and Docker will go away. I consider myself the containerization guy.

2. Where do you delineate the processes on where Terraform is better for a certain process versus Kubernetes for certain processes?

Chad: Kubernetes is the new baseline — you don’t have to choose Ubuntu versus RPM or which machine to run this on, which database, infrastructure, or cloud to choose. Kubernetes creates a new baseline to build your applications. When you build an app, ask, where’s the best place to run this? In some cases, Kubernetes may not be the best option. There are so many options, what tool is best suited for which environment, you have to make the best choice for what that environment requires. From a developer standpoint, Kubernetes is simply the interface where you’re building the application.

Michael: There is no competition between tools because there’s a right tool for each job, be it serverless, container, structureless code or CDK.

3. Kubernetes and its implication on enterprises?

Chad: I’ve been using Kubernetes since 2017 and while it’s not a difficult tool to master, it can be quite complex because it is abstract from bare metal. Let’s say I’m a business owner and I make a decision that we’ll use Kubernetes — I’d hire a bunch of SREs but my expectation is not that they know Kubernetes and nothing else. They would have to be all-rounded — they have to learn when things go wrong, where the logs are, where to go to solve those problems. Kubernetes is not the silver bullet — you have to know other tools like Linux and know what to do when things go wrong.

Michael: DevOps is hard. Cloud is not an easy thing. Practicing DevOps from a tech or cultural perspective is not an easy thing. It’s not easy to break into DevOps.

Mark: We have to understand why we use the tools. We have to ask, have we used due diligence to assess if this is the right way to go or are we just jumping in on the bandwagon

Michael: When I first started my career, I was in a terminal, troubleshooting. I’ve never installed a Linux system before. Now in this current age, this layer of abstraction makes it so much harder for people to break into DevOps. Let’s say we talk about the difference between bytes and bits. This is a fundamental concept that a lot of people can’t get. We need to get around that layer of abstraction in cloud tools. It’s going to be hard to find good engineers in a few years.

4. Do you think there’s going to be an education gap in the approach of problem sets?

Michael: The gap is already there — there are a lot of open jobs yet it’s difficult for organizations to find good engineers who know the fundamentals. This is the reason why I’m going into education more so than consulting. The current tech space is setting people up for skills/tools fragmentation.

5. Can you give us examples of when Kubernetes is misused?

Chad: If you have a large monolith running inside a pod or container, the largest node you’re going to get is not the best use case for Kubernetes.

Michael: The question is, why move from Kubernetes to container? Don’t chase the buzzwords or tools. If you’re chasing a buzzworthy tool, let’s say you have your app running on a VM and you want to make it run faster on a container — chances are you’re running it slower.

Chad: Don’t start with Kubernetes. Don’t start with serverless. Build the app and assess if Kubernetes or serverless is the right fit to deliver your product better.

Michael: Let me play devil’s advocate here. Imagine this scenario — you’re starting a new company, you don’t have a product yet and no funding. Would you recommend someone to deploy on a VM first and then move it to a containerization environment? Or would you recommend they run it straight on containerization?

Chad: I’d say build on your local machine first.

Raphael: I believe in doing something manually first before automating so you know what’s happening.

Michael: When learning cloud and DevOps, do it manually first before automating it. You can’t automate what you don’t know. Last month I was incorporating the IoT port for a client. At first, I was taking manual logs of streams coming in from the IoT core. After that, I hooked up the IoT stream with Kinesis and now I’ve constant logs coming in, I know where those streams are coming from.

Chad: So you need to ask, why are we using this? Does this make sense? With every assignment, ask 7 layers of why? That curiosity will take you above and beyond your career. Learn the fundamentals of Linux and why this is behaving in a certain way and you discover better ways and methodologies

6. What are your thoughts on the evolving ecosystem around the interplay of Terraform and Kubernetes?

Chad: ReAct and RPM provide a way to install the essential components. As Kubernetes evolves, so does the need and requirement for a package manager. I advise people to use Helm.

Michael: I like that I can take my containerization and turn it into a package.

7. Last words

Michael: If you’re new to DevOps, take it slow, don’t learn 5–6 platforms — that causes confusion. Focus a month or two on one thing, then go into another thing. Say Python, containerization, then CI/CD. Give yourself 6 months to learn: a month to learn Python, then apply that knowledge of Python to containerization, and then move to containerization knowledge to CI/CD.

Chad: I’d encourage everyone to be curious when approaching any tech stack or tools, for example, why is Kubernetes important or not important? That curiosity will take you far in your career. Take what you learn and share with others. We used to have gatekeepers and people hoarding information in the past but now it’s all open source knowledge and sharing.

8. To sum up:

Choose the right tool for the job and don’t jump on the bandwagon because it’s the latest tool. DevOps is not hard but it is complex. Take your learning journey slowly, with one tool/platform at a time, and take a month or two to learn a tool and move on to the next, and practice integrating one tool to another.

If you’re looking to try a new (free) tool to spin up your infrastructure easily, we recommend that you check out InfraSketch.

And, if you’re looking to get more Infrastructure as Code tips? Join our Slack community to connect with other DevOps professionals.

PS: Did you know we have weekly Jam sessions on DevOps topics? The weekly invites go out on our Slack and Twitter channels. We hope to see you there!