Infrastructure as Code or IaC is one of the latest buzzwords. So what do you need to know about it? And is it a must have, nice to have or something for others, but not you?
In this video, Paavo Pauklin interviews Maciej Rostanski, a top cloud expert, on Infrastructure as Code and what executives need to know about it.
You’ll learn:
• What is Infrastructure as Code?
• Why IaC matter? What are the benefits? Why is everybody talking about it?
• Can IaC help mitigate risks, and how to get best results?
• Conclusion? So what is our expert’s opinion? Should you go for it, consider or skip it?
Watch the episode on YouTube and remember to like & subscribe.
Video subtitles
Paavo: "Hello everybody, welcome to listening to another series of Netcorp mini series of expert talks. Today we're going to talk about infrastructure as code, and I'm proud to present that I have today with me my good colleague Maciej Rostanski."
Maciej: "Hello."
Paavo: "Hello, who is a seasoned cloud architect and DevOps engineer. He has been a part of many projects involving cloud platforms such as AWS and GCP, and also Maciej has been academy lecturer and author of many IT books. P. S. He's definitely the most talented cloud architect and DevOps engineer that I've had the pleasure working with. So he's a true expert."
Maciej: "Oh, thank you for this introduction."
Paavo: "Well hey, infrastructure as code. Everybody can Google or ask from Wikipedia what it is, but in your words, to a business person, what is it and why is it important?
Maciej: "Sure. So infrastructure as code is about bringing the approaches and principles of the software engineering into the cloud infrastructure management. And you basically switch from having procedures and some kind of instructions how to set up the environment for the people to having a code and a tool that uses this code, utilizes those instructions to just run it through the cloud platform and create this infrastructure as you want it, or manages this infrastructure and looks for changes in this infrastructure. Whatever you need it to change, it will try to change it as you wish. "
Paavo: "Okay, so it's kind of automated on the code level, but why is it important? Why should one use it? What are the benefits?"
Maciej: "All right, well, imagine the situation that you have a team of people working with your infrastructure. Basically, when you don't use infrastructure as code, you have guidelines for those people, some runbooks and instructions, how to set up the infrastructure that those people try to expand and try to develop for any new infrastructure and any new environment of this infrastructure. And when you have the infrastructure as code, those very same people work on the code for the tool to create the same thing. What is the difference? The difference shows when this infrastructure is becoming more and more complex. The people that operate the infrastructure are only people, and they tend to do mistakes. And there are some things that they will change in the infrastructure and they will forget about that, or they will do and not document it, and they will change and forget about telling their colleagues that they have changed it. When you have infrastructure as code, the tool inspects everything. The tool runs it through the infrastructure, examines the changes that have been done, and tries to tell you what needs to be changed to achieve the very code, the very essence of your infrastructure that is contained in this code that you have been running."
Paavo: "So it reduces some risks of mistakes, and it also reduces the dependency on one specialist, for example, because the logic is written in the code, does it provide any value against certain risks?"
Maciej: "Yeah, of course. Well, infrastructure as code I am an advocate in infrastructure as code, and it has helped us with various situations. Well, the most important thing is that you have a documentation of the infrastructure within the code, so you can analyze it. You can even give it to auditor to analyze the code, because this is the infrastructure itself contained in this code. And the specialist can look at the code, examine the infrastructure, and probably propose some changes or analyze any security risks. You can even do a static code analysis on an infrastructure that is written as a code. The second thing that comes to my mind instantly is, for example, disaster recovery. You can set up any procedure for disaster recovery to be based on this infrastructure as code. You are able to run this code anywhere. You can recreate this infrastructure anywhere you want, and this is crucial for some disaster recovery procedures, for example."
Paavo: "Okay, let's consider I'm an IT team lead and I need to set up the infrastructure. Is there any downside of choosing infrastructure as a code, both time or investment-wise?"
Maciej: "Well, it's going to be at the start, because when you will try to use this approach, when you will try to run infrastructure as code with the team that is not experienced, with a team that doesn't have the skill set, it's going to take a bit of time to adjust, and every new project will probably require more time at the start. Well, I would say that this is an investment. This is not a loss, this is not a problem. This is an investment because you are investing in a project, first of all, because if you do the infrastructure as code, probably it will take more time, but you will be able to recreate this infrastructure anywhere. You will be able to create more and more versions of the new environment, like a UAT environment, production environment, testing environment, staging. It's going to be from the same code as the development platform. And the second thing, you will have the tool for collaboration. You will have the team effort, be able to work on the same code, be able to work on the same infrastructure and build on that, because for every new project, your team will be more and more experienced, will be able to use even the same kind of code, even the fragments of the code, like modules or libraries, that will become handy for any other project that this team will develop."
Paavo: "Okay, but still, is it suitable for, let's say, all size of projects are only for bigger, larger projects?"
Maciej: "Okay. It would seem that infrastructure as code is suitable only for a larger project that makes sense because you can say, all right, for a small project, it's not worth the effort. I would say it is. Let's just repeat the word investment. If you would ask me, I would advise every time to use some kind of infrastructure scope tool like terraform on Pulumi, whatever you need to strengthen the skills of your team, because every other project that they will do, they will do it quicker. But at the same time, if this project is only for research and development and you are sure that you're not going to use any new environment, that maybe you can make a decision not to go that way, and then I would say, okay, most of people think about their projects the same way, and then it turns out that they do function quite correctly, that they bring value and they are more and more developed and they are expanded. And that's the time when you wish you have started with infrastructure as code, because it's going to be more difficult to bring the infrastructure as code into the ongoing working huge project than start with the small one. That's the moment you should start with infrastructure as code. Really."
Paavo: "Okay, so just to sum it up, the pluses and minuses of infrastructure as code, and please correct me if I'm wrong. First of all, it reduces dependency on certain one employee and one skill set. It creates transparency in what has been done and how the setup has been built up."
Maciej: "Definitely"
Paavo: "It's a good protection against disaster management or some kind of risks about setting or losing your environment. And it helps to also easier and equip set up exactly the same environment to duplicate environments. Sure, it is an investment. It costs a bit more in the beginning, but it has many opportunities down the line to save costs that you don't have to do things again and again and again. And it's suitable for basically most of the projects."
Maciej: "Yeah, that's my opinion, of course."
Paavo: "All right. I hope this brought some new lights and ideas into some of our listeners heads. And if you're going to be in front of the same question how to set up the infrastructure, maybe this is going to be useful. Thank you very much, Mache. It was always pleasure talking to you and like, thank you everybody who listens. Bye."
If you have any further questions or need help, contact Paavo.Pauklin@netcorp.ee.
