Infrastructure as (a) Code (Iac or IaaC) is currently state of the art and is used in almost every modern cloud architecture, but what are the downsides of this trend that everyone seems to follow?
Infrastructure as Code offers the excellent possibility to map resources and their configuration and to reuse them as desired. But what does this mean without a technical deep dive?
Cloud platforms, as an example my favorite, like Microsoft’s Azure Cloud offer us an enormous range of services of different size, price range and technical utility. Some of these resources, PaaS and SaaS services, have a far greater configuration effort compared to the familiar IaaS services that often find their place in lift-and-shift migrations. This configuration is not just written on the side, but requires expertise, planning and an increased expenditure of time.
If we were to deploy and configure such a resource in valuable time via the Azure user interface, the Azure Portal, then we would have achieved a lot for the time being. But how does it look now in the case of a backup? Or more positively thought: In case of a duplication of resources? We would have the same effort again, only with a bit more expertise and experience.
Pros
To be more sustainable in this regard, I would recommend Infrastructure as Code to everyone. It may seem like a bottomless pit at first, but in the long run it brings some benefits and I’d like to talk about those first.
Backup as Code & Reusability
The great advantage of mapping the entire infrastructure, including configuration, in code is clearly the recoverability and reproducibility of an exactly identical resource in a different environment. Thus, IaC can certainly make up a large part of the backup concept of a cloud platform. Especially for stateless applications, this flexible recoverability is a gamechanger.
In terms of code reusability, not only can any resource be used and created elsewhere as often as desired, but entire infrastructures can find their place in other regions of a cloud within minutes or hours.
Inventory-Management
…is another plus point worth mentioning. Of course, it brings effort to describe every resource or every required resource type, but it also makes you think again about the logic of the existing systems and applications. Is everything really necessary as it is or can it be made leaner and nicer?
Testability
Thanks to IaC, infrastructure is not only more secure, but also testable, such as software. Even before you deploy, you can test whether the constellation works or whether the configured resource can be created at all.
Change Automation
Since resources and changes are represented in the code itself, it is easier to automate and prepare for these changes. Downtime and effort can thus be kept to a minimum.
Human Errors
Since the code itself is tested and checked for feasibility during deployment and co, human errors can be limited. Typos, sloppiness or accidental deletions can either be prevented completely, limited or recovered more quickly.
Cons
Financial and time effort
Separately, but also connected somewhere, because time is money. Knowledge in dealing with IaC is especially currently very valuable and thus also partly very expensive. Describing the entire infrastructure or even just parts of it from scratch involves enormous efforts and hurdles. Certainly many see the goal in front of their eyes, but the way to working code with good logic is long and hard, because who wants stupid code? Terraform as an example of the most common IaC language offers many possibilities to implement such logic and it is also recommended for everyone.
Because even once the infrastructure is in code and has also found its way into the corresponding cloud, you naturally also want to make use of the advantages of the cloud afterwards. Rebuilding, restructuring and making things more efficient are therefore the order of the day. This means that the code and the logic must be as adaptable and expandable as possible, because after all, this should not become a bottleneck.
Increased operating expenses
Operating a cloud platform is not a simple matter due to the enormous number of possible resource types and the broad mass of configuration options. Complexity always entails an increased effort somewhere. In order to be able to support and debug all of this, not only is a good connection to Microsoft and the applications themselves required, but also an extremely broad knowledge of the cloud itself. At least basic knowledge in most areas is therefore essential in order to be able to troubleshoot a wide variety of things at least okay to good with Azure support.
Infrastructure as Code does not play into the cards, of course, and increases the required knowledge and skills of the support engineers by a not exactly small amount. Since support and code often do not always match, this is new territory for some, but nevertheless probably the most important component in terms of backup and feature requests and existing resources.
Now, to get to the point with regard to this disadvantage, what exactly is the problem?
If you want to make changes to a resource, you would do this without IaC by hand in the portal without thinking much about how to restore this at some point, because no one will ever be able to even begin to remember every configuration of every resource in an infrastructure.
With IaC you have to do this in the code. Is this configuration option missing? Then this must be built into the existing logic. Is a resource missing? Then this must be described or an already existing module must be used for it. It is not uncommon to encounter error messages here and certainly not everything is the task of the operations team, but the operations team must maintain the code in part, but for the most part just use and apply it. Variables must be maintained, resources added, tested and much more.
All in all, however, it is a feasible thing, which I can confirm from experience. I myself was once part of just such an operations team which, as former Windows admins with no idea of coding and cloud, had to operate and support a cloud platform with its almost infinite resource types.
Conclusion
Do the advantages or disadvantages outweigh the disadvantages? Should I use IaC or not?
Yes, it’s not as golden as many describe it and you shouldn’t expect lightning-fast successes either.
However, if you plan with a lot of scaling, if you need flexibility or similar resources in the same constellation many times, then code and automation can save an enormous amount of time and money in the long run.
Schreibe einen Kommentar