Mark Tinderholt: The Azure Terraformer on Cloud Strategy and IaC Tools

Hi, everybody, and welcome to another great episode of the IEC podcast. I'm Ohad Meslis, and today we have an amazing guest, an author, and an expert in many topics, Mark Tinderholt. Hi, Mark. Hey, how's it going?

Pleasure. Great seeing you. Every time I'm an expert, I get a little nervous, you know, experts. So we will see today.

So Mark, introduce yourself for those who still don't know you, please. My name is Mark Tenderholt. I work for Microsoft. I got to tell you that I'm not in sales, so I'm not going to sell you anything.

But I'm a lowly, lowly engineer trying to make Azure better. That's what I do at Microsoft Azure. I don't do anything with Terraform or really like infrastructure as code other than use it in my day-to-day job. So I'm a user like other people out there, and I'm just pretty passionate about it.

I feel like Azure was a little bit behind our friends, you know, on that big bookstore in the cloud. So I started a YouTube channel called the Azure Terraformer to spread the love, spread the knowledge of this great tool called Terraform and just how to handle managing infrastructure and managing our workloads on Azure more effectively. So that's me. Thank you so much.

So before we talk about IAC, let's talk about the cloud. then you know Azure pretty well. Let's say I'm CTO of a new startup, and I'm wondering whether I should use GCP, AWS, Azure, or maybe other options. What are the main reasons, in your opinion, that I should choose Azure?

What are the best use cases that you think Azure provides a lot of interesting value to its users? Well, I mean, Azure is a big place. And, you know, honestly, like the the hyperscalers each are big places. So that's a that's a pretty tough question just to answer, like in the generic.

It comes down to like what human capital you currently have, you know, what workloads that you want to that you want to employ within your startup or whatever, whatever your business might be. what existing relationships that you might be able to leverage. So organizationally, I think there's a lot to it, a lot more to it than just like, you know, the technical wizardry of things. But they're all pretty much rock solid platforms.

And in our Microsoft, our CTO, I've heard him say this, you know, we don't like Microsoft doesn't have to be the only winner to be a success in the cloud. We need to be one of the winners, right? So I think it's a multi-cloud world. And, you know, I think each of the clouds have a lot to offer.

I'm trying not to give you like a non-answer here. But, you know, like Azure has a lot of great things that are, I think, a lot oriented towards like the enterprise. One of my favorite features is Azure Policy, which I often call as one of Azure's superpowers, which I don't see it exist anywhere on the other two hyperscalers. But that one in particular, if you're running a business at any sort of scale, it really helps kind of manage your cloud landscape.

And there are interesting points of friction for the infrastructure as code practitioner as well, which I often talk about as well, because in the Azure space, we often run into, you know, beating our heads against our benevolent overlords, you know, that are managing policy, right? So there's some challenges in that as well. But we have a comprehensive portfolio of offerings from general compute data, storage, all sorts of stuff. So it's like pick your points.

What do you want to do? And what tech stack do you want to rock? Absolutely. All right.

So let's start zooming in on ISC. So let's say I chose Azure as the only or one of the clouds that I'm using. And I have a lot of microservices and a lot of different environments that I need to manage. So, you know, this is the IAC podcast.

We strongly believe that instead of doing click ops, there is a better approach of managing your infrastructure with code. Now, in Azure, for what I know, you can represent that infrastructure with different types of code. You have the Terraform slash OpenTofu approach. You have the ARM templates.

You have the Bicep option, which is something relatively new by Azure, I think a couple of years ago, and other options such as Pulumi. When you talk with your Azure users, I know you're a big advocate of Terraform, but can you explain why you believe Terraform is the preferred option to managing Azure with code And what do you think about the other options that I mentioned What are the pros and cons maybe if you'd like to share your thoughts? Sure, sure. Yeah, I mean, Azure, I often refer to as my favorite cloud.

It was my first cloud. I started working on Azure way back in the Red Dog days, 2010-ish. Um, but I was rocking ARM templates, you know, and doing a fair, a fair bit amount of click ops myself. Um, but, uh, I discovered Terraform, um, when like working, uh, you know, with, with AWS.

And, um, once I realized Terraform could also do Azure, I was like, wow, okay, this is sweet. I, I only need to learn one tool, one ecosystem, one release motion, one language of like getting work done. But I might have to describe it, you know, with its own provider in a different like its own language, so to speak, that's specific to that. So that that really appealed to me about about Terraform versus versus ARM.

and then, you know, today Bicep. And Bicep and Arm are very tightly related. There was a design decision when the team first developed Bicep that it should compile down into Arm. So, like, in that sense, you know, Bicep is a very beautiful and elegant kind of abstraction of Arm templates and being only, like, essentially Azure-specific.

Now, I don't follow Bicep too closely, but I am aware of some efforts to potentially have it manage other control planes besides ARM. I think they've introduced EntraID and maybe some stuff with Kubernetes or something. I'm not sure. But so I think the idea of making it more extensible is there, but it's just not as, you know, vibrant as like the Terraform and OpenTofu ecosystem where you have, you know, tons and tons of different providers that manage all sorts of different control planes.

And I guess the solutions that I work with, it's a composition of different technologies. Azure is just one of them. Then you layer stuff on top of that, whether it's Grafana, Kubernetes, et cetera. and so having having a automation tool that can kind of kind of not be siloed into one particular control plane and kind of branch out lets you have one way of managing your configuration just seems to make a lot of sense to me this might be now the other the other aspect like why not Palluni or why not like you know CDK stuff like that this is this might be like a controversial opinion, but I know there's, it is like, I have a good friend of mine who loves his CDK and he's in the AWS space and there's a whole subculture of pieces.

Just a shout out that one of the previous episodes we talked with the creator of CDK, just a shout out to that. Please go ahead. Yeah, I mean, using an imperative like Turing complete language does not super appeal to me just because maybe because like I'm an OG.net developer and I've seen the amount of layers of abstraction, like interfaces and like inversion of control and all sorts of stuff that can go into like traditional C-sharp Java code.

And then trying to manage infrastructure with that type of like layered, you know, technical elegance slash complexity just seems like a pathway to all sorts of pain. But so that the whole imperative Turing complete language approach that CDK offers has never really appealed to me. I preferred like the keep it simple, stupid approach of like just a very simple DSLR like HCL has to offer because then I can see exactly what's going to happen in my environment because it's all about like predictability there exactly so it's it's not about an application code you got you got all sorts of other like architectural things you got to consider scalability you know um things like performance and things like that but like i i the most the apex characteristic you got to optimize in infrastructure as code is predictability so awesome reliability so so you You zoom in on Terraform and how to manage Azure and sounds like others like Grafana solutions.

And you work closely with the community that wants to learn and to become better and better managing infrastructure. What have you seen in your career, in your journey, with your knowledge and experience when you talk with all of those users? What are they trying to learn? What are they trying to achieve?

And how do you just work with this community? How does it look like? I mean, there's there, there, the diversity of problem spaces is immense, which I think leads to different camps forming of like and we see it play out on Reddit all the time Like this is how you structure like a Terraform root module And you know and I think that just is a you know, a symptom of the reality that people are trying to solve lots of different problems, because guess what? Like the hyperscalers are really big places, right?

It's got a big umbrella. So you've got people that are trying to automate like data analytics workloads, people that are trying to do application workloads, people that are trying to do more platform engineering where you're laying down the network, laying down the core compute and stuff like that. And they're fundamentally different concerns, right, in terms of where they fit in the organization. So I think as I've engaged with the community, that's become more and more obvious to me.

Like I come from an application development background and I kind of fell into infrastructure as code because I wanted a repeatable, predictable way to deploy my software. But there's like so many different personas that use infrastructure as code for whatever. And they constantly come up with new ways that I've never even thought of. Like, oh, wow, what are you trying to do?

Why are you trying to do that? Oh, okay. Wow. That's interesting.

So it's, yeah, it's a very, very diverse world out there for sure. Awesome. And one of the things you've done recently is that you wrote a book about telephone and the space. Can you tell us a bit about the book?

Yeah. So I was approached, first of all, I've always wanted to write a book. And actually growing up, I always wanted to be an architect. an architect yes you're like George Costanza that's what you're trying to say Art Vendelay if you remember the name that was his fake character the architect his place in the Hamptons is better than mine I must say but yeah so I always wanted to be an architect but I never I ended up being a software architect so much in the same sense I always wanted to write fiction as a child I wanted like I looked up the Michael Crichton and Roald Dahl and I wanted to write books I ended up writing a technology book we were talking earlier like I'm under no delusions of grandeur right like I'm not right I'm not pumping out the next time fancy novel here but I was just you know trying to you know I think my perspective on infrastructure as code is more an application developer perspective like how do we apply software development lifecycle around infrastructure as code.

And it seems like a lot of the, I guess, zeitgeist within the community is, you know, folks that were in more infrastructure roles already that are now codifying, and maybe they didn't have like that software development lifecycle kind of background. And so I thought that was important to, you know kind of share with the community which is why like i kind of focus on implementing git flow and git ops using terraform and um that that was i think a critical aspect of the book where where you have and seeing everything work end to end and you work across multiple control planes hacker and azure um kubernetes and azure right um and not just like hey let's spin up some bms so to speak.

We still didn't mention, what's the name of the book? It's called Mastering Terraform, a practical guide to something, AWS, Azure, GCP, something. And that was another thing, I wanted it to be multi-cloud. I didn't want it just to be like 90% Azure and 10% AWS or whatever.

So I tried really hard to make sure that there was equal coverage for all three clouds, AWS, Azure, and GCP. Talking about mastering telephone, what do you think about mastering telephone five years ago versus today versus five years from now? What are the different things you need to do or care about or think about, be aware of, in order to master telephone? Hmm.

Yeah. I mean, I, five years ago is definitely not a master's here. It's hard for me to, um, imagine back then, but, um, I, and you know, where I think today, you know, we're living in this world where we, we have traditional, traditional infrastructure roles that are kind of retooling, reskilling to, like where more and more their job is you know programming and automation concerns as opposed to click ops which is i think a very a very positive trend um and you see this kind of stratification between developers and um that that traditional infrastructure will like re-emerge and i i hope you know that we're heading in a direction where we're we're not going to repeat kind of the sins of the past, right?

Where we had discrete silos between infra network security and then the developers, right? And I hope that we're today, like I hope we're like getting to a place where we all developers right We might have different concerns you know in terms of the system that we building whether it whether it a platform or whether it an application or a service that sits on top of those platforms Um but I hope we getting to that place where we all just recognize that we're all developers, um, as opposed to like, I'm in the, I'm a develop, I'm in the developer camp and I'm in the infra camp and that sort of thing.

That's what I hope. Now, looking forward, you know, how AI plays into it, you know, those two magical letters, it's hard to say. You know, I'm fearful that, like, you know, you go back and you look at, like, what people from the 19th century thought, like, 2025 would look like. And it's like everybody's riding flying trains, you know, with steam engines and stuff like that.

So it's, you know, it's hard to see, you know, how far we are away from things. But I think short term, I hope some of the toil that we do manually today, such as like within the Terraform space, right, is to provide our development, right? I hope some of that toil maybe can be automated, you know, and so that we can still provide a good development experience for infrastructures, code developers, while not completely relying on code gen. So we can kind of smooth some of the naturally rough contours of the different cloud platforms to make it life easier and more predictable for infrastructures, code practitioners.

I think that is like a short-term thing. I think mid to long-term, you know, we could see infrastructure as code, you know, like completely be, you know, kind of an automated thing. I see folks post things where there's like chat as an interface where it's like provision this thing. It's hard to imagine that, you know, that reality today, but, you know, I think we're definitely going to see layers of abstraction, you know, to hopefully move all of the developers up the stack so that we're not necessarily, so some of the concerns that we have today are maybe not as low level, I'd say.

Yeah, so. But I think that's going to convert a thing, platforms like Kubernetes, right, as the layers of abstraction move up that stack as well. Got it. So you mentioned some things that are maybe more natural to begin with, such as writing and maintaining the provider's code of the different services.

And yeah, you know, AI can scan your API or your code and then realize what needs to be defined as your telephone or other provider. that sounds like a very good first step that would save a lot of time. Very, very interesting. You know, I think the biggest question is just the regular amount of code.

You know, we developers write code. That's what we do. That's what we're paid for. And in the last few months, we started to see some amazing new things that write code.

Now, whether they have the awareness of all the needed aspects that we must take care of, especially around production environments, that's, I think, yet to be proven, but I think the direction is very clear. And so I think the same way it happens to application code, probably a bit later in a similar manner, it will affect the infrastructure-related code, whether it's Teleform or others. So that's something very interesting to monitor and pay attention. Do you tend to agree?

Absolutely. I think we're in that stage right now where we have skilled laborers such as myself and presumably such as yourself who code. And we use AI as a tool and we kind of extract nuggets from it. We give it instruction.

We extract nuggets from it and we piece that together. We kind of cobble it together. but once the ai gets good enough like i mean our productivity is going to start ramping up where we're going to cobble and cobble together so much faster but eventually there's going to be kind of like a a moment where maybe we don't have to cobble it together we don't have to have a human cobble it together it it knows enough about the context as you said to to cobble it together itself so that integration work I think at least in the short term you know us coders are going to be doing but long term I think there's a big question mark about whether we're going to be doing that and how much of that we'll have to be doing it's hard to say Alright Mark thank you so much for sharing your knowledge and thoughts with us it was super interesting anything you'd like to say to the audience today?

No, thank you, Oad, for having me on the show. And I love your podcast and just like the diverse of perspectives that you bring and just like your style, man. Thank you so much. And thanks, everybody, for listening.

Until next time, see you later. Bye-bye, everybody. All right. Cheers.

Cheers.