Original Address article content
- Why DevOps
- What is DevOps
- The benefits of DevOps
- How can DevOps be implemented?
- Clarification on DevOps
- Resources
Why DevOps
There is a growing awareness that the traditional sense of development and operation of the behavior of the disconnection phenomenon, resulting in conflict and inefficiency, so DevOps came into being.
As Li Hu Thompson Lee Thompson and Andrew Cheffort Andrew Shafer said, "There is a wall of confusion between development and operations." Conflicting motivations, processes and tools have led to the existence of this "wall".
Development-centric people generally believe that change brings rewards. Companies rely on them to cope with changing needs. As a result, they are encouraged to change as much as possible, while OPS often see change as the enemy. Companies rely on them to maintain their normal business to make money. Because change can affect stability and reliability, operations business has reason to say no. We have heard the following statistics several times: 80% of all downtime incidents are due to suicidal changes.
There is a fundamental difference between how developers and operators know the world, and their roles. They all thought they were doing the right thing. Indeed, they are all right in isolation.
Worse, development teams and operations teams are often in different parts of the company's organizational structure, with different managers and competitive relationships, and even working in different locations.
Making the wall of chaos more robust also includes the dislocation between development and operations tools. Take a look at the tools that developers and system administrators use daily, and you'll find that the two are very different, developers are not interested in using OPS tools, and vice versa, and there's no significant integration between them. Even if there is some overlap on some tool types, the way you use them is completely different.
The "Wall of chaos" becomes more apparent when application changes need to be pushed from the development team to the OPS team. Some call it a "release", while others call it a "deployment" (deployment), but one thing is universally acknowledged and the problem may follow. Although it is an abstract scenario, if you have experienced this process, you will certainly feel its authenticity.
The developer "throws" a software version to the operator on the opposite side of the wall, and the latter begins to prepare for deployment. Operations personnel manually modify the deployment scripts provided by the developer or create their own scripts. They also need to modify the configuration file to accommodate a real production environment that differs greatly from the development environment. The perfect situation is that they have succeeded in repeating their previous work, and, worse, they are introducing or discovering new vulnerabilities.
The OPS then perform the deployment process that they think is correct. This deployment is actually the first to be implemented because of differences in scripts, configurations, processes, and environments between development and operations. Of course, if a problem occurs during the period, the developer will be asked to help with the troubleshooting. OPS will say there are problems with the product that the development team gives. Developers will respond by saying that the product works well in their environment, so it must be what the Ops people did wrong in the deployment process. Because of the differences in configuration, file storage location, and process, it is not easy for developers to diagnose problems.
There is no reliable way to roll the environment back to a previously known normal state. It was supposed to be smooth sailing. The deployment process eventually turned into a fire fighting operation, after repeated testing before the production environment returned to normal.
As John Alspava (John Allspaw) points out, collaboration requirements between development and operations exist before they are deployed and continue to persist for a long time after deployment. The deployment phase has clearly required a devops mindset to solve the problem, but it's not just this stage that requires devops.
What is DevOps
DevOps (a combination of English development and Operations) is a group of processes, methodologies, and systems that promote communication, collaboration, and integration between software development, technology operations, and quality Assurance (QA) departments. It comes as the software industry is increasingly aware that development and operations must work closely together to deliver software products and services on time.
Traditional software organizations set development, IT operations, and quality assurance as separate departments. How to adopt new development methodologies (such as Agile Software development) in this environment is an important issue: developing and deploying without IT support or QA in-depth, cross-departmental support in the way that you used to work, but now requires extremely close, multisectoral collaboration. DevOps, however, is not just about software deployment. It is a set of processes and methodologies for communication and collaboration issues between these departments.
Businesses that require frequent deliveries may need to have a general understanding of DevOps. Flickr has developed its own DEVOPS capabilities to support the business unit's "deploy 10 of times a day"-the deployment cycle is bound to be short if an organization is to produce multiple-user, multi-functional applications. This capability is also known as continuous deployment, and is often linked to lean entrepreneurship methods. Since 2009, relevant working groups, professional organizations and blogs have sprung up rapidly.
The introduction of DevOps has far-reaching implications for product delivery, testing, functional development and maintenance, including the once rare but now commonplace, "hot fixes". In organizations lacking DEVOPS capabilities, there is an information "gap" between development and operations-for example, when operators demand better reliability and security, and developers want infrastructure to respond faster, and business users need to deliver more features to end users faster. This information gap is the most frequently problematic place.
The following factors may prompt an organization to introduce DEVOPS:
- Use agile or other software development processes and methodologies
- Business leaders demand faster product delivery rates
- Virtualization and cloud infrastructure (possibly from internal or external suppliers) are becoming increasingly common
- The popularization of data Center automation technology and configuration management tools
- One view is that the current dominant "traditional" American style of management ("Sloane Model vs Toyota Model") [16] leads to "chimney-type Automation", which creates a gap between development and operations and therefore requires DEVOPS capabilities to overcome the problems that arise.
DevOps is often described as "a more collaborative and efficient relationship between the development team and the operations team." As a result of improved teamwork, the efficiency of the entire organization is thus improved, and the risk of a production environment with frequent changes can be reduced.
The benefits of DevOps
DevOps is a very powerful concept, because it resonates on many different levels.
From the point of view of the development or ops front-line people, DevOps frees them from a multitude of annoyances. It's not a magical panacea, but if you can make DevOps work, you'll save a lot of time and not hurt your morale. It is obvious that we should be more efficient, more agile and less frustrated when we put our energies into putting DevOps into reality. Some people may argue that DevOps is a distant goal, but that is not to say that we should not try to achieve it.
For businesses, DevOps directly contributes to two powerful strategic enterprise qualities, "business agility" and "it convergence." They may not be something the IT people worry about, but they should get the attention of the managers who have the financial power.
A simple definition of it convergence is that "a state that an enterprise aspires to achieve is an efficient use of information technology to achieve corporate goals-often to improve corporate performance or market competitiveness." ”
DevOps helps achieve it convergence by aligning development and operational responsibilities and processes from a common enterprise goal perspective. Development and operations personnel need to understand that they are only part of a unified business process. DevOps ideas ensure that individual decision-making and behavior should strive to support and improve this unified business process, no matter which organization you come from.
A simple definition of business agility is "the ability of an organization to quickly adapt to market and environmental changes in an efficient and economical manner." ”
Of course, for developers, "agile" has a special meaning, but the goal is very similar. The agile development approach is designed to keep software development in sync with the goals of the customer/company, which can produce high-quality software despite changing requirements. For most organizations, the iterative project management approach to Scrum is synonymous with agility.
Business agility promises close interaction and quick feedback between corporate equity groups making decisions and developers responding to them. Look at the products of a well-functioning agile development community and you will see a steady and continuous improvement consistent with your business needs.
However, when you review the entire development-operations cycle from an enterprise perspective, the relative benefits of agile methods are often blurred. The wall of chaos leads to the division of the application life cycle. Development and operations are carried out at different rhythms, respectively. In fact, the long-term gap between product deployments makes the agile work of a group A waterfall life cycle that it has been trying to avoid. When there is a wall of chaos, no matter how agile the development community is, it is extremely difficult to change the slow and sluggish nature of the business.
DEVOPS enables the benefits of agile development to be reflected at the institutional level. DevOps can do this by taking into account the fast, responsive but stable business operations that enable them to stay in sync with the innovation of the development process.
If you want to build a DEVOPS project within your organization, be sure to keep in mind "it Convergence" and "business agility."
How can DevOps be implemented?
As with most emerging topics, it is much easier to find common features of problems than to find a solution.
To implement a devops-related solution, there are three areas to focus on:
1. Evaluation and encouragement of cultural change
Changing culture and motivating systems is never easy. However, if you do not change your corporate culture, it will be very difficult to deliver on your devops commitments. When examining the dominant culture of an enterprise, you need to pay close attention to how to evaluate and Judge business performance. The content of the evaluation will affect and stimulate the behavior of the occurrence. All parties in the development-operations lifecycle need to understand that they are only part of the larger enterprise process. Individual and team success is evaluated throughout the development-operations lifecycle. For many organizations, this is a shift, no longer isolated for performance evaluation, and each team is no longer based on its own team to evaluate and judge performance.
2, unified standardization of the process
This is an important theme of DevOps, and the entire development-operations lifecycle must be seen as an end-to-end process. Different stages of a process can take different approaches, as long as these processes can be grouped together to create a unified process. Similar to the question of evaluation and motivation, there may be slightly different requirements for each organization when implementing this unified process.
3. Unified Tools
This is the area where most devops discussions have been focused. This is not surprising, because when a technologist is thinking about solving a problem, the first response is to jump directly to the tool discussion. If you focus on the tools community such as puppet, Chef, or controltier, you may already be aware of the great concern about building bridges between development and operations tools. "Infrastructure as Code", "Model driven automation" and "continuous deployment (continuous deployment)" Infrastructure is a concept that can be categorized into devops.
With regard to what types of tools are needed to turn DevOps into reality, Jack Sorofman (Jake Sorofman) suggests the following:
One version control software Library
It ensures that all system products are well defined throughout the release lifecycle and can be shared consistently while keeping up-to-date information. The development and QA organization can obtain the same platform version from which the production organization deploys the same version that has been validated by the QA agency.
Deep Model System
Its version system clearly describes all of the components, policies, and dependencies associated with the software system, making it simple to replicate a system or introduce changes without conflict.
Automation of human tasks
Reduce manual interference during dependency discovery, System construction, configuration, updates, and rollback. Automated operations become a command and control foundation for high-speed, conflict-free, and large-scale system management.
There are many different tools in the life cycle from development to operations. Tool selection and execution decisions need to be determined based on their impact on the end-to-end life cycle.
Clarification on DevOps
Some system administrators are now trying to change their job title to "DevOps". However, DevOps should not be a single location or title. Turning DevOps into a new job title or specific role is a very dangerous thing to do. For example, this causes the following error endpoint: Are you a DBA? Or is it a security expert? So don't worry about DevOps, because that's the problem with the DevOps team.
Imagine that you would not say "I need to recruit an agile" or "I need to recruit a scrum" or "I need to recruit an ITIL" and just say that you need to recruit developers, project managers, testers, or system administrators who understand these concepts or methods. DevOps is the same thing.
There are many terms that have the same philosophy as DevOps, such as agile Operations, agile Infrastructure (Infrastructure), and Dev2ops. There are a lot of people who don't mention "DevOps", but they follow a similar philosophy.
Resources
- Wiki DevOps
- Devopsbookmarks
Why and what is DevOps