Geekly Articles each Day
📜 ⬆️ ⬇️

DevOps Evolution

This article is devoted to the evolution of development and administration, and the definition of its own position in the overall picture of everything. The article is inspired by Marc Hornbeek 's slides , but is indirectly related to them. For a wide range of fermers (ops, devs and devops).


First, a small background to meet. I know that prehistories are usually very boring, on the other hand - how would you otherwise believe that the author in general has the right to speak on this topic?


That year in 2003, I first got a job as an admin. For a while, questions such as manual patching and bulkheads for VPNs and night vigils behind the postfix-dovecot-spamassassin-etc installation have been overwhelmed. Somewhere in 2011, I looked up from the next-sized bash script that was about the size of a commentary under the post of Alizar, looked around, and was surprised to see that everything was working for everyone. Without these titanic efforts. “Once and in production” comes to us, and how can you earn money now ?


Now, in the case of a similar problem, I would just go to a conference like DevOops , and instantly figure out: what is now in the trend, and how to pull out my team. Now there are connections, and Facebook with five thousand IT friends. Then there was nothing of this: I had to leave my current job (in order not to become, after all, a solitaire maker), start desperately to learn Java, and eventually become a complete javist .


What is it for? I would like to clearly show that our dependence on a specific administrative culture, a culture of programming and development in general, a toolbox is not a joke. This is a matter of survival.


All familiar dudes who did not have time to adapt - now either have become cool professionals in narrow areas of administration, or nothing is known about them at all. Maybe they are not alive already.


As astrophysicist Carl Sagan once said,


Extinction is the rule, and survival is the exception.



In our quite civilized world, there are special jungles of administration and development, with its own evolution.


As we remember from school, natural evolution moves along adaptation processes (natural selection), plus there are some additional reasons: gene drift, gene flow, mutations.


Our admin evolution is moving along quite specific business interests. When you cannot adapt to a very specific set of changes, your boss eats you up.


This is what you need to adapt immediately:



(This is only the beginning of a long list. To begin with, that's enough).


Beat, run, stand still


For each of these parameters, you can make some very specific process (within the company), or at least - career changes.


Now we will play in a kind of bullshit bingo , trying to describe with human words what the chef wants from us before eating.


We will beat and freeze, but the runaway option (for the last paycheck, buy a box from the refrigerator and live at the heating main) is not considered.



Flexibility


What is flexibility is hard to say, but its absence is obvious. This is when innovations disappear in a company, people start to rot on the spot (gradually turning from admins into solitaire game experts), and the company's products are released well if once every three months.


What does the boss want to see from us? For example, that the products began to roll out every day at exactly 15.00. Or that customers began to use the service more often (because it is stupid to quickly install, configure and deploy).


Stand still : By the way, do you understand what it means to roll out a product? You need to run 100,500 commands in the console, read a ton of updated documentation, and so on. We can just work more. Very much more! The admin always has some piece of personal resources that is still left for a rainy day (if there is no such thing, this is a bad admin), and this piece will go to the firebox of the revolution.


Bey : there are very specific ways and tools that help lay out new builds faster. The simplest and most logical is fully reproducible builds, which have already been run in many times by the developers themselves, and therefore, to release a new version, it is enough to repeat the same thing. And since it is “all the same”, it can be automated. Scripts and dockers in hand - and went :-)


Adaptation on the “hit” strategy is the study, use and participation in the development of modern CI / CD systems and other devops tools.


Efficiency


When you rolled out the product, and it immediately collapsed (perhaps without even starting), and you have to repair it and stitch it over and over again, this is extremely low efficiency.


The chef would like to see what was done once - no need to redo every time. That writing a particular action takes intuitive terms, for example, a startup script is written in 5 minutes, and not in 5 hours.


Stand still: we have standard Bash-type tools that have been proven over the years, the knowledge of which can be polished to a mirror finish. For any standard task there is a snippet or instruction on Confluence. It is necessary to continue to do the same thing as before - to improve their skills in these tools.


Bey : on the contrary, you can take the tools in which all these problems are solved. For example, you can use Systemd to run it, and all of your noodles on a 20-page bash can suddenly curl up to a few lines. And yes, throw out already RHEL6. If you need a script, you can write it in Python, since the availability of Dive into Python, PyCharm and Ansible makes managing Python clusters accessible even to schoolchildren. However, Bash is still needed, but in a different way.


Adaptation according to the “hit” strategy is the study of programming and maximum automation of everyday work. Things that you can not program - it is better not to program and take ready-made solutions, provided that the implementation of this solution is almost free (as is the case with Systemd).


Stability


In our country, stability is appreciated, if you understand what I mean :-) For us, both the stability of the admin and the service he serves are important.


For example, we work in freelancing. The chief wants us to take the task every time, and every time we fulfill it. That is, you cannot set up a super-important server today and get a bonus, but tomorrow you can’t do anything and go to the horizon. Only programmers can afford this :-)


I specifically interviewed managers, and most of them consider stability as the top priority: it’s better to have consistently poor results than to get miracles from time to time, and sometimes nothing.


The same applies to automated services that we serve. The service should fall with approximately understandable frequency for understandable problems. For example, if Java has devoured all the RAM, and regularly does it once a day at 00:00 - this is OK, this is Java, everyone is used to it. But if an unsolvable problem happens in a perfectly running service once a month, it is a disaster.


Stand still : we can hope for the long life of our instruments. It is unlikely that something will happen to BIND9 that has already happened. Everything has already been invented, everything is already somewhere on the Internet, or the closest acquaintance understands this. Well, in the end, over the years we have had enough time to read and understand the source code of BIND.


Bey : modern IT constantly comes up with something new. For example, microservices. Microservices as data sources in complex topologies. Non-relational databases with tricky architectures. How are we going to resolve this, how are we going to debug it? Where to get ready-made technology? All this is completely unclear. Instead, you can rush and start creating technologies yourself! For example, for service discovery in microservices, you can take a stack of Netflix Open Source. Not enough features Netflix Eureka? Found bugs? Yes it does not matter. All this is written in Java with modern spring, you can always take the source code of Eureka and download it exactly the way your company needs it for a specific situation. (Yes, you need to know Java sufficiently for this, but this is a completely different story - the story of how an admin can learn to program).


Adaptation according to the “hit” strategy is the study of means of automated and semi-automatic response, as well as means of automatic diagnostics and monitoring. It is stable not only that it does not break at all, but that it constantly breaks down and is repaired at a known speed.


Security


Everything is clear here, given that usually we are the people who either help the security guards, or they are generally. People just want security.



Stand by : use existing solutions proven over the years. The entire process of delivery of the product is checked by hand and eyes. During the delivery process, use as much privacy and security through obscurity as possible so that it is incredibly difficult for an attacker to understand even the attack vectors.


Bey : As for the low level, unfortunately, here it is with the new technologies that everything is very sad. You can not take and write a good cryptography on the knee. Perhaps commentators will tell you what modern security technologies need to be used now.


As for the high level, it is useful to use full automation and transparency of all processes. Administrators should only intervene in the automatic delivery process in the most critical situations. Normally, the delivery should be fully controlled by Python code, Ansible, and the like. Administrators must write code, or adjust the parameters of the existing code. Note that even the little things like entering passwords need to be reduced or removed altogether.


“Beat” strategy adaptation is the implementation of a fully automatic CI / CD, including the seamless implementation of security updates.


The quality of life


You can talk for a long time on the topic that new technologies are good, simply because they are new. Personally, I’m wondering how to make more money out of it and not let yourself be eaten.


From this, the main evolutionary question: what strategy to choose, stand still or beat?


Imagine a person who always chooses old stable solutions. Most likely, this is some kind of person with an unimaginable experience and experience, endowed with so much intelligence that he allows him to wriggle out of a new ready-made set of tools from any new situation. It must be some kind of godlike creature like Richard Stallman, who with the help of Emax controls the movement of the stars.



But the thing is, not everyone can become a Stallman.


Have you seen many such people? Do you really want to spend all your free time at work, studying network technologies from the very beginning of the centuries?


Well, the main question of all time. Money. Money pays for what is now in trend. If you look at the report of comrades from Puppet , it turns out that the trend is now ...



Suddenly, in a trend now DevOps. Good news, we do not have to live in a box near the heating main. 10% growth in three years is very cool.


Simply put. A simple study of Python already gives a non-figure bonus to your paycheck. If you have the strength to tear off your ass and get involved in building a full-fledged devops process in your company, you can start smearing buter caviar. This is business!


Development model


In order to more clearly observe how boaters are moving towards you, you need to have some kind of clearer model than just learning the words from a bullshit bingo. Without a model, you can not live, eat, sir.


As a framework, you can take the Capability Maturity Model (CMM), and slightly adapt to our realities. The model assumes several levels of development, according to which the project turns from a monkey into a human.


In the original, it looks like this (the descriptions are taken from Wikipedia , the Russian translations of the names of the stages I also do not really like):



Let's perekolbasim this list under our realities.


1. Entry Level, Chaos and Overcoming


It all starts with some cool startup.
In our case, the startup was the creation of computers.


Portable German Enigma encryption machine



1939 - Alan Turing blasts into the thread with the hacking of the Enigma codes, "Bombe"



Another German encryption machine - Lorenz



1943 - in just 9 months, Tommy Flowers and his comrades do Colossus to work with Lorentz codes.



1946 - ballistic tables and "ENIAC" - one of the first general-purpose calculators



1954 - finally, the first computer, which went into mass production, IBM 650



Magnificent years filled with great discoveries and outstanding hackers like Alan Turing.


On the other hand, from the point of view of modern devops, this stage is a great example of how not to do.



2. Mechanization



In the picture - Margaret Hamilton, lead developer of the Apollo Project. It stands next to the source code of the programs that were written by hand. As a result, people visited the moon.


Starting from the 60s, manual work automation processes come into play, starting with attempts to formally record and explain secret ad-hoc knowledge to a wide mass. Formalized knowledge is transformed into standards, the development of standards allows you to create projects with millions of lines of code.
Much attention is paid not just to standardization but to testing for these standards (if possible, automatic).



3. Variation of tools and cultures


Skipping the nineties with their vigorous experiments, we immediately jump almost to modernity - and we see the top of the engineering thought of this time, flexible methodologies.



In the course of rapid development, it became absolutely clear that simply introducing new software is not enough, you need to upgrade also the production process.


As for the tools, then we had a certain broth from a huge number of tools. The surest way to move off the roof is to try to study and apply all these tools.


To reduce the complexity of the task, the tools can be divided into groups:



Often, the introduction of “devops” during this period was to collect as many new development methodologies, popular utilities as possible, run inside one project, thoroughly coat smoothies, and somehow try to live with it. Such an approach could lead to chaos in any other production, but we were lucky - all the tools used are designed to increase order and work with minimal human effort, so if you have direct hands, all this can be kept under control.


4. Standardization


/ WE ARE HERE /


In 2017, Devops became mainstream. As shown by Puppet research, the quantity and quality of the introduction of the devops is growing like yeast.


In the conditions of total commodization, we need to adhere to several proven strategies. For example, the emerging stacks of technology and activities need to be arranged in the form of very specific lines, and give these stacks the names.


What directions immediately come to mind?


First, there is a certain “DevOps toolchain” that includes standard elements: the DEV environment starts (code repository, its type check), continues with centralized assembly and storage in the repository (Jenkins, Artifactory), continues with configuration (Ansible, Chef, Puppet) and final deployment (Docker, cloud platforms).


If you hire a new employee (or check what needs to be improved in your own knowledge), all these standard classes of tools must be there, and the ability to build them into a clear, continuous chain of fully automatic delivery. Tools may vary from team to team, but the blocks are mostly unchanged.


Secondly, learning . This can be anything from a planned knowledge transfer within teams or external conferences such as DevOops , and ending with strictly standardized certification trainings. Organizations working in this area already exist, you can contact them right now. For example, companies like DevOps Institute or DASA (Devops Agile Skills Association) are globally represented. If you want to attend a conference (or even organize it on a turnkey basis ), there is a JUG.ru team in Russia for that.


Thirdly, these are formal standards . Right now, there is already " P2675 - DevOps - Standard for Buildings Reliable and Secure Systems Including Application Build, Package and Deployment". General understanding can be compared with ETSI TST006 Report on CI / CD and Devops . Even if you do not want to bother with international initiatives, you should create your own standard for teams within your organization and publish it in a clear and easily accessible way (for example, at Confluence).


A note . Why do we need such a clear division and names? For example, there is a purely psychological phenomenon that if some product or principle is given a clear name, then the person first believes in this name, and then already looks for logical explanations of this belief. For example, it infuriates many that the general concept of "devops" firmly stuck to Jenkins, infuriates with its irrationality. On the other hand, “Jenkins as a basis for devops” is a good launching pad for building trust in what we do. Jenkins is something concrete, substantial, and has justified self-confidence a hundred times. Even in spite of the fact that in 2017 for many it does not look like a top technical solution, but it is a top psychological solution for pushing through their interests. It is important here to focus not on the specific names of products or companies (such as Jenkins and Ansible), but on the needs of our teams (for example, the possibility of rapid integration of changes) in order to develop trust in the whole devops themselves. The same applies not only to tools, but also to training programs, or standard elements of a design culture.


Having built a good standard platform, you can go to a brighter future.


5. Optimization


Optimization is our future. So, thanks to which we will be in the near future to smear sandwiches with butter. Talking about the future is difficult, so I will outline the most common trends.


At the previous stage of standardization, the developers were striving for a fully automatic CI / CD, but they still worked out all the risks manually. Roughly speaking, if the delivery falls apart or the service drops - this is most likely an SMS or a letter to the administrator of the corresponding service, the rise of SRE and devops, and so on.


Most likely, in the very near future, such works will be greatly optimized by intelligent systems that work out the majority of problem situations. Man will manually resolve only the most difficult 10% of errors. This was made possible thanks to the widespread adoption of Docker, microservices, configuration, code, and other well-managed technologies. The person in this model will describe (in the form of program code, or configuration as code) specific ways to solve problems, and intelligent systems will automatically apply these solutions if necessary.


Absolutely all systems will become continuous- * . Continuous integration, continuous testing, continuous monitoring, continuous delivery and deployment. The deployment will go mainly to all sorts of elastic platforms, and the creation of snowflake servers will finally fade into the background even in the most classic companies such as banks.


The overall culture of developing and managing it will also change accordingly. Management learns to love and apply metrics such as number of releases per day, stability (MTR), quality (MBTF), and so on.


The principles of software design change, the convenience for use in standardized (at the previous stage!) Technological and procession stacks becomes an obligatory basis in software architecture and design. For example, for modern products, you should always explicitly consider the interfaces for fully automatic or semi-automatic administration, and if this is not possible in the selected architectural concept, then the architectural concept is sent to the trash.


And if once there were posts like "devops" or "developer with skills of devops" or "administrator with skills of devops", then by the sum of factors we can consider the appearance of a more general and specific specialty of the type "process automation scientist".


All this is too big a burden to stand still and try to solve problems within the framework of the technologies of the early 90s. We can only bravely fight, learn to administer (in the sense of programming) all these new systems, adapt our behavior to the changing rules of the game. I hope all readers of this post will live up to the morning, to our great bright future, and we will discuss the future stages of evolution .


')

Source: https://habr.com/ru/post/336520/

More articles:


All Articles