“The enabling idea of infrastructure as code is that the systems and devices which are used to run software can be treated as if they, themselves, are software.”
Kief Morris, Author, Cloud Specialist
Look into above infrastructure and think about the pain of managing IT infra.
Historically, managing IT infrastructure was a manual process. People would physically put servers in place and configure them. Only after the machines were configured to the correct setting required by the OS and applications would those people deploy the application. Unsurprisingly, this manual process would often result in several problems.
•The first big problem is cost. You’d have to hire many professionals to perform the necessary tasks at each step of the process, from network engineers to hardware maintenance technicians.
•The next big problems are scalability and availability. But in the end, it all comes down to speed. Since manual configuration is so slow, applications would often struggle with spikes in access, while the system administrators would be desperately trying to set up servers to manage the load. This necessarily impacts availability. If the organization didn’t have backup servers or even data centers, then the application could be unavailable for long periods.
•A third major problem is monitoring and performance visibility. Now that you have all of the infrastructure in place, how do you keep an eye on it to ensure it’s performing optimally? When you have an issue, how do you pinpoint exactly where in the infrastructure the issue is coming from? Is it the network, the server, or the application?
•Last but not least on our list of problems comes inconsistency. If you have several people manually deploying configurations, discrepancies aren’t going to be unavoidable.
What is Infrastructure As Code?
Infrastructure as code is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.
Or in simple words — Infrastructure as code (IaC) means to manage your IT infrastructure using configuration files.
The key takeaway from the definition is this: Before IaC, IT personnel would have to manually change configurations to manage their infrastructure. Maybe they would use scripts to automate some tasks, but that was the extent of it. With IaC, your infrastructure’s configuration takes the form of a code file. Since it’s just text, it’s easy for you to edit, copy, and distribute it. You can — and should — put it under source control, like any other source code file.
Benefits of IaC
•Automation/Efficiency — By employing infrastructure as code, you can deploy your infrastructure architectures in many stages. That makes the whole software development lif cycle more efficient, raising the team’s productivity to new levels.
•Speed — The significant benefit IaC provides is speed. Infrastructure as code enables you to quickly set up your complete infrastructure by running a script. You can do that for every environment, from development to production, passing through staging, QA, and more. IaC can make the entire software development lifecycle more efficient.
•Repeatable/Consistency — Manual processes result in mistakes, period. Humans are fallible. As you’ve read, manual infrastructure management will result in discrepancies, no matter how hard you try. IaC solves that problem by having the config files themselves be the single source of truth. That way, you guarantee the same configurations will be deployed over and over, without discrepancies.
•Accountability — This one is quick and easy. Since you can version IaC configuration files like any source code file, you have full traceability of the changes each configuration suffered. No more guessing games about who did what and when.
•Cost — One of the main benefits of IaC is, without a doubt, lowering the costs of infrastructure management. By employing cloud computing along with IaC, you dramatically reduce your costs. That’s because you won’t have to spend money on hardware, hire people to operate it, and build or rent physical space to store it.
IaC best practices
•Make code your single source of truth. You should explicitly code all the infrastructure specifications in configuration files. Your configuration files should be the single source of truth for all your infrastructure management concerns.
•Version control all of your configuration files.
•Test and Monitor Your Configurations. IaC is code, and like all code, it can be tested. By employing testing and monitoring tools for IaC, you can check for errors and inconsistencies in your servers before you deploy them to production.
Different IaC tools
•Terraform
•Ansible
•AWS CloudFormation
•Chef
•Puppet
•AWS CDK
No tool can do everything and each one is great in a specific area. IaC tools automate tasks in different categories for different phases:
3 main categories based on phases:
•infrastructure provisioning
•configuration of provisioned infrastructure
•deployment of application
Moreover, the IaC tools differ in the way HOW they work:
•declarative vs procedural : Procedural language is also often referred to as imperative language and it outlines a specific set of steps that must be taken in order to arrive at the desired outcome. Declarative language tells the program what needs to be done and allows the program to figure out the necessary steps.
•mutable vs immutable : A mutable object can be changed after it's created, and an immutable object can't
•agent vs agentless : sometimes agent is required to do the job.
For example, here’s a comparison of Terraform and Ansible
Which one should you use?
Find more details about AWS CDK in below article where I have tried covering everything about it on high level
Infrastructure as code is a crucial part of the DevOps movement. If you think of cloud computing as the first step to solving many of the problems caused by manual IT management, then it’s fair to say the IaC is the next logical step. It takes cloud computing to its fullest potential, and it frees developers and other professionals from performing manual, error-prone tasks.
Top comments (3)
Never have been a big fan of the cloud, to many eggs in one basket so to speak.
Who is to blame when your site gets hacked (and it will) the cloud provider our the developers who created it or some third party?
IMHO developers need to get out of the mind set of create it as fast as possible, as cheaply as possible not once stopping to think about the security implications of thier choices.
Call me old fashion but I like being in physical control of my machines, I don't like the idea of a cloud provider being able to turn my site off if I violate the cloud providers policies.
But anyways not a big fan of the cloud.
While I see your points I think you've got too much of a "Cloud is bad" rather than "Cloud has a different set of issues to be aware of"
In terms of "too many eggs in one basket" : Yes one of the major cloud providers has had multiple occurrences of "Single point of failure" taking down their entire cloud. You can diversify over cloud providers, You can also use cloud providers as burst capacity.
Who's to blame when the site gets hacked? Well who's to blame now? Specifically please provide details of when the compromise was due to the cloud provider rather than the customer. I'm talking hypervisors / API's weren't secured rather than customers didn't bother to secure their presence eg An open S3 bucket is the customers fault.
Developers need to get out of the mind set: Dev's are only in that mindset because they have been conditioned to it by senior management. It's senior management who want time to market to go through the floor, They want it for free and security costs money so sadly these days most senior management think the cost is greater than the risk.
I don't like the idea of a cloud provider: I've got news for you ANY provider will terminate if you breach contracts. The difference here is that many cloud providers have bigger PR departments who are more proactive and protective. Most come from the US where there is a greater tendency for people to seek redress via the courts and the courts are typically going to award higher settlement & costs. As such there are people watching for anything that might cause them problems. Most smaller providers simply cannot afford to have those sort of staff.
Don't get me wrong I think too many people / places have gone cloud crazy, but the reasons that you put forward are not confined to "the cloud"
You have a point there, and many thinks same way. But on the contrary I feel the security on cloud is pretty strong, I can be little worried of the hardware failures but have not heard much of security issues, unless we design it in a way that can be hacked.