Podcast Summary - Infrastructure as Code (IaC)

Podcast Links:

PODCAST OVERVIEW (INFRASTRUCTURE AS CODE)

The one and only hypothesis to scale an application from high to low or vice versa, ultimately be the Automation and DevOps. While everyone wants an escape from the nuisance of limited-scale deployment, no one has the time and patience to carter the challenge of delivering a great user experience within cost optimization whenever the demand spikes.

This is where Infrastructure of code (IaC) kicks in, paradoxical as it may sound IaC is the finest way of provisioning infrastructure going hand-in-hand with configuration the same way you handle an application code. Join industry experts Tim Davis (DevOps Advocate for env0) and Rob Hirschfeld (CEO of RackN), as they take you through the nitty-gritty of IaC.

Dive into the world of IaC as we give it all to relinquish your thirst for a provisioned infrastructure, from tools to collaborations and pitfalls of IaC, this podcast has all the diversified knowledge that can come in handy. The sections below elaborate on the uttermost giveaways of this podcast’s episodes, keep up with reading both of the episodes sections if you want to be sure that IaC is the one you’ve always been searching for!

1.1 EPISODE 1: AVOIDING INFRASTRUCTURE AS CODE (IAC) PITFALLS

Tim Davis shares his wisdom on the possible pitfalls of IaC, the topic discussed is not as negative as it sounds. Nevertheless, IaC is for everyone and an awesome thing if approached correctly with regards to the people, processes, and tools involved.

Kicking right in with the generic IaC talk, the episode starts with pointing out the right audience that goes across the board involving the developers and infrastructure folks. Tim explains, that while a lot of minor issues can cause a massive pile of pitfalls, the beauty of IaC lies in a collaborative effort between the developers and infrastructure/ops team, implying that there is no such thing as DevOps rather fostering communication between the Devs and the Ops.

1.1.1?ACTUAL PITFALLS OF IAC

The way Tim sees IaC pitfalls, these well-off challenges are categorized as cultural and communicational. Putting hands on a keyboard for coding prior to engaging properly in code designing and research is never a sumptuous idea, neither can one simply jolt CI/CD Pipeline and call it DevOps. Quite inevitable it is the use of the right tools and frameworks that never take away anybody’s job but define the responsibilities that developers and infrastructure people have to commence individually. The pitfalls of IaC pointed out by Tim are:

1.1.1.1 PICKING UP THE MOST SUITABLE FRAMEWORK:

Enchanting the first and foremost importance in the IaC is picking up the righteous framework. Exceptional research plays a crucial role in selecting the framework for IaC that is best suited for people as well as the organization. For example, a prompt decision is vital to start the IaC journey with either a cloud-specific or a non-cloud framework, as pulling out from one platform and deploying on another can cause unrecoverable disruptions. As Tim elaborates seeing people trying to pull out code from AWS and deploying of Azure, it’s just not going to work people!

Despite this, there are options for SaaS providers to streamline all of your favorite toolsets as one of the podcast hosts indicated using a SaaS provider to create MongoDB instances for Google Cloud Framework a long time ago.

1.1.1.2 SELECTING YOUR DREAM TOOLS:

At the end of the day, it’s always that one tool that is successfully doing the job for you and fast, as Tim says. Consistency across a tool versus using 2 different tools must be figured out by an organization that cost analysis and supportability.

1.1.1.3 HYBRID OR SINGLE FRAMEWORK, WHICH ONE IS BETTER?

Expertise makes you a swift decision-maker, as Tim quickly responds that a single framework is always a better option, as you are managing a single set of tools. That being said a single framework is much easier to scale up and down rather than a hybrid framework, whereas the issues are concerned, platforms like Terraform have a rich and diverse community where there will always be somebody who has pointed out the issue that you are facing.

1.1.1.4 ROLLBACK:

Keeping it short and simple, Tim explains that rollback is basically making a new change whether it is considered to be one or not, thus, it’s not the framework that blows up while a rollback but the process and methodology of doing so.

1.1.1.5 RISKS OF RELYING ON A CLOUD-BASED TOOL:

The value that you gain from a centralized platform far outweighs the risk of having a specific glitch refraining the platform to operate for a day. The visibility, centralized state management, code design customization, and centralized infra deployment are all well worth it.

Nevertheless, merging the code of infra and app should be kept relatively separate and this is 100% up to the people and process. Subfolders can be of great help in minimizing the number of changes.

1.1.1.6?SECURITY OWNERSHIP IN IAC:

Handling the security in IaC comes down to the in charge of the security posture, however, it doesn’t mean that he/she is crafting the security policies so everyone needs to be involved. The foundation of IaC is the concept of the constant building therefore security needs to be involved from the initial phases. In IaC there are different attack surfaces so are there several security frameworks (cloud best practices) out there to cater to such attacks, such as Terraform Cloud.

Then there are security custom write-scripts such as TerraScan and Open Policy Agent that leverages the power of making security policies from scratch and setting boundaries. Although, customization can be daunting as you have to implement security from scratch such platforms are ‘different kinds of beasts’ as Tim calls them.

1.1.1.7 TESTING IAC

There are a lot of different ways and tools out there to check how well is the code written as well as linters for checking the code syntax. Additionally, using regular development methodology and traditional SDLC is simply a good approach for testing IaC, where this works exactly the same as unit testing.

1.1.2 TIM BREAKS DOWN THE METHODOLOGY OF DEPLOYMENT IN TERMS OF REPOSITORIES:

There are 3 major entities at work:

1. CI/CD Pipeline or Automation Tool
2. Infrastructure Code
3. Application Code

CI/CD Pipeline will pull down and clone the repository hence deploying an infrastructure. After getting its output of connections, it will deploy the application code. Now it doesn’t matter where it is pulling from, it could be 1 or maybe 2 repositories. The significant thing in this process is the access management, absolutely depending on the people and the security level of the organization.

1.1.3 TIM ELABORATES ON THE CONCEPT OF DRY:

The methodology of DRY is an outcome of pitfalls emerging from app code versus infra code, Tim explains that DRY methodology is basically creating smaller or repeatable codes. In IaC there are multiple productions and if the names in the code are hardcoded, they can’t be reused, ultimately copies are made each time there is a need to reutilize the code. With DRY methodology the names are given variable calls in that way you are only managing one set of code. No more copies are required!

With DRY, you only have one set of code and by creating modules you are further breaking down the code into smaller chunks rather than bigger templates for reuse. Despite there being tools out there to make your code DRY, practicing the DRY methodology when writing code from scratch is always a boon.

1.1.3.1 WHAT IS THE OPTIMAL CODE SIZE?

The answer to this again goes back to the DRY methodology, where the smaller chunks of code are always considered to be the optimal ones. If the code is in the form of smaller chunks and modules there will be a need to only check-in that specific module rather than checking the whole bunch that needs not to be checked.

1.2?EPISODE 2: INFRASTRUCTURE AS CODE SHOULD FOSTER INFRASTRUCTURE AS COLLABORATION

Reaching out after hearing the last episode, Rob cornerstones the significance of tools, teams, and collaboration, whilst elucidating the effects of culture and fostering efficiency within IaC.

Deeply invested in the world of infrastructure, Rob has taken the discussion in the last episode one step further by unraveling the concept that you don’t want your pipelines to be DRY but just the code and its modules as it is all about how you structure the infra delivery around the pipelines.

1.2.1 INFRASTRUCTURE PIPELINE

Rob calls Infrastructure Pipeline a CI/CD pipeline but for the infrastructure, which is composed of modular code that is reusable. These modules can be picked up by various users and teams to be benefited. A CI/CD pipeline starts off with 2 or 3 teams working together but as it expands to get more people involved, it links up to become an infrastructure pipeline that may possess production, security team, ops team, and even observability components baked into it.

1.2.2 TOOLS

Tools are definitely there for a reason but they have to be serving a purpose, as Rob says, the whole purpose of utilizing tools is trying to build the automation that is the least about the language used and most about how the teams collaborate together.

Tools definitely have an impact but so does the way a team is structured. Each team uses a tool that may have evolved over time, but if the tools are not working together, communication becomes of utmost importance to not only fit the tools within the pipeline but also keep the pipeline going. This is what they call increasing the agency of the team and minimizing the distraction.

Teams have to embrace that it is a complex way to keep all the tools collaborating with each other but ultimately it will help the organization to work smoothly through all the teams and tools involved. Talking about the teams, Rob pinpoints the next discussion on Platform Teams.

1.2.3 AN IDEAL TEAM

According to Rob, the idea of a full-stack engineer is toxic, because it’s always focused on individuals not on teams and these individuals have to change responsibilities through the whole SDLC, basically over-burdening them. Rob goes on to say that siloes are not bad if they are good in their expertise, however they become toxic when they get territorial and lack collaboration.

To cater to such a problem, Platforms teams are required and make them acknowledge that they are working in a complex environment and have to individually foster code reusability. There are 2 basic ways through which platform teams can resolve code obstruction across the entire organization:

• Having well-defined inputs that are modular small components of work.
• Making the code immutable that goes into the system and putting them in a bundle. This way, for a simple fix the whole bundle has to be revamped and connected properly.

In a nutshell, the platform teams are flexible performs reactive infrastructure programming, and have the ability to accelerate teams all across the organization if they can get those team to build a code that is reusable.

1.2.4 KEY TAKEAWAYS

• We need to think through the concept of an infrastructure pipeline that initially may not need to connect everything but just the 2 simple ends will do the work as long as it is creating forward benefits.
• The tools we use in IaC need to reinforce collaboration.
• We as teams need to embrace the complexities as they are not bad or evil but always serve a purpose.