The first deployment: how was the DevOops 2017 conference

The organization of conferences has its own “dev” and “ops”: for success it is required both to “develop” a program from excellent reports and “roll it out to the product”. And with any new conference, as with any new software product, a lot can go wrong at both stages. We first had DevOops - what was going on there, and didn’t it work? On Habré has already appeared feedback from one of the participants, and now we publish your text.

Among the daunting difficulties there is, for example, such. When choosing a site for a conference, it is necessary to proceed from the number of viewers, but if such a conference had not been held before, how to predict this number? Will the real demand not be much lower or higher, so that the site will remain almost empty or will it burst at the seams? It looks like the eternal problem of start-ups "on which loads to count." But in the end, some fatal discrepancy did not arise, and the conference facilities of the Crowne Plaza approached the hundreds of people who had gathered.

But in the course of the conference another problem of volume correspondence arose. Both the opening ceremony and the Keynout Corey Quinn who followed her took less time than was originally supposed - so that when Corey finished speaking, there was still a decent time on schedule until the end of his talk. But this is not so bad: after their presentations, the speakers moved into a special discussion area, so if you wanted to get more from the speaker, you could always do it there. And Corey couldn’t complain about the lack of interest in this zone:
')


If the “ops-part” in the case of Corey Queen gave a slight glitch, then with “dev” everything was different: the performance itself received excellent reviews, and repeatedly caused laughter in the hall. Corey sarcastically criticized the situation when large companies talk about their infrastructure as the only true, while others look into their mouths. In his opinion, it looks like a cargo cult, when people see “everything works well for them” and imitate external signs based on the same success, not taking into account the internal difference:

“I saw a speaker from Netflix say from the stage“ we give all developers access to the prod ”. Everyone in the room was impressed, and the person next to me said: “Yes, we should also give developers access to the prod”. I looked at his badge and saw that he was working in a bank! Listen, you need to take context into account. First, Netflix takes pride in not taking the juniors - of course, it is easier for them to give access when all are experienced. Secondly, they pay higher than the market - and everyone wants to “make it like Netflix’s”, but for some reason they are not eager to pay higher than the market. Thirdly, for all scales of Netflix, they just stream movies. If you don’t start the film, it will not be as big a problem as if there is a failure in the bank. ”



After keyout, the action diverged in different halls, and it was possible to see how not just different topics begin, but different approaches to the notion “devops-report”. Our other conferences, from Joker to Heisenbug, are known for their “hardcore”: technical specifics in reports, not “general chatter”. But with DevOps, as noted earlier in an interview with a member of the program committee Baruch jbaruch Sadogursky , everything is more complicated. In this case, “processes”, “people” and everything else that would look like “soft skills” at a Java conference turns out to be the most important components, and you cannot reduce DevOps-problems to you only with Docker. What then is the program to do? Usually, we pay a lot of attention to reviews of reports, better understanding what to give to viewers next time, but there were no reviews yet, so it was necessary to take risks in this regard. As a result, various options were present at DevOops - and which of them are more suitable for the audience, it was only possible to understand completely after the fact from the reviews.



Say, in the very first time slot you could see completely different reports: while Adrian Cole talked about distributed tracing using Zipkin, the same Baruch together with Leonid Igolnik talked about what should be the correct duty.

In the first case, it was precisely that technical specifics. Adrian began with how the concepts of “tracing”, “logging” and “metrics” correlate (referring to a visual diagram from someone else's blog post ), and later went directly to Zipkin, and telling about it theoretically, and demonstrating its use in practice . It seems that the only somewhat distracted fun fact in his speech was why Zipkin is so called. It turns out that when Twitter regularly fell and showed the so-called “fail whale”, Zipkin was created there to fight this, and used the Turkish word for “harpoon” (that is, he had to “help kill the whale”).



But Baruch and Leonid had a different performance. Although the value of the correct tools for working with logs was mentioned there, more often it was about things like the escalation path: who and under what conditions the employee should be on duty when his own competence to solve the problem is not enough. Of course, this is not about technology, and, of course, the report had a lot of jokes and jokes (it would be strange to wait for another with Baruch) - but it is also impossible to call it “common talk”, there were enough specifics. Moreover, some things were both funny and vital: “Why should the escalation path go to the company's CEO? First, the practice shows that if in 5-6 hours you have to wake up the director, then you have much more problems to decide during these 5-6 hours! ”

And what, which of the two options was interesting to the audience? You will laugh: the difference in the weighted average of the audience ratings of these two reports was some three hundredths - this can be considered a statistical error. And at the same time both of them were in the top 5 reports of the conference. With such success, it is obvious that the audience is interested in both.



However, with all the difference between these two reports, they have something in common: they both about the fact that you can directly implement in your company, be it at least a technological tool, even a work process. And there are reports like “there are no direct instructions on how to change your project, but it is useful to know” - was there such a thing here? Yes: for example, the story of Oleg m0nstermind Anastasyev about how classmates moved from the division “each server is responsible only for one task” to a “private cloud”, when several tasks can be performed on one server at a time. Their solution of one-cloud is not in the open source, so you don’t use it yourself - but, following someone else’s logic, you better understand the principles common to all. If some tasks require minimal response time, others (conditionally “batchevy”) require a lot of resources, and still others (“background”) can wait for their turn, then how to divide the CPU resources between them correctly, and what parameters of the Docker launch will help to do this? And what to do with traffic, where Docker has no corresponding parameters for separation at all?



Curious was still a round table "How to" sell "DevOps colleagues, superiors and other indifferent." It would seem that in the case of both "technical" parties - development and administration - one can rest on specific metrics, showing the acceleration of time to market and other indicators. But in the dialogue, the participants of the round table about both these parties noticed that there are concerns related to job security: administrators are afraid that they will not be needed, and they will be fired, and the developers - that they will break production, and they will be fired. At the same time, people may not express such fears out loud, but simply otbryvatsya from any technical arguments, until the fears are dispelled. And it turns out that to build DevOps successfully, understanding people is no less important than understanding Kubernetes.



But to understand Kubernetes, of course, is also important - there were several reports about him at once, and the audience rated the performance of Nikolai Ryzhikov above all. Here there was a solid technical specifics: “There are a number of resources, for example, ConfigMaps and Secrets - this is a purely informational resource that you can download to your container and transfer, for example, passwords from Postgres. You can associate this with environmental variables that will be injected into containers, when they start up, you can download it to the file system, everything is convenient. ”



Finally, Keynout Baruch Sadogursky and Leonid Igolnik finished the conference, stylized as “Greek tragedy” (to the extent that there were vases on the stage, and the speakers were in togas). In practice, however, it was more like a comedy: over the misadventures of an imaginary company that faced various DevOps problems (from the story from the left-pad to the story with GitLab ), the entire audience regularly belched . Here, there were no such concrete practical conclusions as the report on duty, but this was not required from the closing speech. In the end, everyone was delighted, and the "tragedy" led the hit parade of audience reviews. As noted in the reviews, Baruch is always charismatic, but with Leonid he generally has a synergy - these are two perfectly complementary speakers.

What is the result? The first production test, despite some minor difficulties, was generally successfully completed. But anyone related to Devops knows: to release a single release is one thing, and you try to build a Continuous Delivery with regular updates. Well, we will try: now, when the first DevOops was successful, we could not escape the appearance of the second.