Breaking Down The Advantages & Disadvantages Of The IaaC

 

As we know today, the Cloud is a mighty powerful thing.  After the COVID-19 pandemic, many businesses have made their move to the Cloud, when it is on the AWS or Microsoft Azure Cloud platforms (in full honesty, I am more partial for Azure, especially with the tools that they available for the SMB owner). 

It seems like that on a daily basis there are more and more tools that are becoming available.  Let’s face it, the Cloud has many advantages, especially when it comes to price affordability and especially that of scalability.

But there is yet another feature of the Cloud that is also intriguing to me, and in fact, I just came across in an article today.  It is known as the “Infrastructure as a Code”.  You are probably thinking “oh great, another as a Service”. 

My thoughts somewhat also, but this one is rather different from the others.  First, let me give the technical definition of it, which is as follows:

“Infrastructure as Code or IaC is the process of provisioning and managing infrastructure defined through code, instead of doing so with a manual process.

As infrastructure is defined as code, it allows users to easily edit and distribute configurations while ensuring the desired state of the infrastructure. This means you can create reproducible infrastructure configurations.”

(SOURCE:  https://www.bmc.com/blogs/infrastructure-as-code/).

If I have it right, it is simply another way to manage your Cloud based deployment (whether it is on the SaaS, the PaaS, or the IaaS) rather than having to go through any manual re configurations.  Since source code can be used over and over again, this is just another way to make to make your life easier in the Cloud. 

Just like AI, Infrastructure as a Code is just another way to automate some of your more mundane and ordinary processes in the Cloud, wherever it may reside at.

These processes are actually recognized as pieces of code by the Cloud, thus making management and provisioning of files even easier, as well.  But even with this huge advantage, the “IaaC” (this is the acronym for it) also brings along a set of disadvantages as well.  

First, is that it is not all bullet proof in terms of security.  While it will let you do things in the Cloud faster, you will also face greater risks of misconfigurations and settings not being applied properly.

Of course, the end result of all of this, is data leakages in occurring, which is the last thing you want to happen to your business.  But yet, another key area in which the IaaC is used is in the Software Development Lifecycle, which is also known as the “SDLC” for short. 

It is this process that software development teams use create a Web application right from scratch.  Although the Cloud is used in this process, many of the tools that are needed are typically rented and used on as needed basis.

For example, if the software development team needs to create a test server, they can create a brand new VM and its corresponding databases on a whim, and then delete them when it is not necessary to have them any longer.  This process, of constant software development and code reuse is also technically known as the Continuous Development and Continuous Deployment”, or CI/CD for short. 

When the IaaC is used any manual processes that are involved with the source code development becomes fully automated.  It is also quite useful in deploying the various APIs that are needed, as well as checking them for any type of security issues that they may have as well (which is a huge, hot button issue today). 

It also creates a baseline of each of the source code modules that have been compiled, so if a software developer has to roll back to a previous module or even build, they can do so automatically, and in a fraction of the time it would normally take. 

However, even in this environment, misconfigurations can still happen, and they do occur.  So, here in lies the second major disadvantage with the IaaC.  Although it can do a spot check for any errors as the software development process continues (imagine a continuum of going from left to right), it cannot catch for any misconfigurations that go in the reverse process, which is from right to left. 

In this case, it is highly probable that the software developer(s) is trying to roll back to a previous source code module, but is doing it manually, which is something that the IaaC simply cannot track, at the present time.  If this rolling back process is not done properly, it can have a cascading, negative effect on the other source code modules as well. 

The third area in which the IaaC does not do well are in those Cloud environments that are simply too large.  For example, if you are just using one type of deployment model, it can work quite well. 

But if you are using all three of them in tandem with another, then it will barely work at all (at least this is based on my understanding of it).  And once a misconfiguration is leaked into this kind of environment, it is usually quite difficult to catch and isolate.

Therefore, if your business is in this large-scale environment, it is always prudent to use the IaaC in smaller chunks rather than having it to try to digest everything all at once.  Therefore, if you are going to introduce the IaaC into your environment, it is first best to test in a sandbox environment first, correct any errors that you find, and then release it into the production environment. 

But again, the key here is to do it bit by bit, and not huge in huge chunks all at once, where mistakes are sure to happen.

My Thoughts On This:

To be honest, I am not a software developer by any means.  And probably there are areas of the IaaC of which I am not familiar with it all.  But it’s a learning curve, and I plan to keep up with it the best that I can.  Stay tuned for more about this new thing for the Cloud throughout this year!!!