And again about DevOps
I often hear questions about what DevOps is. What makes it different from the usual roles in IT. Maybe this is just a fashionable term, a whistle in the form of a fashionable profession.
What is DevOps? This is the speed. This is interdisciplinary. This is a synergy. This is a new IT elite.
Traditional development methods are a set of processes stretched over time, where the roles are clearly distributed. Analytics, project plans, evaluation criteria. As a rule, the team is also distributed by roles, there are analysts, developers, testers, and admins who are involved in infrastructure maintenance. It worked for some time in the industry, I mean industrial development. With the growth of projects, with the transition from monolithic applications to the system of microservices, with the increase and accumulation of products, there are questions that require a completely different approach, if they can be solved in the old paradigm.
First, the problem, which takes a year and a half to solve, can change incredibly, or even disappear, and cease to be relevant. Secondly, the complexity of the systems has increased so much that the old approaches simply do not work. Third, the quantitative increase in infrastructure projects, industrial automation, scaling does not fit into the old framework.
')
DevOps - reduces production, i.e. development and operational management together, through automation, in order to meet the challenges of new business requirements as quickly as possible.
What is the development for many developers. This is a kind of team, formed into an independent unit, which works according to the established rules, and eventually creates a certain product - an application or service. After that, the product passes the testing phase, and then rolls out at the disposal of the team, who support it and bring it to the end customer or the masses.
And then there are problems. Isolating commands leads to the fact that an application or service that works in the development environment may have and usually has problems in the live-environment. Error detection and correction, in such a situation, require knowledge of the working environment with which isolated commands are not familiar. This leads to frustration, frustration and accumulation of problems. Both technical and business side suffers.
I will not describe here the principles of DevOps, about which many have heard. It is automation, virtualization, integration, and communication. But this is not only a set of techniques, it is not infrastructure projects enveloping the system, it is not only a paradigm. This is primarily a philosophy.
Imagine a system of more than 200 services that are combined in a high-speed dynamic environment that serves thousands of requests per second, where each action is displayed as a chain of asynchronous requests. A system where reliability and speed come first. Where caching systems are widely used, with their problems, where servers are united into clusters, and where asynchrony is at the forefront. And there are several copies of such systems. I'm talking about environments. As a rule, there are 4-5, DEV, TEST, UAT, DEMO, PROD. As in the system of such order to adjust the processes of application deployment, the development cycles of various teams should be synchronized with each other. How to manage this all, and how to solve problems arising in the course of work? Finding bugs, fixing and deploying fixes on all environments becomes complex and costly.
With the use of Test-Driven-Development, Continuous Integration and Delivery, control and monitoring systems, Agile approach can bring the speed of releases to unimaginable orders. For example, Google has more than 2 billion builds per week. True, they count for instance, multiply by the number of servers in clusters, and these guys can scale very well, but nevertheless, 2 billion a week! Other Internet giants have equally amazing numbers. Roughly speaking, DevOps is the answer to the challenges facing companies such as Facebook, Yahoo, Yammer, Amazon, Google, VMware and many others.
The continuous flow of release, version control, the process of deploying and launching the system is not just automated, but in every company of this kind, infrastructure projects arise to reduce risks and increase the speed of development and deployment. For example, one of the projects that our company is developing is an automatic application assessment system. After the developers contribute code to the version control system, a rating system is launched, as far as the application meets the criteria, from the presence of monitoring and control systems to stability in stressful situations and the absence of memory leaks, and other operational problems. An application that does not score enough points or has dropped critical marks is not allowed until deployment, which is also automated. As the application progresses from environment to production, the number of evaluations increases. This is not the same as the unit and integration tests that each application also has, it is a more global assessment, taking into account the requirements of both IT and business.
But DevOps, this is not a set of techniques, as I noted above. This is a philosophy. Part of the work is to convey a vision to the development teams in order to break the isolation and expand their capabilities. This is the process of spreading knowledge. Programmers are involved in the process of supporting and deploying the created systems, in studying the interaction of various services, in the process of generating ideas, to facilitate and simplify work. This is not always successful, and it is often difficult to go beyond the paradigm in which you are used to working. This is a great responsibility. At the same time it is rewarded. A lot of ideas that eventually led to successful infrastructure projects, it was expressed from the development side. Programmers are lazy, and this is a huge motivator that needs to be sent in the right direction.
Communication. With all the hack and banality of the word, there is nothing better that could increase the added value of the product leaving the divisions. Communication between commands, merging development and support. It is DevOps. Many successful companies have not a vertical, but a horizontal hierarchy. Open offices, lack of offices, and the work of management at all levels, together with subordinates. Such seemingly small things are surprisingly effective.
A successful DevOps engineer is a generalist with a deep knowledge of individual moments. A fragile mixture that ultimately adds to the value of the business by being adequately applied to the needs of the company. DevOps is knowledge, tools, experience and discipline.
In my work, half the time I develop. These are mostly infrastructure projects as part of Continuous Integration and Delivery. The other half is troubleshooting and this is the most interesting part. Our department is Special Forces, which solves key problems, deals with performance-engineering, analyzes the performance of development teams and shares knowledge about how and what can be improved.
We have a crazy pace, bugs and problems are not standing in line, and everything is aimed at improving quality. Today I can solve problems with an increase in the number of threads in the application, and find that they do not close when garbage collection. I am refining the code, and spend the chain of environments. Yesterday I could have run into a load-balancer HAProxy configuration problem in the authentication system. Tomorrow I will face timeouts when calling each other's services because of garbage collection and I will solve it. Every day, the experience and volume of knowledge in the widest field is increasing, and no role in IT provides such. This is similar to the work of a detective or a diagnostician. The average between Sherlock Holmes and Dr. House. Symptoms are not like causes. Analysis of logs, building chains of queries, multi-threaded environment, all this is something that does not occur in the work of the developer. And this way is an alternative to what stands at the “end of the career” of a programmer. Go through the business line in the project managers, or on the technical side in the architects. This is a different way. And DevOps is in a sense Zen IT. Lifting patterns of thinking, going beyond, deep understanding and ease of movement.
Welcome to DevOps.
What is DevOps? This is the speed. This is interdisciplinary. This is a synergy. This is a new IT elite.
Traditional development methods are a set of processes stretched over time, where the roles are clearly distributed. Analytics, project plans, evaluation criteria. As a rule, the team is also distributed by roles, there are analysts, developers, testers, and admins who are involved in infrastructure maintenance. It worked for some time in the industry, I mean industrial development. With the growth of projects, with the transition from monolithic applications to the system of microservices, with the increase and accumulation of products, there are questions that require a completely different approach, if they can be solved in the old paradigm.
First, the problem, which takes a year and a half to solve, can change incredibly, or even disappear, and cease to be relevant. Secondly, the complexity of the systems has increased so much that the old approaches simply do not work. Third, the quantitative increase in infrastructure projects, industrial automation, scaling does not fit into the old framework.
')
DevOps - reduces production, i.e. development and operational management together, through automation, in order to meet the challenges of new business requirements as quickly as possible.
What is the development for many developers. This is a kind of team, formed into an independent unit, which works according to the established rules, and eventually creates a certain product - an application or service. After that, the product passes the testing phase, and then rolls out at the disposal of the team, who support it and bring it to the end customer or the masses.
And then there are problems. Isolating commands leads to the fact that an application or service that works in the development environment may have and usually has problems in the live-environment. Error detection and correction, in such a situation, require knowledge of the working environment with which isolated commands are not familiar. This leads to frustration, frustration and accumulation of problems. Both technical and business side suffers.
I will not describe here the principles of DevOps, about which many have heard. It is automation, virtualization, integration, and communication. But this is not only a set of techniques, it is not infrastructure projects enveloping the system, it is not only a paradigm. This is primarily a philosophy.
Imagine a system of more than 200 services that are combined in a high-speed dynamic environment that serves thousands of requests per second, where each action is displayed as a chain of asynchronous requests. A system where reliability and speed come first. Where caching systems are widely used, with their problems, where servers are united into clusters, and where asynchrony is at the forefront. And there are several copies of such systems. I'm talking about environments. As a rule, there are 4-5, DEV, TEST, UAT, DEMO, PROD. As in the system of such order to adjust the processes of application deployment, the development cycles of various teams should be synchronized with each other. How to manage this all, and how to solve problems arising in the course of work? Finding bugs, fixing and deploying fixes on all environments becomes complex and costly.
With the use of Test-Driven-Development, Continuous Integration and Delivery, control and monitoring systems, Agile approach can bring the speed of releases to unimaginable orders. For example, Google has more than 2 billion builds per week. True, they count for instance, multiply by the number of servers in clusters, and these guys can scale very well, but nevertheless, 2 billion a week! Other Internet giants have equally amazing numbers. Roughly speaking, DevOps is the answer to the challenges facing companies such as Facebook, Yahoo, Yammer, Amazon, Google, VMware and many others.
The continuous flow of release, version control, the process of deploying and launching the system is not just automated, but in every company of this kind, infrastructure projects arise to reduce risks and increase the speed of development and deployment. For example, one of the projects that our company is developing is an automatic application assessment system. After the developers contribute code to the version control system, a rating system is launched, as far as the application meets the criteria, from the presence of monitoring and control systems to stability in stressful situations and the absence of memory leaks, and other operational problems. An application that does not score enough points or has dropped critical marks is not allowed until deployment, which is also automated. As the application progresses from environment to production, the number of evaluations increases. This is not the same as the unit and integration tests that each application also has, it is a more global assessment, taking into account the requirements of both IT and business.
But DevOps, this is not a set of techniques, as I noted above. This is a philosophy. Part of the work is to convey a vision to the development teams in order to break the isolation and expand their capabilities. This is the process of spreading knowledge. Programmers are involved in the process of supporting and deploying the created systems, in studying the interaction of various services, in the process of generating ideas, to facilitate and simplify work. This is not always successful, and it is often difficult to go beyond the paradigm in which you are used to working. This is a great responsibility. At the same time it is rewarded. A lot of ideas that eventually led to successful infrastructure projects, it was expressed from the development side. Programmers are lazy, and this is a huge motivator that needs to be sent in the right direction.
Communication. With all the hack and banality of the word, there is nothing better that could increase the added value of the product leaving the divisions. Communication between commands, merging development and support. It is DevOps. Many successful companies have not a vertical, but a horizontal hierarchy. Open offices, lack of offices, and the work of management at all levels, together with subordinates. Such seemingly small things are surprisingly effective.
A successful DevOps engineer is a generalist with a deep knowledge of individual moments. A fragile mixture that ultimately adds to the value of the business by being adequately applied to the needs of the company. DevOps is knowledge, tools, experience and discipline.
In my work, half the time I develop. These are mostly infrastructure projects as part of Continuous Integration and Delivery. The other half is troubleshooting and this is the most interesting part. Our department is Special Forces, which solves key problems, deals with performance-engineering, analyzes the performance of development teams and shares knowledge about how and what can be improved.
We have a crazy pace, bugs and problems are not standing in line, and everything is aimed at improving quality. Today I can solve problems with an increase in the number of threads in the application, and find that they do not close when garbage collection. I am refining the code, and spend the chain of environments. Yesterday I could have run into a load-balancer HAProxy configuration problem in the authentication system. Tomorrow I will face timeouts when calling each other's services because of garbage collection and I will solve it. Every day, the experience and volume of knowledge in the widest field is increasing, and no role in IT provides such. This is similar to the work of a detective or a diagnostician. The average between Sherlock Holmes and Dr. House. Symptoms are not like causes. Analysis of logs, building chains of queries, multi-threaded environment, all this is something that does not occur in the work of the developer. And this way is an alternative to what stands at the “end of the career” of a programmer. Go through the business line in the project managers, or on the technical side in the architects. This is a different way. And DevOps is in a sense Zen IT. Lifting patterns of thinking, going beyond, deep understanding and ease of movement.
Welcome to DevOps.
Source: https://habr.com/ru/post/260659/
All Articles