Hello, I'm Rob Hirschfeld, CEO and co founder of RackN and in your host for the cloud 2030 podcast. In this podcast, we talk about Infrastructure as Code. And we do it with a Kubernetes filter. So the beginning of this call, we're actually doing a check in on coop con, which had just ended, and VMware, which had also just wrapped up. And both of those are very relevant in our discussion and considerations for Infrastructure as Code. And so we build on those systems. In the process of looking for how do we build sustainable automation and operations, and we get to some really interesting places. Stay tuned through the whole thing, I know you will enjoy it.
I would be interested before we roll into the Infrastructure as Code topic, if there were any takeaways that people had from cube con. I'm happy to talk about VMworld. Two, I actually paid more attention to that than I did Keuka.
So I have some really great conversations. Cute, tornado has always been this abstract thing that people have always say, Oh, yes, I'll be really interesting problems and an enterprise that I just never see exists. Because I'm more of that I'm more, I still have my foot in the VMware community. And we support a lot of cots ISD stuff that is packaged software, it may come in the form of containers, but all of that is typically self contained. So I've never had these application development workflow problems that Kubernetes solves. And I was really taken aback by the number of teams of end user teams, even though only 1/3 of the attendees were in use of words, I was taken aback by the number of conversations that I have with people who are actually creating, or who have created workflows where they're just coding and pushing code, or on their way to that level of maturity, where developers are just coding pushing code, and the machine of, you know, infrastructures, code and, and get get ops. And all of that is taking over in, in publishing code. And I was it's way more advanced or way more prevalent in that community. And I thought it would be
perhaps a note than that is that it's not so much to developers, I believe other driving careers because they really don't care where they run their, their containers, whether it's Docker or Kubernetes. But it's the it's the sysadmin, and the SRE is who are pushing for it? Because managing your workloads in Kubernetes, is more predictable than managing a fleet of of VMs or, or, or a fleet of Docker hosts. It's darker, stration aspects that so the attractive part there
when people are doing that, or they have dynamic is, is the environment because I could see building that pipeline pushing to Kubernetes and rolling your painters, is that include the setting up? No publishing the app load balancers, all the DNS infrastructure certificates like that also part of it? Or is it
is yes. Oh, X that use funny because I came to that same kind of question. And what I'm, what I've discovered, like the most mature example of this, and I, you know, Echo, how do you, obviously, I can't just simply write code and hit publish, I have to make some decisions. And they have done that they put t shirt sizes and said, hey, you know, what do you need a little batter. And they made opinionated decisions for the hopper on the operations side of it to simplify the process. And they haven't excluded developers who want more control. So they do have primitives. So for developers who want who understand the platform, and they want, they want to make specific decisions around, you know, number of replicas, blah, blah, blah, blah, the they they've fully given that capability to the developer, it may not be in the same primitives that Kubernetes the new thing up and running, if you need to their landscape and environment
that it makes sense, it still sounds like the development teams, not the ops team. But maybe I'm
Yeah, so it's a, it's funny because it's an ops team field with developers from
engineering teams is a lot of water who are running the Kubernetes clusters and acting as kind of your traditional sis admins, but are really actually focused on building out platforms, product platforms for their developers. So in a lot of ways, acting almost as a full on internal software development organization, for enabling developers to just write code essentially.
And in this case, they call the platform team, a developer experience team. So their whole job was a bunch of Cesaris, who were focused on making the developer experience as simple as possible.
For good term. Yeah. And, yeah, I mean, ultimately, that that is, that is the goal of bell of DevOps, right, bringing in dev teams and the serie and on platform teams closer together, tearing down the barriers for the developers to be able to say this is what they want, and minimizing the amount the amount of work necessary. or minimizing the amount of work thrown over the fence necessary.
Yeah, they thought where they failed, they measure success failure, if a developer is spending time. The anytime, the more time a developer spends fussing with a platform, the more the less likely they are succeeding as a team. So even from the local experience, if they have if the developer has to figure out how to get local container Docker environment up on their laptop, then as a developer experience team, they are failing. That's not something that developers should be worried about. They should be worried about writing code, and not getting the platform in alignment with their CI CD process.
Exactly.
And that, and you felt like that was the themes that emerged out of cube con?
Well, that was the conversations I was having the bigger themes will be around application model, around security, around security, specifically, chain security, well, that supply chain security by saying security was a huge topic throughout the conference. And, you know, one of the things I didn't think about until I went to the conferences, you know, it's open source is me and Rob getting together and doing a project. And then upstream that project gets, you know, used in a piece of commercial software, how do you continue to validate that Keith and Rob are the ones that sign the code and deliver the coal downstream. So it's really it is it is a really complex problem, then, you know, you get into identity and people in open source don't want to necessarily have their personal identity tie to code and it's a very complex problem that I don't fully appreciate yet.
It it's something that a lot of people saw commenting after SolarWinds dot rent, it, it was It wasn't viable anymore to to ignore it. And it had been ignored for a long time. By I'm by upper management and, and by, by companies I've worked there, we're just trying to be as agile as possible. Unfortunately, when one velocity is your key metric, security tends to suffer. So in essence, this is a knee jerk reaction to that. It was necessary. But it it's very much a reactionary event. And now the proactive one.
That's really cool.
What were the things you saw the VMworld?
Developers Developer developer, VMware is
is very
singularly focused on moving up the stack in engaging in the developer experience.
So the my interaction was not with a lot of end users during VMworld, because it's virtual. And it's hard for me to interact with end users in a different way than I normally do. And so a lot of my tweets were responded to via DM from executives, and VMware. And the reply was pushed back of this, this perception that their multi cloud strategy is only VMware vSphere, across multiple clouds, and that they are a grown up developer focused company. And I don't, I don't know if I intuitively get that yet. I understand the reason why they want to push that. But I don't know if that's, I don't
know if that's real. I think your skepticism is valid. Yeah. I mean, they're, they're certainly all in on the Kubernetes. Side, Pivotal side, they've got some multi cloud story. But these things, and they're one of the few vendors that actually have sufficient scale with software that you could use in multiple cloud. I don't know if that translates into being a multi cloud story yet, but at least you could, you know, use VMware components and all bunch of different clouds.
Yeah, I forget the term that they used. But it was a I think it was multi cloud services. So they actually have a proper umbrella name of it, and what but when I went to search via the, the content catalog for that term, multi cloud services, I think, is the the umbrella term that they're using. And when I went to search, the content catalog, there was no single session that talked about that overall strategy. And I think a topic we, you know, kind of bring it up from not just VMware thing, like, is there? Is there a vendor that, you know, kind of we can trust? Whether it's, you know, OpenShift, or VMware or Microsoft, or even Google that has a proper multi cloud framework that we can actually apply? At this point? I don't, I don't have to like do because I don't know what we even know what that is.
It's just gonna ask Keith is what does that? Does that mean? multicloud? Are they federated? Are they maintaining synchronized control planes? It's kind of a loaded term, right?
Well, and and I think maybe you're driving home, one of the things that I do not just VMware on but all of these kind of multi cloud vendors on when I, when I think of like security pass policy, and I want to implement it across multiple clouds, I can't deploy NSX in every cloud, that's, that doesn't solve my problem for the very types of workloads in use in services that I use. What I need is a is a solution that normalizes my policy, that affects my policy, and then it goes to each control plane and applies that policy to each control plane, the way that that control plane works. And I don't know if that's right, but that's what I want. And there's not a solution on a market that I can see that normalizes the, the cloud control plane and the way that multi cloud can be useful from a traditional IT perspective.
I that's what TerraForm now, attempts to do. I'm not exactly 100% successful with it.
But what what your
overlay, we're talking overlay, though, under right?
It has to be an overlay, it has to be in a infrastructure abstraction, that it's not multicloud. But Keith is describing to me and actually this is the Infrastructure as Code topic. I mean, you literally just walked into to me what is the topic today, which is, you know, what does that look like? Because it's infrastructure agnostic. So, processes that you define in one cloud can work in other clouds. And it's not human processes. It's tech. So I can define a workflow that works in Google works and Amazon works on bare metal works in VMware. That's the goal. That to me, that's what you just described what what we've called distributed infrastructure, as opposed to cloud. With different control planes and different, there's not one control plane, it's different control plane. So each cloud would have a control plane. But the processes inside of that control plane would be reusable to other other infrastructures. That makes sense.
And as you look at, you know, high level Kubernetes, and you look at high level, even, even if you were all in in VMware Cloud on AWS, like there was nuance, and there's problems, and there's, there's those of you on the call that have way more experience in this area than I do. And I'm really interested to kind of dig in and understand some of that nuance, and kind of where, where some of this stuff falls apart. Whereas where some of the stuff stuff is wrong.
I would I would ask is, Is it even even if you're all in on AWS? Right region to region variation is still still something you're gonna have to account for it still is, there's a multi cloud, or at least an automation portability component, in that
we just talked about today. Right, Rob is? Well, hyperscalers get to the fire edge, will we be seeing the use running on hyper scalars? And from Beth stone and other operators that were on the call? answer's no. So you're gonna have to have something that as a controller of controllers to be able to do this kind of orchestration, right? Because at some point, AWS stops, right, at some point at the edge, it stops in the EU is running on some kind of fabric, that you need to have improper interrupt between both right.
And I think Dave, you're kidding. The key point here, I'm not like, Oh, I love the nifty nest of AWS outpost. And they're, they're cool solutions. However, once you put something out of a controlled environment, into, in this case, the edge is the data center, into the edge and you introduce a customer's network and environment into it. AWS, like AWS, big breaks, you, they can't give you the same SLA as they could give you when they're in AWS data center. So whether it's the edge proper, you know, the old T OEM type of edge, or if it's the edge data center, and we're thinking about Cloud Control Plane, how do we as solution providers and solution architects think about, you know, where does the one control plane in unknowingly start and when to use abstractions from one end to the other? So as we're thinking about Infrastructure as Code, not all Infrastructure as Code is equal?
I definitely agree. But I'm interested in for you. The have to one thing, that the idea of having multiple control planes I want to come back to, but I'm interested in digging into why how are you saying not all Infrastructure as Code is equal? I want to make sure I'm, um, you and I are talking about the same thing that I agree with you.
Commutative,
assuming that that was his doorbell,
maybe then.
Well, what well does that Lolo, maybe my two cents. Going back to what we were talking about before we couldn't is one of the nice things about this is that as long as you stick to the same version, once you once you're running your your, your coordinate on coordinates, it is significantly more portable than done if you base your infrastructure as being trusted cloud provider. So you're you still need to have cloud provider specific tooling to spin up your clusters for this AKs or Eks, or GK or dogs or, or any other currencies as a service offering. But once you're there, you have Have a great deal of, of normalization between how you deploy your effects. That the only the only main things I can think of where where it differs, rather majorly is is, is at the edge of current news, things like DNS on load balancing, and or Ingress, and so on. Although, follow those,
what about storage or database or block or file, I mean, those things factor in or have Kubernetes ecosystem components been able to abstract out some of that variation too. Right, I would say that it doesn't matter.
Botha did Pareto principle applies. So 90%, of what you do is normalized, as long as you as long as the default storage provider is sufficient. And you're fine with with multiple providers. If you if you need to start provisioning, specific storage, whether that's high performance or high permanence or anything else, then you still got your normalization inside converters, but but again, you have that edge component there where you need to have a Google specific way of requesting a particular storage provider or Amazon specific way or IBM specifically, or Oracle or whatever. Databases small as the same as well, like, the developer only cares that you that you're giving them an endpoint to connect to the major differences between cloud providers, and up being word credential management, as like, whether you use Iam or local identities or whatever cloud product has available to do basically have credentials or less access to just by using like zero trust, or whether you need to still provide the credentials to the application itself. But to to a degree that that is still you're still able to normalize it, like if you standardize on, on providing credentials to the application are secrets. That application developer doesn't care what the content of the secret is, as long as it's got the right keys.
So when I go ahead, we found similar when we did our VMware Cloud study, like vSphere vSphere, whether you know, as vSphere running on premises or vSphere, running in AWS, you know, the vSphere Web Client is the vSphere Web Client. However, think about how to expose a public IP address on premises versus how you expose a public IP address in AWS versus how you do it in cloud versus how you do it in
Azure, anywhere, everywhere.
Everywhere is different. And we ran into like this simple, like operations probably like the from a, you know, the AMR solution is cool. And that is basically a SAS offer. I'm getting vSphere. And I get VMs. And I, me as the operator, I'm, as a data center operator, I'm getting a very similar experience that we're trying to give developers and when it comes to Kubernetes, it's when we need to go beyond that is when we need to have the equivalent of SRE or operator say, Oh, this integration has to be created. So that when I go to expose a VM to the public Internet, that is a similar process or across the board, that maturity isn't there yet. When you talk to VMware there, they believe that that maturity comes not via improving the vSphere control plane, but in improving the Kubernetes control plane. So when they follow it recruited Aggies, they'll maybe even take the namespaces from Kubernetes. Apply that to vSphere and salt and solve it for vSphere.
But then, to an extent, the fact that Kubernetes is sort of a common deployment model allows you to then focus on the things that are actually value added differences. So, right I mean, it's not about eliminating complexity, it's about managing it. And so what we're, what we're describing here is, you know, hey, if I have, my team knows how to use Kubernetes, my processes know how to use Kubernetes and 90% of my use cases, I know how to handle wherever I go, that's a huge win, compared to the alternative. Even if it's even if it's 60%, even, you know, 60 percents a big winner.
So me and Martez talked about this a couple of weeks ago, I get the podcast is in the candle we published in the next few weeks or so. But this the same idea of the problems that we run into with the network stack. And we build abstraction on top abstraction on top of abstraction, that there's these quote, unquote, reliable contracts between the different layers of abstraction that aren't very reliable contracts. And the so, you know, forget the latency, and why, you know, storage drivers and Linux are horrible. Forget all of that. Just the fact that I can't reliably say that I'm going to do I'm building these systems on top of systems and AI, and they're not exactly reliable systems. And my fear of Kubernetes is that is moving so fast, that we're going to end up building these abstractions. And these contracts that not are not fully thought out contracts.
Yes, or No, they did to a degree through this, I think they did a smart thing. But saying, here is an interface for for providing such an abstraction with the with your own definition. So essentially the operator framework. And for and for, for various other components, like storage network that does all they also have a common interface where as a third party provider, you can write your plugin that interacts with turn is natively and provides your own opinionated implementation. Part of the the the thing, though, also is there, there is only so much where you can abstract an automated before you run into other issues that are not performance, but there are human issues. We were just talking about supply chain security. And and when we bring this to say that the management of like the of the ingress or the or the load balancer, yes, we, we haven't fully automated it, but should we are actually fully automated it automated, because because then we put, we put our workloads at a higher risk as well. So in some cases, it might be desirable, to have it fully automated, in some cases, it's, it's preferable to have it supervised. So the, the, I don't want to say brilliance, but But I, I am failing to think of a different word for it. But so so I'm going to use it for now. So the brilliance of Kubernetes is that it allows the cluster managers that the SRE or the DevOps engineers to pick and choose which of these contracts they want to automate or not by the operator framework. And, and, and you're right, keep that that there, there is a risk of this becoming a dog's breakfast with with various different different operator frameworks going in multiple directions. But in the end, it's it's something that still lets you set up an opportunity environment in a composable and reproducible manner.
Make sense? I mean, it's, it's, it's definitely a We saw this in the container orchestration work. Right? There's a sweet spot that Kubernetes was was in that you know, wasn't it was more complex than swarm and more configurable and less complex and less configurable than Mesas? And so that that sweet spot was important. And what you're describing I think, with the sum of the CRD pattern I I'm not as big a fan of what I'm watching going on with operators but But maybe that'll evolve over time.
But I mean, I don't think it will I think the operators end up getting us back in the same sort of pattern we have now let's see a TerraForm or a puppet where, yes, I have that that single language to define things. But literally trying to normalize across, let's say cloud providers, is still challenging. Because one of the things I think that's often looked past, at least from the initial investigation or evaluation, is how much context is required to let's say, go through all the different options for deployment of networking or storage to GCP, or network and storage to AWS, even though it's all all defined in Kubernetes, Yamo code, it's still those details that end up taking you a week to figure out why it's not working exactly.
Oh, yeah. Yes, or No. Um, I think that the operators serve a rather crucial function in, in the ecosystem in that they allow application developers, not Platform Developers to think encapsulate expert knowledge. So look at for example, the elastic search operator, which i i personally think is brilliant. Because with a single CRD, you can serve self maintaining self upgrading Elasticsearch cluster, and if you've ever tried, if you've ever had the misfortune of, of having to manage one of those yourself, you you realize how, what the Titanic where amount of work is, is involved. So So that's, that's where the beauty of the operator comes comes in. Where that it not only allows the Platform Developers like the storage providers and enterprise to do to provide their opinionated tools, but also the application providers. So it it's a, it's in essence, similar to the AWS Marketplace, where you win the marketplace, you it's basically got to click kind of thing. Your application gets spun up on a VM. It's hosted on your infrastructure. But it's deployed with the application developers knowledge. The operator pilot does the same thing. But on your cluster.
Yeah, definitely the value from a software vendor standpoint, and even the potential to bring the idea of more as a services offerings, whether it's object storage, or database as a service to its own Prem utilizing operators in Kubernetes. I definitely see the value. I think it just like every pretty much everything in life in that that the double edged sword effect.
Absolutely. But But in those in the operators. And this is this to me as part of and this is actually, once again, bat is an Infrastructure as Code question, right? It? Is the operator a thin shim in front of a much more sophisticated, you know, maintained deployment infrastructure? Or is it is it actually, you know, which it has to be because operators are really just a object interface to a service that then does work. And so, that service is instantiating a logic that you're describing here. And in a lot of the operators I've seen are really front ends for other services that then do the work that have their own, you know, they there, it's the operator itself is just is a standardized interface, which is
my job going too late? You know, the, again, I use that the so naively, next not not too long ago, maybe only within the next few last few years, that I've realized that there there are no simple problem solving solutions to complex problems. And the thing I don't know if it was on this channel, I don't think it was on this channel, but we start with talking to somebody from SpaceX, who maybe was on this. And they were talking about the process they use before they went down any solution but they were specifically talking about Kubernetes and whether or not they should adopt Kubernetes. And I think it goes back to this like intentional architecture around Infrastructure as Code like, what? What is the thing? We want abstract around? Like, what is the controller of controllers? Having that opinionated view? And not kind of floating in between? Like, are we going to abstract at operators? Are we going to expect on a close worth product solution? And then just, you know, integrating stuff around? And I think the answer to that question just becomes around the operator, question just becomes what is your philosophy about abstractions? And where to abstract?
This insightful? Yeah.
very abstract. I mean, so would you say even that, like, an operator that's interfacing to another platform that then set stuff up would be that something that is abstraction boundaries? So the setup becomes an abstraction boundary or the infrastructure becomes
a boundary? Then it becomes a question of, Am I even using the operators operator the correct way to approach the problem in my environment? Because at the end of the day, when it breaks, nobody has to troubleshoot it? So do I have a guy troubleshooting TerraForm? And I may have a guide Pro to the TerraForm and the operator or some other some orchestration layer, I have somebody troubleshooting some orchestration layer, where do I want to deep expertise in? Yes, solving it with TerraForm may not have been the most optimal solution, but it made them work. So portable solution in my environment, I go to companies that still have HP UX in AI x, not because it's the best technology that they can deploy the solution on. But it's the most optimal technology that they can support. So I think it becomes, you know, what's the most optimal technology versus the, the one that you can support?
What standard MVP? Yep.
Well, the MVP, because the challenge, because on various automation projects I've worked on, it becomes what's the what's the least elegant solution I can create? But then you might have the challenge at the moment you in a lot of scenarios, you step out of that first use case, that was clearly defined, the solution starts to show its brittleness. And so that's where we get into that quickly over engineering of before time, do I factor in all the 30,000 possibilities of what it could do, I focus in on the maybe the five that are fully defined.
Balance, because if you if you, we see this a lot people solve the problem that's immediately in front of them. And then the next problem comes along, and they they start incurring technical debt, the fix that one next solution in the next one, and by the time you get to the fifth, you've you know, you're now you're now at something that's not sustainable for any of the five solutions, let alone sign that comes forward. I see that a lot as an ops pattern. So it's, there's definitely a balance between get it done and and the stain?
Yes, we're where we're at with some of the the operator patterns and even some of the broader Infrastructure as Code is. I think we're still in a even though it's been around for some time, I think we're still in a lot of ways in a maturity state where it's developing those best practices, and what those look like, obviously, across organizations.
Yeah, I that you're hitting the key points to me, because there's a and we saw this, like with Ansible, stuff that just made makes my head explode where, you know, you might have a playbook that looks very similar to somebody else's playbook. But you're not sure it's not shareable. You're not reusing it. It's not decomposable. So now, you have you know, every person who picks up that playbook has a has their own their own fork of it. And the tools don't encourage convergence back. Which is why if I was thinking Infrastructure as Code that that multi party sharing and reuse the libraries and things like that needs to be a central part of the Infrastructure as Code story. But it doesn't seem like it's the priority and how the tools are built.
Well, I think, in some ways, part of it is need to get to the concept of libraries have to start building those libraries and saying these are libraries. Instead of saying, Well, yeah, wait, we got this code snippet, or I've got this cool tool instead of calling it a tool. It's like, is it really just part of a library That should work everywhere and be composed, be used for composability
well, that that's that the interesting part of a pulumi. Right? And that's a direction that they went out. They created libraries for various programming languages. Managing your infrastructure with Paluma is literally writing code. Yeah.
I love that. That parallel, like, what other code? primitives? Are we not considering we throw around the term Infrastructure as Code? You know, what's the library's a great Ajam nap? Or what's a method that you know was a method that would be commonly accepted in a modern Infrastructure as Code language? Where even once the Infrastructure as Code language like what? What is really cold? What what are the languages? What are the methods? What are the lab areas? What are the primitives? What are the basic computer science primitives or language?
Simple things like arrays, databases?
It isn't isn't I mean, for the stuff that we're doing? The infrastructure right are we actually worked really hard to avoid creating a new DSL. Because that doesn't seem very useful. Although we end up with go Lang templates. As a DSL, we end up with bash as a as a as a language or Python, if that's the usable thing or TerraForm rants like for us, the goal isn't how isn't isn't the tools. And this actually, Keith, when when you had made a comment earlier that I wanted to dig in on which is where the tools where the tools are hard. What what we find is that there's an element here, which is the context of the operation. And some tools like TerraForm work really well in in one context, like dealing with a cloud API, from outside of the cloud. And there's other things that work well inside of a context like Ansible, where you're inside of a machine doing configuration work. And both of those tools have ways to do they have ways to do some overlap with the other tools. But they're, they're really painful to use in those in those modes. And it's because there's literally different context. So when we build an Infrastructure as Code, components, the component tree for it, which for us is like templates and tasks and stages and workflows, that all get chained together. And then all version controlled and managed as immutable artifacts that makes it Infrastructure as Code. But part of doing that well is actually using a tool that does what it does in context. And then taking data out of that. And then passing it to another tool that does it in context, in maybe a different context. And so it's the, the missing thing to me is that I've got TerraForm or Ansible, or pulumi, or something like that. But actually crossing the context and creating a workflow across all of them, is a is a missing element.
So if you feedback, I love the idea of looking at it as coding coding languages, and all of that look back, you know, at the very beginning, we didn't even have procedures, right, it was just code with go twos and groves, we added procedures, then we added inheritance, and that encapsulation provided us with this abstraction, you know, where are we in that in that kind of lifecycle? And actually,
I would ask, if you had sorry, let me ask a different question. What, what keeps us from having like an HTTP module that you can just plug in and say, like, I everybody has a web server, here's an HTTP module, I'm just going to require it. And I don't know I'm not going to write it. If I actually need a better HTTP module, I have incentives to improve the HTTP module, not not read not write my own port 80 open, whatever. But what keeps us in infrastructure from that module being reusable? Right, uh, you know, set up a Elasticsearch
Yeah, you this is a fascinating conversation. I got to look to see if I already bought a main book that talks about a lot of this I'm, I'm stacking up many books without ever reading.
With them under your pillow works
exactly the same. But if I were to, like, do a modern PhD program, if I was to literally go out I've always had this challenge of if I were to pursue a PhD, I don't know what area of research I want. But this will be really interesting because we're asking fundamental computer science questions that are not well defined in this area of expertise. Like, Robert, I really love your point that you're using the right tool for the right context. So in my mind, a computer a Infrastructure as Code a Infrastructure as Code language isn't down to whether or not I'm using Ansible versus Python vs. Software dysfunction. that's those are just a collection of modules or libraries with in a link within the higher language Infrastructure as Code lane. What does it mean to have Infrastructure as Code language?
And and the context this is this was the big aha for me was the context that you're working in, is part of that conversation. That that if like, if you're like, Oh, I've got TerraForm. Now I can I've got Infrastructure as Code. And that's all I needed. I'm like, Well, what about orchestration? What about monitoring systems? What about configuration? And TerraForm? Doesn't have stories for that.
That there was a question also, whether within should or not, I am personally in the camp of it should not TerraForm should be good at what it does, which is provisioning infrastructure. But then when we come down to, let's say, deployment within a VM, or so I My opinion is that, at that point, TerraForm should hand over to the should hand over the task to the next tool, whether it's cloud in it, or Ansible, or whatever, I
strongly, strongly agree with you. Yes,
challenge you're going to have some of the vested interest organizations have. So as I see it quite often, is the the tools rationalization conversation in the enterprise, every handful of years, where it's like, we've got too many tools, particularly from a licensing standpoint. So we want to we want to rationalize the tools. Can you use TerraForm? To do some of the things Ansible does? Oh, sure. Okay, well, we'll get rid of Ansible. And we'll try to use TerraForm. To do everything, you got some of that going on. You also have some scenarios where the content that's been produced, sort of hacks at the idea of using a tool that's not appropriate for certain scenarios. One of the the examples I commonly give is utilizing Jenkins for CD. Jenkins isn't necessarily a CD tool, but you can you can kind of use the hammer and smash it and bend it to do cd. But if it's good enough, people are going to use it for not necessarily its intended purpose.
I love what I've been I've been calling that infrastructure pipelines, by the way, that the CI CD tools don't don't understand infrastructure and resources for infrastructure. And that there's a separate, separate pipelining requirement outside of the CI CD tool.
Oh, that's a that's a whole conversation like orchestration like CI CD, you know, you Yes, you validate cold. But do we even have the capacity within the region to run that? That that Korea is validated, but what does validation even means is not that doesn't mean anything when it comes to in the context of capacity and orchestration?
Do it fair also, the term CD has been kind of CO opted these days to mean like, all the way to application deployment and readiness initiative, initially, CD just meant continuous delivery of artifacts, like put them into your iPhone repository, and then CD is done. But we've extended that now to go to go from the artifact repository to your actual infrastructure on deployment. And Dr. Jenkins is not the greatest tool for that.
MP, this is a modeling problem, right? Infrastructure is different than code and the linearity is different than thing.
So here's a unpopular take is anybody taking a look at where Zul is at the moment?
I know it's a lot from Ghostbusters.
Named after the same thing. That's the OpenStack CI.
Yeah, and we know that they just keep on keeping on and that they kind of mostly junk Jenkins quite a couple few years ago, because it wasn't doing it for them.
Yeah, I systems still have a tendency to see the resource, the resource lifecycle component, or infrastructure is fundamentally different than the DI process, where you've got code, you replace code, it's an artifact with resources. There's startup been down, right? Kubernetes does, actually, it's one of the things that I think people underrepresented about Kubernetes strength is its ability to say, here's startup tasks, here's removal tasks, here's health checks, that I can build in and then help create resilience in my application, just the artifacts around that are a much bigger win than I think anybody thinks about any more for Eddie's. But infrastructure, if you're building a cluster, you have very similar concerns and constraints around building infrastructure up in those ways, and then propagating ease and then there's order of operations, you can't build a de until you actually have the name of the machine and its IP address. So there's like, order sequence of operation stuff that has to be accounted for. That's to me, that's the Infrastructure as Code like, it's not just hey, I need a machine, can you go build a machine? It's Can I go build a machine, there, may let it get ready when it's ready, collected into a cluster, propagate the secrets, so that cluster to the new system, or tear it down and make sure there's enough resources to handle the you know, that we haven't torn down the cluster in a way that destroys the cluster? If I was trying to keep it
viable?
I all that stuff past that has to be standardized. I think close to your point. It's like if I can give you a way that does it for a thing in a repeatable way, company to company site, the site? I've saved, you know, that's good. That's amazing.
But I got asked, he also discussed it, it varies greatly from company to company, which is why it's hard to abstract it up to the the two click operation kind of thing. And this is, again, where I agree with Keith is that our jobs are not going away anytime soon. Because we we are responsible for architecting and composing these tools into something that is usable by the enterprise.
Fair enough. Fair enough. We are at the top of the hour. So um, I actually think that's a good note to go out on.
All right, one, it was great conversation.
It was a real pleasure. A lot of good voices. I appreciate everybody's coming in and opinions. But y'all either on Thursday or next Tuesday. Times. Cheers. Cheers.
Wow, what a great conversation about Infrastructure as Code, not because we had simple answers, but because I think we really laid out some of the challenges and problems. There's no doubt that Kubernetes is influencing and helping people build more productive systems. But there's a lot going on around it that we really have to consider and think about, I believe we really laid out some of those core questions. We will keep talking about Infrastructure as Code and the challenges that get created by the systems that we're building and the complexity of those systems. So please join us at the 2030 cloud. Thanks. Thank you for listening to the cloud 2030 podcast. It is sponsored by RAC in where we are really working to build a community of people who are using and thinking about infrastructure differently. Because that's what rec end does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly, or just keep enjoying the podcast and coming to the discussions and laying out your thoughts and how you see the future unfolding. All part of building a better infrastructure operations community. Thank you
