default-focus-right

Navigating the Road to Infrastructure-as-Code

Episode Overview

In recent years, interest has skyrocketed in all thing’s agility. In the IT world, phrases like minimizing blast radius, managing cattle versus pets and just in time service delivery have become part of our everyday language. The main point is that businesses both inside and outside of the technology industry are enamored with finding ways to do things faster through creation of loosely coupled autonomous teams and infrastructure unencumbered by the processes, red tape and fragile monolithic tooling of yesteryear. One specific trend that has emerged is that of “Infrastructure as Code” or IAC for short. The basic principles behind this model is to codify everything, use version control, continuously test, integrate and deploy and make the code that drives this as modular as possible. For those just looking to move in this direction, it can be challenging and confusing. In our discussion today, we’re going to work to demystify this space by talking to experts that have already been on the journey and work in this world on the day-to-day basis… I’m joined by a panel made up of 3 members of Kemp’s Platform Operations team, Roy Dunican, Michal Jeco and Dariusz Banach

Jason Dover photo
JASON DOVER

VP, Product Strategy, Kemp

@jaysdover

July 29, 2021

Jason:
I'm Jason Dover, Vice President of Product Strategy at KEMP Technologies. And you're tuned into the Application Experience Insights podcast. Today we'll be tackling the topic of Infrastructure as Code. In recent years, interest has skyrocketed in all things agility. In the IT world, phrases like minimizing blast radius, managing Cattle versus Pets, and just-in-time service delivery have become a part of our everyday language. The main point is that businesses, both inside and outside of the tech space, are enamored with finding ways to do things faster, through the creation of loosely coupled autonomous teams and infrastructure that's unencumbered by the processes, red tape and fragile monolithic tooling of yesteryear. One specific trend that has emerged is that of Infrastructure as Code or IaC for short. The basic principles behind this model is to codify everything, use version control, continuously test, integrate, and deploy, and make the code that drives this as modular as possible.
For those just looking to move in this direction, it can be challenging and confusing. In our discussion today, we're going to work to demystify this space by talking to experts that have already been on the journey and work in this world on a day-to-day basis. I'm joined by a panel made up of three members of KEMP's Platform Operations teams. Folks welcome, and why don't you introduce yourselves?

Michal:
Hi, my name is Michal Jeco. I'm the Platform Operations engineer at Kemp for the last two years. I'm originally from Slovakia. Why I like working in tech? I guess I just like constantly learning new technologies and solving challenging problems.

Roy:
Hi, I'm Roy Dunican. I'm the Platform Ops Team Lead, based out of Ireland. I just love deploying new technology and getting my hands dirty.

Darius:
Hi, my name is Darius. I'm calling in from beautiful country of Poland. I'm working for KEMP since 2014. And my favorite thing in working in the tech is just getting things done. I just like to build things.

Jason:
Awesome, awesome. Thanks a lot guys. Really excited about our chat today. So why don't you tell me a little bit about the Platform Operations Teams and what do you guys do?

Roy:
Yeah, so before Platform Ops Team, there wasn't really any infrastructure team within the company that was maintaining the systems that were in place to deliver an app or a product. So we decided that that needed to change if we were to do this right. So we formed Platform Operations. So the reason that we chose the name Platform Operations is around kind of the productionize effort of both like writing code and delivering the ops of all the apps and all the platforms that we deliver in a way where we're responsible for uptime, as well as getting a software released.

Jason:
It certainly sounds like a really, really vital role specifically in a modern technology company. Now I'm hearing the word ops and platform ops, and this reminds me of another phrase we're hearing a lot these days, that of DevOps. Can you dive in a little bit, how would you say DevOps differs from platform ops and even beyond that, what is DevOps? The, the $5 million question?

Darius:
Yeah. So DevOps for me is, to be honest, this word is not fully clarified yet. I think that there is plenty of literature about this, but the sentence and to say like, okay, this is DevOps, I think this is not defined yet. And for example, when I'm browsing Polish system operators or operators groups on Facebook, or whatever, LinkedIn, or something like that, there's a constant argue about the definition of that. And for example, when someone is posting the job offer and in the job offer, there is a thing like, okay, we've got that one DevOps position. There is like a huge storm after that, that, "oh my God guys, there's no such a thing like a DevOps position." The people think about the DevOps, like a culture of working more than a position, because depends of the company, they're like different name for that.
One people called this DevOps position, when second people called that, like a Site Reliability. There's like a many definitions of that. And for me, this definition is basically a bridge between the teams who are like a pure developers and the teams who are like a pure operation system guys. Okay. So the guys who call himself a DevOps, he needs to know these two domains. He needs to know how to code, he doesn't have to be algorithm specialist, but at least to know the rules and how this works and how it's supposed to work and also have to be really fluent in the domain of operation systems. So, yeah, so for me, it's just the making a bridge between two domains

Jason:
Makes a lot of sense. And that, that gives us a good basis for the discussion, because the things we're going to be talking about are absolutely applicable for environments where starting to bring in these types of cultures and principles around how they approach operations and managing their infrastructure. Let's dive in a little bit more to definitions though, right? In our intro, we talked about this concept of Infrastructure as Code, and there's a lot of other things to support moving in that direction. So why don't we start there? What is Infrastructure as Code?

Michal:
Yeah. So this is a topic that's been thrown around a lot recently, Infrastructure as Code, IaC. It's basically like tradition... It's managing your IT infrastructure with configuration files and automation tools in a sentence, if you want to put it that way. But traditionally in an IT, maybe couple of years back, it would be kind of, you would click on the user interface, and your Azure and your AWS or and your local hypervisors to deploy machines, to configure networks like virtual networks. It would kind of be a manual process for the most part, mainly clicking on, or maybe using the CLI, if there was one, or maybe even if you went a step further writing some custom bash scripts to automate parts of it.
But today this is kind of getting really popular as Infrastructure as Code, where you're able to manage your entire infrastructure, be it in the cloud or on some local hypervisors, like vSphere, completely true automated tools. So you don't need to click any buttons on any user interface. Everything is done in kind of very simple definition files, and then the tools themselves, which we'll talk about later, what the actual tools are, the tools are responsible for actually bringing up the infrastructure, deploying the, let's say the virtual machines, the virtual networks, VPCs in AWS or Azure. So everything is really automated. So it's basically your infrastructure is as code and you should treat it as code, which means you can version control it in Git, you can track changes easily. So that's, I think what the Infrastructure as Code is really about, is going away from the old manual way of configuring and deploying infrastructure into this new realm of treating your infrastructure as if it was a kind of an application, as a code base. Another kind of definitions around that, that we should demystify is continuous integration, delivery in deployment. There's maybe a bit of confusion on those terms, because they're kind of similar. So continuous integration is basically a practice where developers checking code regularly into source control. And then your build system automatically builds that code, runs it through your automated tests. So you have instant feedback on if something was broken.
This prevents issues where during the release date, developers are trying to merge everything together. And that's just impossible because there's so many changes and something's going wrong. It's hard to debug. So this gives you an instant feedback loop on you checking code when you broke this build. Continuous delivery builds on that idea, on the continuous integration, where you try to release new changes to customers quickly. So basically in the continuous delivery, you can decide when you want the release. So you need to have an automated release pipeline as well. So on top of your automated tests, you also have an automated release process. Continuous deployment takes it another step further from continuous delivery where basically kind of every change that goes into the product is really quickly released to your customers immediately. So there's no, let's say there's no set release date.
Instead, the releases are continuously rolled out to customers, which allows you to get really fast feedback from the customer on anything that's broken or the features that you've released. I Think I already kind of mentioned what the version controlling it. So kind of source control of code and source control, even of your Infrastructure as Code. So most popular things I guess is Git and SVN, some places. This basically allows multiple people to work on the same, same application at the same time, by creating branches and merging code together, doing code reviews. So that's really a most, in today's, any business that wants anything to do with software.
Maybe the last two things is kind of immutable infrastructure and declarative versus imperative infrastructure. So I think Jason mentioned in the beginning of this, it's treating your infrastructure as cattle instead of pets. So, that's what immutable is. Basically you should be able to destroy your environment without having to spend a weekend rebuilding it. So you should be able to destroy your environment and rebuild it in a matter of minutes. So it's immutable. If there is a change, you don't log in to the machine and make a change. You redeploy the entire machine with the change. So it's always a fresh machine. So this avoids configuration drift where, if you have 10 machines, as certain machines might have slightly different configs than the others, just because of how you worked with them. But this avoids that because every time you make a change, the old machine, let's say it is a VM or whatever it is, is completely destroyed and replaced by the new version.
So this is kind of concept of immutable infrastructure. Declarative, what it means is, in Infrastructure as Code, you define your infrastructure in a declarative way. So use domain specific languages that these tools use, which we'll talk about later, to basically define the final state of the infrastructure, what it should look like. And you don't have to worry about how it's actually going to get to that state. That's the responsibility of the automation tools to get you from where the infrastructure is to the final state. So you just declare what it should look like. And the tool is taking care of the rest, of the heavy lift really. So I think those are some important terms in today's DevOps or Platform Ops worlds that maybe cause confusion when people hear them. So hopefully that explained it a bit.

Darius:
Yeah. I want to add one small thing, that this like all this definition are not totally separated. A lot of section overlaps one to the other. For example, if you're talking about continuous integration to the delivery deployment, there is also, there is no specified boundaries for that. Okay. So what this part of the continuous integration, is always part of continuous delivery. What is part of continuous delivery, is a part of continuous deployment, and vice versa. So yeah, so this is just the Lego bricks, but they're not totally separated.

Jason:
It sounds like this really entails a fundamental set of changes to the way I think about my infrastructure, the way I manage it. And it also sounds like there's some new skill sets that folks have to build. I mean, I can think back to when I was an admin myself, working in infrastructure, and there was a specific set of systems and applications that you had responsibility over and a very specific set of purpose built tooling for that part of the infrastructure.
This sounds like there's a bit more of a flattening out of the environment as a whole to treat it, as you said, like cattle that you won't feel bad about destroying on a Friday night, but what's more is that there's the code part of the Infrastructure as Code phrase, which infers that there's some level of codification that's going to happen. And therefore some basic development skills that the admins of yesteryear are going to have to take on. Given all of these, not blockers, but steps that have to be taken, I've got to imagine there's some gold at the end of that rainbow, right? What is it that's driving customers to go through the process of this transformation? What are the benefits that one can expect if they start to adopt these types of principles in their environment?

Roy:
One of the drivers for us for doing it was like we used to be really reactive to issues that were happening. And we spend sometimes weeks repairing systems. I remember there was one time we had VM-ware, which I think was it FreeNas as a storage. And it went down when we lost the FreeNas OS and we had to rebuild basically most of our infrastructure in the next month and a half. Things like this is one of the main reasons that I'd say people will start adopting this, is because nobody wants to be in that position of having to go [inaudible 00:15:33] work because the systems aren't there for them. So they'll try and proactively go. And okay, if the system does go down, like you were saying, you can easily destroy the old one and build a new one within minutes as Michal suggested earlier. For me, that will be one of the main reasons of adopting these kind of tools. Some of the other reasons for this is, you lose a lot of people from your organization, like it's natural that people leave. And what happens is like, they take a lot on the knowledge and how the systems are built. So, as you said, Jason, like is in you're working on this [inaudible 00:16:12] systems that have this particular way of working, but if you lose that person and they don't tell you that little nuance of how this thing integrates with another thing, and suddenly you have to try and reverse engineer how it all works when your [inaudible 00:16:28] company is using revenue, or there's a lack of productivity within the different teams you support.
So this is another real benefit of it is, I guess, it's all like in a repository where you can see exactly how it's configured and there's none of this sort of like, oh, there's this one little program that somebody wrote that is actually very integral, but nobody knows about. One of the instances I found out recently is like one of my SQL databases had a particular parameter in Azure and I didn't know about this, but it was integral to running. So like that was like one little bit. And like all that knowledge is amongst different people. If the wrong person was trying to recover from us, you could end up losing a lot of time and causing a lot of grievances, different parties.

Jason:
Funny that you mentioned that I can recall a bank that I used to work at and I had moved on. And it was four years later, I met up with my colleagues and they told me that they had just deleted the last Jason folder that I had in all the servers that I built and got rid of my front end scripts as well. So that definitely makes sense. It's also interesting that there's a lot of business benefits that you just articulated there. It helps the team responsible for the infrastructure for sure. But it also connects with risk reduction, right, for the business. I remove single points of failure and the fact that it can do things a lot quicker means that I'm also able to get services to market quicker. So a lot of reasons for organizations considering starting to adopt this model.
But let's take a little bit deeper and now we've got the basic principles. We understand the teams that are involved here. We understand a little bit about the transformation that has to happen to adopt an Infrastructure as Code model. But can you guys explain a little bit more about what my environment actually needs to look like to start bringing Infrastructure as Code principles in? And I guess connected to that is where do I start? How do I get started? Is this that CIO comes in and says, Hey, "you guys need to move towards Infrastructure as Code." Is it driven by a line of business that says, "Hey, we're moving too slow." Or is it more like a couple guys have a problem and start tinkering around with some of the tooling to move faster. Can you kind of expound on that a little bit?

Darius:
Yeah. So basically, first thing you need to change if you want to adapt to the Infrastructure as Code is the mindset, you need to change the way you're thinking about your infrastructure. Okay? So your infrastructure cannot be anymore like the house where three biggie lives and it's going to be constantly there and you can provide new [inaudible 00:19:24] and everything. Your infrastructure, you have to think about your infrastructure, like about something really ephemeral, like just a tool was going to do the job for you and you can keep it or you can kill it. You can keep it as is, or you can destroy it without losing the business part. So we need to treat our infrastructure as a thing which is like our minion. It's doing the job for us. And because it's just here temporary, but in the meaning of the temporary, I don't want to say it's just for a little moment, but it's doing like a quick and reliable job for us.
So, the first thing you need to change in a team, is a mindset. What do you think guys about that?

Michal:
Yeah, I think that makes sense because you need to change from the way you normally think. If you're going from manually configuring these things, you can either treat them like babies because every time something's wrong, you have to spend a lot of time fixing it because it's all manual. Whereas if you have it all kinds of automated, you can get away with a lot of things because you don't have to spend too much time fixing it because you just rerun the alternator and it will take care of most things for you. You don't need to worry about infrastructure too much.

Roy:
Yeah. Like one of the points I'd like to add, is people will ask you for stuff and it's so easy to kind of do it manually because it might be quicker. So trying to stay with that mentality can be tough and when the business is putting pressure on you.

Michal:
Yeah. I also want to add. Yes, Jason asked, who has to make the decision? Is it the CTO or is it someone from, let's say R&D or is it just the developers making decision, "hey, okay, let's move to infrastructure score because we're sick of manually doing this stuff." I would say it's the last one. I think it's kind of a natural progression in any person in this DevOps space, is naturally going to be interested in staying up-to-date with the technologies that are out there and just wanted to try out new things. And then they come across these Infrastructure as Code tools and automation tools, and they just want to go and try them out and adapt them into their environments to make their lives easier. So I think it's just naturally going to happen in companies. People just seek new things to try out and they end up with Infrastructure as Code.

Jason:
So basically happens organically driven from within the team. And presumably as the business starts to see the benefits or the business is going to get behind it, sponsoring it when checks have to now start getting signed to make this thing scale.

Michal:
Right. That's definitely how it happened in KEMP. We started playing around with these tools and started moving bits of our infrastructure to Infrastructure as Code, and using configuration management

Michal:
tools, immutable infrastructure, and nobody really paid much attention to it. But now we know the Infrastructure as Code, they kind of become more popular in KEMP. Yeah. It started kind of just our own little, let's say, playground. It's just evolved over time, over the last year, I would say, because we see huge benefit in it.

Jason:
So here's another question that maybe gets us starting to go in a direction of talking a little bit more about the specific tooling and plumbing that's required to support an Infrastructure as Code model. You use the word of ephemeral and we've talked a lot about how an Infrastructure as Code model can be more dynamic. Things can change. The whole environment can go down and you should be able to bring it back up quickly. That said, tech teams are responsible for keeping the infrastructure up. So I imagine that there's a balance that has to be struck. And my question is, how do you monitor this type of environment? I presume the principles are different from a traditional infrastructure, but I still need to keep track of the state of my environment. Is it healthy? Is it not? So that I can serve the business. What's some of the tooling and things that you put in place in order to do that?

Michal:
Yeah. So if you're talking about infrastructure monitoring, there's definitely a vast range of tools available. One of those we use is Datadog. It's a cloud platform that we use to monitor our infrastructure, basically. We can do different sorts of checks and alerts, email alerts, slack alerts, I think it can even do phone alerts to alert us of any... We can set custom alerts to different tress holds of things, memory, disk space and the state of the node if it's online, offline. So, that's kind of how we monitor things. But the other tools that are vital is actually the automation tools for working with Infrastructure as Code and deploying it. So there is also different tools out there, but let's say in the recent times, the most popular one is definitely Terraform and the kind of suite of tools that are offered by HashiCorp, which is a company that builds these tools for us.
So yeah, Terraform is a infrastructure deployment tool and this is what we use in KEMP. It covers a very broad range of providers like cloud providers and different hypervisors on premise. So this is the tool, the Infrastructure as Code tool that we primarily use in KEMP. There's different tools like configuration management tools, probably the most popular one that we use, and probably the most popular one on in the world is Ansible. Ansible allows you to do configuration management. It's different to deploying your infrastructure, this is configuring existing infrastructure in an automated way, also to avoid configuration drift that I mentioned before.
So how would you pick the tools for your specific project? The way I see it, there is not much picking because you will probably want to use the best tools that are out there. And those are in at this moment, I would say Terraform and Ansible for the majority of the workflows. If you are going very cloud specific, there is cloud specific tools in like AWS for Infrastructure as Code, they have their own service for that. There is also the Azure have their own services for it. But if you're looking for generic tool that can be used across your hybrid cloud or multi-cloud environments, then definitely Terraform would be the way to go in that regard.

Jason:
Why is that? What is it about Terraform? I mean, as you even highlighted here, there's suites of tools that are out there, dozens that claim to offer benefits, there's Open-source, et cetera. What is it specifically about that combination, Terraform and Ansible, that makes them good candidates when moving in this direction?

Darius:
Yeah, so basically from my perspective, I had a feeling, I felt a little bit like in the Truman show, like HashiCorp engineers were watching me over my career, they were gathering all the problems I had and they just solved this, they just gave me a solution for all my pains. Previously, we were struggling with environment to retrieve IP address of machine and assign this to the variable. Using the HashiCorp tools, we are not vendor log and we can do across so many environments. And that, it seems like it's just designed for us. And I think people have the same feeling across all the companies.

Jason:
So, most likely made for developers by developers. That sounds like folks that have actually been in these shoes.

Michal:
Yeah, that's exactly it. They're basically seeing these issues. They probably had the issues themselves and they solved it by developing tools to fix the issues they had. So that's really interesting. Terraform is just, I guess, one of the more mature tools out there for this and the documentation is absolutely amazing. The community behind it as well is really good. If you have issues, there's the GitHub page, which you can find a lot of answers. It's just the features that it provides. I don't think we've seen any other field that can do what Terraform can do basically. So that's why we use it.

Jason:
Now. What are the skill sets that folks need to start developing? Let's say I am a quote-unquote, traditional admin infrastructure type, and we're now moving the organization towards this direction, starting to adopt some of these tools. What are the basic skills that I should try to start building so that I can be in a good position as my organization makes this transition?

Darius:
Okay. So basically, if you want to start doing stuff related to the Infrastructure as Code, you have to have like a basic understanding of scripting and logic. You don't have to go deeply into the programming stuff. It would be nice if you have, if you go deeper in the programming stuff, let's say object oriented programming, et cetera. But to start it, it's enough if you have a basic understand of the scripting and the basic understand of the logic. These two things are totally enough to start with the Infrastructure as Code. And official Terraform HashiCorp documentation, because it's perfectly done with a lot of examples. And they're also providing like a basic free training for everybody who is interested in that stuff. So these two things are perfectly enough to start with Infrastructure as Code.

Jason:
Well, good thing is there's so much content that's available out there these days for building those tools. I mean, if you just look at some of the platforms like Udemy, or even the various blogs that's out there, Medium, et cetera, there's so many resources that are available for building these skills. So it's an exciting time to be in the infrastructure and operations world. Okay. So we've talked about all of the benefits that you can extract from moving to an Infrastructure as Code model. And we understand what the plumbing and the framework looks like, but it can't all be that simple. There's got to be some challenges that you can expect to come across as you start to go through this transition. Can you numerate what are some of the challenges or pitfalls people can expect to face and maybe how to combat them?

Roy:
I suppose one of the major ones, I see, is like time, sometimes you need a lot of time to kind of dig into these tools when you're trouble-shooting stuff. That's very specific to how you want to deploy. So it's like, basically you want to do something, but it isn't quite working the way you want, because, to the opposite of what we probably just said, there's times when it doesn't work just because it's Open-source. So it's trying to figure out like why it doesn't work, or maybe it's a language thing. Like we've come across where different words mean different things in different products. And because of the lack of kind of understanding between them, especially when you're using multiple tools, it ends up kind of maybe delaying it a little bit because you kind of have to figure out, okay, why isn't this working because, okay.
I need to understand what it means by this and this tool, but what it means like that in the other tool. That will be kind of like one of the major challenges I've seen. From a, like an organizational point of view, I suppose it's just, like I mentioned it earlier, it's a speed, right? It's like the speed of delivering things and people want things now, their things are always more important. So it's kind of trying to balance the, let's do this in the perfect world with the perfect solution versus what the business needs and [inaudible 00:31:10]. And especially when you're trying to do something, that's a little bit different to how the company works like there's culturally, they don't understand what you're trying to achieve until they see the huge benefits. So that particularly happens when you're... For us, right, we're a couple of guys in a team and we have to support maybe seven or eight stakeholders. Like there's no way you can achieve what you want to achieve with these tools in the timeframe you need to get all the benefits. So you're going to need to expand and teach people about what's going on and try and get them excited about it and get them using it so that you could actually get more traction within an organization moving towards that way. So it's kind of like creating like champions that will evangelize what you're trying to do.

Michal:
Yeah. Another challenge, I think, is a deep learning curve at the beginning. If you've never used tools like Terraform or Ansible before, it can be pretty overwhelming with the amount of things that they can do. Because they are very versatile tools. Like Terraform let's say, even has like 50 providers you can manage, Ansible has hundreds of modules. So it can get pretty overwhelming as the learning curve is pretty steep. But if you get the basic understanding of how the tools work and the syntax and stuff, you should just focus on the actual parts of the tool that you need to use and not everything that the tool can do. So it can be also challenging.

Jason:
Okay. So technical and cultural, maybe digging a little bit more on the cultural piece because that's come up at least three or four times in our discussion so far. Why is that a challenge? And I guess at a practical level, if we're trying to move in this direction, what are specific things that I might want to address in my team to optimize our success as we move to an IaC approach?

Darius:
So for example, if our organization is spread around the world, actually we have in KEMP. We need to be aware that different departments have a, like a technical related people. So we can have the admin that's platform ops in the different part of the world and approach to the things and approach to solving problems might be different. So it could cause, one team's expectations might be different than second team's expectations. And this happens when we're trying to get to the point where Infrastructure as Code is fully usable.
Because for example, we don't have this problem with creating and developing application when this team is put together from the beginning of the project. When the team is like separated and we have a local admins, we need to get people to use that kind of mindset. So there is like learning curve. We need to like match people expectation. That's why the cultural, and the, let's say, location differences are a challenge in getting things done. So the lack of information between the locations, the communication in the certain domains, and certain area might be slow at the beginning because of the understanding of this mindset.

Jason:
Okay. Got it. Thanks for that clarity. So, certainly some challenges, but sounds like they're not insurmountable and the benefits far outweigh them. I mean, I can think of a lot of admins that would really be thankful for an environment that could break on a Friday night and within minutes they could have it back up and running. When we all who've been kind of in the light of fire as it were. So we covered quite a lot today on the topic of Infrastructure as Code. We now have a pretty good picture of the basics of how this actually all works. The teams that are going to be most interested in it, how to get the projects off the ground in the first place, along with some of the challenges that one can expect to face, maybe as we wrap it up, let's just go around the room and share key takeaways that you want our listeners to keep in mind.

Michal:
Yeah, for me, I think I would say don't be afraid to try it. It may be difficult and overwhelming at the start, but it will definitely bring you long-term benefits if you move to this Infrastructure is Code.

Roy:
Yeah. For me, like it's in, just have a bit of time and patience for this, you're never going to change the way that people see things over night. So you just need to give the business enough time to catch up with you. One of the other things with that as well is the work you put in now, you will see it in like six months, nine months, a year's time, and the type of work that you were doing maybe a year ago, won't be cropping up. So it actually means you'll have more time to research and look at new technologies and things like that. So instead of reacting, you'd be more proactively and continuously improving your environment.

Darius:
Yeah. Also, keep learning, keep teaching other people, just try to get excited with the new things. What else we can say? Don't drink and drive.

Jason:
I think that's a great note to end on. Michal, Roy, Darius, it's been a pleasure chatting with you guys on this interesting topic of Infrastructure as Code. I can't wait until our next get together. Thanks again. And thanks to all our listeners for tuning in.

texture

Optez pour Progress Kemp dès aujourd’hui

Essayez Progress Kemp gratuitement

Facile à déployer et à configurer, avec un accès aux modèles de configuration et aux guides de déploiement pour être rapidement opérationnel.

Démarrer une évaluation gratuite

Nous contacter

Vous avez des questions ou vous souhaitez acheter ? Contactez un expert Progress Kemp qui saura recommander la meilleure solution pour vous.

Contacter le service des ventes