Author: Xu Lei
The original address of the article: https://smartide.cn/zh/blog/2022-1010-iac/
As a basic practice of modern software engineering, Infrastructure as Code (IaC) is the underlying logic behind cloud native, containers, microservices and DevOps. It should be said that all of the above technologies or practices are a collection of one or more methods based on infrastructure as code. Infrastructure as code is not a specific technology, but a way of solving problems. This article will help you understand why DevOps systems that do not use IaC are rogue from three aspects: the meaning, principles and implementation methods of infrastructure as code.
What is IC
The goal of infrastructure as code is to solve an ancient problem : how to complete the software delivery process safely, stably, quickly and efficiently. Note that the delivery here does not only refer to deploying deployable software to the final operating environment, but a broader concept of delivery, that is, transforming the software from an invisible and intangible idea or creativity into one that users can A system to operate and use. This process involves the entire process of capturing, designing, planning, developing, testing, deploying, and releasing software ideas. It also includes the iteration of collecting user feedback and starting the above process after the software is released. This iteration will be repeated throughout the entire life cycle of the software until the software is no longer used and reaches its end of life.
This continuous iterative process in the software life cycle constitutes the concept of the DevOps feedback loop . The left and right ends of this feedback loop are Dev and Ops, and code and infrastructure are the most important artifacts of Dev and Ops. , Dev maintains the code, and Ops maintains the infrastructure. Traditionally, there is a clear distinction between code and infrastructure. Generally speaking: code refers specifically to application code, while infrastructure refers to all "basic" components except the application (or below).
Before the emergence of cloud computing technology, hardware was generally considered to be unchangeable once created. Just like if you bought a computer and wanted to replace the CPU, internals, disks, and network cards, you had to repurchase the corresponding components and reinstall them. Assemble. Cloud computing decouples computing resources (computers) into three resource types that can be combined at will: computing, storage, and network , allowing users to combine them as needed. Its underlying implementation mechanism is to turn hardware into software . For example, object storage technology and software-defined networking (SDN) are the basic technologies of cloud computing. The result of hardware being software-based is that we can change the ability of the hardware through configuration. This is actually the most basic meaning of infrastructure as code.
But for users, they don’t actually care what hardware or cloud the software they use runs on. For example: for users' social needs, WeChat is the infrastructure for social needs; for users who need to write documents, WORD is his infrastructure. Compared with hardware, this is actually another extreme meaning of infrastructure, that is: any support capability that supports users to complete a certain operation can become the infrastructure for this type of user operation.
In this extreme sense, any layer in the above environment stack may become the infrastructure above. In order to provide the upper layer with self-service capabilities similar to cloud computing, configurability needs to be provided. In order to meet this need for configurability, infrastructure-as-code implementations such as containerization technology, Kubernetes, Terraform, and Azure Resource Manager have emerged in the IT industry. In fact, these technologies all solve one problem, which is the configurability of the system.
IaC implementation principles
There are many ways to achieve configurability. The traditional operation and maintenance method is actually very simple, which is to automate the configuration process through scripts, automating the originally cumbersome configuration process.
Although the automated script method can solve the configurability problem to a certain extent, when the frequency of system changes reaches a certain level, the workload of maintaining the automated script will offset the efficiency improvement brought by the automated script . At this time, the operation and maintenance Teams may find that manual processing is even more efficient than writing and maintaining automated scripts. Therefore, in today's context of increasingly faster software iterations, automated scripts are gradually unable to meet the team's needs to respond to the rapidly changing market. We need a way to maintain the environment that allows the team to easily adapt to rapid changes. Infrastructure as Code (IaC) was born in this context. In fact, it is not accurate to say that IaC was born. IaC is actually the result of continuous improvement by engineers after encountering problems.
When the way of maintaining automated scripts cannot adapt to the rapidly changing market needs, how to decouple the development and operation and maintenance teams becomes the core of solving this problem. In the working model on the left side of the figure above, the core of the problem is the "request-response" working model between the development and operation and maintenance teams. This working model makes the development and operation and maintenance teams dependent on each other and unable to independently follow their own Rhythm work. In order to solve this problem, IaC borrows the layering principle in large-scale software architecture design to turn those capabilities that need to be shared into common components, and share these components between development and operation and maintenance, so that the two parties that are originally interdependent can A team becomes dependent on another third-party component. As shown below:
In order to be able to work together with third-party components, the IaC approach needs to follow several key principles
-
Declarative: In order to make all orchestration capabilities independent of development and operation and maintenance teams, no team should keep the specific operations of the capabilities within its own team. Declarative configuration can ensure this, because in the configuration As long as the statement has no specific logic, it means that both parties of the original dependency must contribute public capabilities, otherwise C in the above figure will not take effect.
-
Idempotence: Furthermore, declarative configuration must be able to ensure the results of environment orchestration at any time, which also means that the operations on the environment in general component C must be able to be executed in any state and obtain a consistent final result. In other words, no matter whether the target environment is in the initial state, intermediate state, final state or error state, when the declarative configuration is loaded, it will become the desired state (Desired State) we need.
How to implement IaC
In essence, IaC is a way of doing things. As long as the methods and tools for implementing IaC follow the above principles, they can help teams implement this method. In the actual work process, we need some basic conditions to achieve IaC:
cultural support
Implementing IaC will change the working model and collaboration methods of teams (especially development and operation and maintenance teams), and the work boundaries and responsibilities of both parties will change. In the traditional model, development and operation and maintenance teams collaborate through processes. When both parties need the cooperation of the other party, they initiate a process (issue a request), wait for the other party to complete the operation as required (give a response), and then continue the process until the goal is achieved. IaC requires both parties to collaborate through shared capabilities. Both parties need to continuously discover problems that prevent the other party from working independently during the collaboration, and jointly contribute the ability to solve these problems to another component shared by both parties (usually a tool). In daily work, They no longer rely on processes to drive each other, but use this shared component (tool) to complete the work. The working model of IaC requires both teams to accept an uncertainty way of thinking, and when problems arise, they must jointly solve problems instead of defining and assigning responsibilities. If the culture in the team does not allow the existence of this uncertain way of thinking, IaC will not be implemented.
Sharing tools
Teams with the above cultural support need to jointly build a tool that is recognized by both parties and encapsulate all the environment orchestration capabilities that both parties need into this tool. The core goals of this tool are twofold:
Uncoupling: Let both parties no longer rely on each other in daily work, and can use it freely according to their own rhythm and work mode. At the same time, it ensures that the standards, rules and strategies that both parties care about can be implemented normally and can be monitored.
Customizable and evolvable: The purpose of this tool is to adapt to changing market needs. A static tool cannot do this. Only tools that are highly customizable and scalable can do this. Ability. Therefore, it is crucial to control the functional granularity in the process of designing and implementing this tool. If all functions are designed according to daily business processes without considering versatility, the end result will be that any change in workflow will cause the tool to changes, such tools will lose their existence value as general components.
IaC is everywhere
In fact, cloud native, microservices, containerization and DevOps are all practicing IaC at different levels. Cloud native emphasizes using the basic characteristics of the cloud to empower teams. In fact, it uses the underlying technology of cloud computing to provide teams with the basic conditions for implementing IaC. Microservices use componentized thinking to allow multiple teams to work independently without being affected by other teams, thereby maximizing team work efficiency. Containers are based on cloud computing technology and provide IaC capabilities for the operating system and its upper environment stack. Major container tools including Docker and Kubernetes are designed based on declarative configuration and idempotence principles.
What is DevOps here? DevOps is the synthesis of all the above concepts, methods and practices. In fact, the scope of DevOps is broader than this. You should be able to see from the picture at the beginning that in terms of breadth, the infinite loop formed around Dev and Ops actually covers all aspects of the software delivery process. In terms of depth, DevOps can cover cultural concepts and management methods. , business innovation, agile and lean, project management, team management, technical management and all levels of tool implementation. As a result, more and more people are putting more and more content under the DevOps hat, and many extended concepts such as AIOps, GitOps, TestOps, DevSecOps, BizDevOps, etc. have emerged.
In fact, we don’t have to worry about the concept itself, because DevOps, which comes from the spontaneous summary of the community, does not have a centralized intellectual property owner, and no one can give it a clear interpretation. This in itself is actually a good thing, because just like the above analysis and explanation of IaC, the existence of DevOps also helps us continue to improve. If it itself becomes a static method set or toolkit, how can it adapt to the current continuous What about the changing business environment and market needs? From this perspective, all the so-called certifications, systems and programs that hope to standardize DevOps are actually misleading.
In the process of introducing container technology, microservices, cloud native and DevOps, many companies are still continuing the original department structure and workflow, and trying to integrate these new technologies and methods into existing processes instead of exploring new technologies. New possibilities with new methods. I have encountered too many similar organizations in the past ten years of helping companies implement DevOps. The most obvious symptom is that you will find that the departments that promote the implementation of DevOps are constantly defining responsibilities and shifting the blame. They must be rogue with DevOps. The IaC working ideas I described above have never been important to these people. They don't care about root cause analysis and improvement measures after the problem occurs. On the contrary, if the results of the root cause analysis put the blame on themselves, then they would rather not analyze; if The result of the improvement measures is that you need to contribute part of your functions, which is even more impossible. The final result is that "shared tool" with various patches, hard-coded processes and technical debt buried in it. It is conceivable how such a tool can carry uncertainty and how it can help other departments improve efficiency, let alone for The organization improves its overall effectiveness. By the way, this tool that buries a lot of time bombs is the "integrated R&D platform/DevOps platform" that you are passionate about.