Howdy!
In this article, we will talk about non-technical topics/Q&As that covers anyway IaC concept.
Have you ever done any task without taking care cause and effect relation?
It’s of course not a poll but I’m a bit sure that most of you did this in somewhere your work/social life because of the situations that you faced. If we look at today’s trends, it can be a very valid situation especially for new concepts/architectures that we hear frequently, such as IaC. “Let’s design our infrastructure by using IaC, write our application in accordance with microservice architecture, let’s use Go” etc. But before that…
- Do we really need to use it?
- “Why” should we apply it?
- What should we expect in the long/short term?
- Where should we start? How do we proceed with a plan?What should we pay attention to?
These questions are perhaps some of the most fundamental/correct questions to ask before starting to use not only IaC but all similar approaches. In this article, we will try to find short answers to these questions in terms of the IaC concept, and aim to better understand and apply the IaC concept. Most of the views here reflect what I can see from my reading, listening and experience.
Before to start, if you’d like to check out first article of the series, click the below link. At the first article, we examined how to building infrastructure in stone age, disadvantages of it and revolutions that has been made against to them.
Here is the questions and their possible answers…
→ Do we really need to use it?
As you know, IaC enables you to deliver your IT infrastructure faster, it ensures that the effort and risks of making changes on your existing infrastructure are reduced with rational code usage approaches, just like the software code. At the same time, it aims to shorten problem solving times with correct resource use, reliable systems and less coupled structures. That sounds good…
Some companies and their teams say they haven’t made much changes once they’ve set up an infrastructure, and if they do, it’s very rare. Besides, there is only one way for them to build a system from scratch. At the same time, some people in workflows make change processes difficult, while others argue that change is temporary. Therefore, no matter how difficult and manual it is, they do not turn their processes into concepts such as IaC, by proceeding with the logic of “the beaten road is the safest” and “it is as it should be”. In my opinion, this is understandable at some point. Knowing whether team/company really needs this or any concept, planning and fully implementing it requires a separate effort. And it should not be used when it is not necessary or when it is foreseen that it may bring more harm than good. For example, for a small company operating in many different delivery scenarios, making this transformation according to its current density and employee competence may become long and difficult due to their priorities (deadlines, project loads, financial concerns, etc.).
But what if feasibility study really says you should use it..? If we have talented and curious teammates who can do this job..? In this case, thinking that “the beaten road is the safest”, “it is as it should be” or “this is not our main job, we will do it sometime” mindset will not go beyond misconceptions and sometimes compaines/teams are doing mistake because of this. Change knock the door anyway. For example, during periods such as Black Friday; testing of infrastructure, services or rebuild requirements of it.
→ “Why” should we apply it?
Actually, this question has similar answers to the previous question. But here I wanted to emphasize one thing that is fundamental among many that we can show as reasons. “Changes”…
Even if you do not make any changes, your IT infrastructure includes situations that are constantly changing and require you to monitor and manage them. “Change” doesn’t just mean an update/patch made under your control. The data written to any log file or processed, the security weakness in the OS/tool, the necessary steps to be taken in the network/cluster to improve the performance values, and accordingly, all of the work done by all teams in their own scope that will indirectly/directly affect other teams which means “change”.
Due to the changes coming from so many different channels, it can be difficult to control them, test them and rebuild your infrastructure when necessary to keep your infrastructure stable. Therefore, it would be a correct approach to use IaC in order to keep track of the changes much easier. The fact that every change you apply in this approach is small, independent and non-monolithic, makes these changes manageable. At the same time, automating this concept by supporting it with VCS(Github, Gitlab etc.) and CI/CD(Jenkins, Argo etc.) means you can get maximum efficiency from the IaC approach.
As the simplest example, you can define your variables and write codes in declarative/imperative ways on different or the same code repository depending on deployment strategy of your product. Thus, you can monitor the changes for different deployments in a controlled manner and easily create your stacks from this repository when requested.
→ What should we expect in the long/short term?
Let’s look at the benefits for us in the long term… We can say that the IaC concept has become important as we start to use cloud and automation in every field and aiming to get maximum efficiency. Although it is possible to consider these three concepts separately, considering them together in the period that we can call “Cloud Age” allows us to achieve real efficiency. We must make use of speed to improve quality and productivity… and to achieve speed, we must create quality and efficiency… When we can do this, we will have achieved speed, quality and efficiency in the long run.
Of course, doing this will not be easy in the short term. The main reasons for this can be listed as different focus points, motivation and competencies. In addition, it takes time to automate the infrastructure, adapt the existing IaC approach, and learn how to do it and best practices in the first place. But in the end, while you will gain the benefits of flexibility, efficiency, quality and speed mentioned in the other questions in the long run, you will have started the transformation of building your infrastructure with this concept in the short term. For this reason, we can say “sooner better”…
→ Where should we start? How do we proceed with a plan? What should we pay attention to?
As might be expected, to start using such a concept from scratch; it is a challenging process where many choices are made and adaptation processes are experienced. It can be difficult to see the value of the work done in a short time, to convince some people and, as a result, to focus on your goals. In such cases, motivation should come from the answers of the above questions. These answers should be the points that drive teams and companies.
So where should we start? Questions such as “Which tool should we choose”, “Let’s choose an easy-to-integrate way for our X application/infrastructure platform”, may come to mind first. But I think the first step should be emphasized that “the concept is important and should be learned, not the tools.”. Of course, different tool selections for different purposes (configuration, provisioning, CI/CD, testing etc.) should be considered with their positive/negative aspects. But if you don’t know what you’re using for which purposes, you can’t get enough of it. It may even become a burden or a bond that you cannot break after a while.
After knowing roughly where to start, it’s time to make our plan and see some core points that we need to pay attention to while doing this… Although the “plan” part varies for different cases, the “3 core practices” should be applied for the plans created from the IaC concept.
- Define everything as code
In order to make your changes applicable, fast and reliable, you should define all the infrastructure you have as code in your plan and build accordingly. Thus, you can use your code to create instances in different situations (crisis scenarios, tests, etc.). We can call this “reusability”. Also, your entire infrastructure does not become dependent on you. Other people get the same platforms as you using the same code. Thus, the result of your work will be more “consistent” and your platforms will be more stable. At the same time, you will have achieved “transparency” as your code and the changes you make can be seen by every person/team that concerned. In this way, you can get suggestions from healthier improvements and troubleshooting studies.
- Continuously test and deliver the code
Teams that truly implement the IaC concept should pay attention to the testing and delivery phase. Test and delivery pipelines, which are usually created with automation, must be run after every transaction and change in order to get the best results. After CI merges done by the different teams, appropriate tests execute in the testing phase. On the other hand, CD works so that the created code base is always production-ready and deployable. Thus, the quality and reliability of the work is built with the matter of speed.
- Build small, simple pieces
In large systems, many things are interconnected and therefore more complex than usual. The process of implementing changes is difficult and error-prone. To eliminate these risks and test each change in modular form more easily, we must code the infrastructure in small and simple pieces.
As a final word, what we are talking about here are the questions that arise roughly as a result of my own experiences and readings during the implementation of this concept on both a large and a small scale. I’m sure there are much more specific questions, different cases. I will try to experience and share them in time.
See you in the next..!
