Why it is impossible to let programmers to the servers, or Why devops did not die out yet, although they talked a lot about it

Hi, Habr!

Today we have an unusual material. We will not publish a tutorial or consider new frameworks, but simply give the floor to a colleague who has something to say.
')
The opinion of the author may not reflect the position of the company and other colleagues.

Meet - Alexander Efimov, Configuration manager / DevOps

I have a friend who, being a first-class sysadmin, dreams of becoming a programmer. According to him, he wants to create, and not to use the already existing ... not very good software. In some ways, I understand him: “pure” creativity is certainly cool. But let's see what is really happening.

I have been working as a devops for quite a while. The projects in which I had the honor to participate, inevitably went through the following phases:

1. Anarchy. Each developer makes and commits everything that he wants (at least, this is how an outsider sees it). At the end of the sprint, the “most guilty” collects all the groundwork for a cadavre running on his machine and (theoretically) on one of the servers. Then, going through circles of pain and hell, it is embedded on the server and somehow it works there.
2. "Staging works." Finally, the customer has allocated money for one server of aging. Now the hell with the assembly of a working prototype is repeated for staging too. The piquancy of the situation is that all the “strapping” in the form of a database, a queue server, a cache server and others lives on localhost. That is, we get the same developer machine, only remotely. With all the conclusions of the hardcoding type of the sensitive connection parameters.
3. We need some admin. At this stage, everything, created earlier, has already become uncontrollable, styling is bad, production is not updated. Here someone comes who will be called DevOps, and begins to rake a mess and distribute nominal pendels means of motivation. If ever comes.

Here we come to the most important - the conflict of Development and Operations. He has already been considered and obmusoloj from all sides and briefly looks like this:

Next, I will try to explain why for me the solution to this conflict is in the title of the article.

Creativity vs. the order

Software development is a creative process. Managing the creative process involves flexibility and the ability not to interfere. Actually, the Agile methodology grows precisely from this: its goal is to control the chaos, minimally ordering it. And this, in my opinion, is really good: with a properly done Agile, a good product is obtained.

Operation, on the contrary, requires an absolutely clear knowledge of all elements of the system, configurations, potential points of instability, and so on. ITIL and similar methodologies dominate here.

Developers, in principle, are not sharpened to streamline everything strategically - it's just not their profile. Moreover, most simply do not think about some little things that can later lead to great consequences.

An example from life. Suppose, by default, log files are in the application directory. Developers are comfortable: you always know where to look. The developer deploys the application on a test server. Three days later, the server disk is full, the queue server has fallen, the database is yelling into its logs that there is nowhere to write. Nothing works, demo after three hours, all in shock. And the reason is simple: it was necessary to shift the logs to a special section and / or adjust the rotation. With this, even a novice admin / DevOps would have coped with the machine, not really thinking about why this is necessary. Just "for order."

Ability to use existing solutions

When I first started working in a software development company (in that company for internal use), I was surprised by their monitoring system. It was self-written and incredibly buggy. In 2009. The infrastructure department had to go through a lot in order to convince the authorities that Zabbix had to be implemented.

I encountered similar problems several times in different companies, and everywhere it was the same thing: “it’s easier for us to write our own than to understand someone else’s.” Later, I understood the reason for this way of thinking: developers really are easier to develop. This admins are accustomed to dig into configs, "sniffing" several systems into one. Sometimes through parameters, sometimes with scripts, sometimes with both. A developer is easier to write 100 lines of code than to understand the documentation and configs.

In general, here the conflict of approaches is very acute. The admin will not get into the code until he gets it, just like the developer will not get into the configs.

Difference of competences

This partly follows from the above, but the fact remains: the sysadmin / DevOps and the programmer / developer have completely different competencies.

The programmer will be able to configure the server. Probably. But he is unlikely to take into account potential problems that are not obvious to him and solve them immediately. The same applies to the infrastructure: the developer simply will not understand it and will do everything “by default” + according to StackOverflow advice.

An example from life. At one of the previous jobs, in a small software company, I was faced with the question of the authorities “why do we need admins / DevOps?”. And indeed, they didn’t understand what the system administrator was doing. IP-addressing in their local network was from the Internet-range (good, this subnet belonged to some of the American providers of home Internet access). We used soapbox switches and the usual home router for accessing the Internet. These people have developed a very serious distributed system (I can not say what), trying to make it fault tolerant. After about six months of development, the realization that it is necessary, nevertheless, to hire someone who understands server hardware and operating systems, won out.

Conclusion and conclusions

In my opinion, the separation of spheres of influence is wonderful. You can be arbitrarily versatile "spherical IT specialist in a vacuum," but you just can’t manage it all. That is why developers develop software, and administrators create and manage infrastructure and the same software.

Programmers should not be allowed on the servers, not because they are bad, but because this is not their concern. To do this, there is a devops - “a stranger among his own”, a human-admin in the camp of developers, who has adapted to chaos and created a strange order in it, called a bunch of phrases with Continuous (Continuous Integration / Deployment / Delivery / Operation).

Therefore, dear programmers, developers, architects, do not be offended if you dream of a bearded man in a sweater late at night reproachfully, “again you changed the format of the config, and my deployer fell.”

And you, dear devops and admins, be tolerant to developers. They are constantly looking for new, better solutions. Because of this, their work resembles chaos, but contains a higher order.

But do not let them on the server anyway.