“Necessity arises from both sides”: the DevOops program committee on the conference and on DevOps

Although the notion of DevOps is already far from the first day, there are still controversies about it, starting with the question "what is it all about." The word combination “DevOps conference” also raises questions: for example, if dev and ops converge here, then the event is designed for viewers with a background in development or administration?



There is a circle of people who know firsthand about all this: the program committee of our DevOops conference, which will be held for the first time this autumn in St. Petersburg. It depends on them what the reports at the event will turn out to be, so we decided to ask them about DevOps and about the conference itself - so that it becomes clearer what to expect from it. In the conversation participated:

')

• Baruch Sadogursky (JFrog)
• Oleg Anastasyev (Classmates)
• Alexey Akopyan (Dell EMC)
• Kirill Tolkachev (Alpha Laboratory)
• Alexander Tarasov (Classmates)

And during the discussion, a question for you all spontaneously arose - so that while reading this text you can also personally influence the conference program!



JUG.ru: In connection with the concept of "DevOps" you can see the controversy. Do you have solidarity on such issues, or are there internal discussions?



Baruch Sadogursky: In my opinion, what DevOps is, everything has long been defined.



















Alexander Tarasov: And in my opinion, a little differently perceive so far. We all have different backgrounds, and we all see different things. As with any word that is a fairly large generalization. Of course, people have a common understanding, but in details it sometimes varies greatly, and only the ways of implementing this idea on the real landscape in general are a zoo.









Baruch: I agree with you that if you start saying “OK, but how we do it”, then everything is different. But it seems to me that there is an understanding of the general idea, such things as “you build it, you own it”. And how exactly to implement it is not so important.



Alexander: Often, DevOps is understood in the narrow sense, when developers are developers, and operations are system administrators (and not support in general, which can be different). But for me this is a broader concept: for Continuous Delivery and other such things to take off, as a rule, the participation of the whole team is required. There are analysts, testers, there is the deployment process itself, and after that the maintenance in the form of monitoring and other pieces. Although in the very word “DevOps” there is nothing about QA, even if you just open Wikipedia, you immediately see three circles on the diagram, one of which is QA.







JUG.ru: Different parties converge in the Devops - and from which comes the main activity? From people from development or from administration?



Baruch: Most devopsniki come from the administration. Roughly speaking, what is our task in the devops? We want the developers instead of transferring what is written to the sysadmins can drag it all right into production, and if it fell there, then it’s their problem.



This means that they must learn this second half: roughly speaking, they must become new sysadmins. There is a completely different skill set, a completely different set of tools, and so on. Who can teach them, who can write all the applications they need, who can build automation within their office? Those former administrators, who are now sometimes called devops engineers. That is, people who come from the administration, become devops enablers, they set up everything and the tools and processes, retrain the culture, go and tell you why you need to do this now - these are all just admins. And former programmers will use all of this, roughly speaking, in order to execute this devops.



Oleg Anastasyev: But I fundamentally disagree with Baruch, there must be intrigue! I will say that rather the opposite: this movement comes from programmers. Because before the emergence of this term, administrators traditionally performed some kind of manual procedures, they had their own processes, their instructions, they solved them manually or by semi-scripts. But programmers get bored with executing commands on machines through the admin, this is a spoiled phone: when the admin reaches the limit of his competence about a product, he starts asking the programmer. The programmer himself does not know what to do, and begins to command: well, look at what is in this directory, and what the dates are, but what it shows, and that is ...



Once in the thirtieth, such command execution via the Skype console pushes, and it is natural that the programmer wants, on the one hand, to have more control over the production system, and on the other, so that it does not take him too much time. And we, as programmers, are very good at writing all sorts of applets, and we have written some of these programs that make life easier for us, then we also wrote them, we modeled them somehow, built the architecture, made them up, twisted them, and it turned out. And then they taught the admins how to get it all to them, install and configure them so that they too began to receive benefits from these applets.



Baruch: Well, Oleg, I suspect that here we are both right and the need arises from both sides, but the popular tools we are talking about (except for CI servers, just because they were created before Devops) are all Infrastructure-as -a-Service, Chef, Ansible, the same Docker and so on - they are created by people from administration, not development. That is, their tools.



Oleg: Well, I don’t know, we have something the other way around on Odnoklassniki. I have nothing to argue on personalities for the listed tools, I just don’t know them so well, but still my point is that if only admins needed this, then no one would do anything. It is important here that synergy is obtained when both camps have their own benefits.



Baruch: I will say this: business needs it.



Alexey Akopyan: I want to add this. In my opinion, it is important that in recent times there have been many services that are replacing products. Traditionally, the bulk of the software business was made up of box products, which the team wrote, then gave in the nth number of customers, they had to be deployed somewhere. Accordingly, instructions were needed, because admins were primarily on the customer’s side. And now the industry is quite evolving towards public services (and internal ones too). Accordingly, we are more often confronted with the fact that there is a service with which users interact often through a single deployment, which is smeared in some cloud, which needs to be maintained. And this, in my opinion, gave a very big impetus to the entire ideology of the devops: sharing not the code, but the working service.



JUG.ru: And what does all this mean in relation to conferences? For whom DevOops is primarily intended: people with a background in development or administration?



Baruch: Traditionally, almost all Western conference devops (like DevOps Days, DevOps Enterprise Summit, and so on) are very focused on DevOps from administration. They discuss the guts of their tools there and, roughly speaking, “how to train programmers to make the right devops.”



And it seems to me that in our conference it’s interesting that we will also have programmers. The main audience of all conferences JUG.ru Group programmer in general. The approach “even if you are not administrators, come to the conference by devops” - it is always correct in general, but for us it is especially correct and interesting: firstly, because it is a natural audience for us, and secondly, because it is quite unusual for traditional devops conferences.



Alexander: I would not even be limited to "developers and administrators." It seems to me that it should be interesting to a large circle of people who are basically interested in automation issues, improving the organization of the development and implementation process to speed up the delivery of value to the client, what tools can be used for this now, and how they will solve his problem. One will be interested to hear about the hardcore part, “how to do supermonitoring, which will monitor ten thousand services”. Others are more interested in solving organizational problems. Although technical reports prevail in our country, most often problems in this area are both technical and organizational, because there are many parties involved in the process, each with both common and different interests.



JUG.ru: Already, according to the list of key topics, it is obvious that the reports will indeed be severely technical: specific tools are immediately indicated everywhere. Not just “Continuous Delivery”, but with the listing “Jenkins, TeamCity, Bamboo”. Are more general performances that are not tied to a specific product?



Baruch: I think there are two components here. First, talk about some kind of common Continuous Delivery - they are abstract, nothing. It will be either something very superficial, or something completely without a specific application. And our two fundamental factors when choosing reports, as usual with the conferences of the JUG.ru Group, are, firstly, utility, and secondly, hardcore. And some general reports will not be particularly useful, not particularly technological, not particularly hardcore.



Secondly, there is a question that we, in my opinion, have not yet decided. Because of the background of JUG.ru, we have sharpened for specific technologies and tools: guts, hardcore and technology, and not soft skills and agile.



But in application specifically to Devops, this turns out to be a problem, because any person who really has a relationship with him will tell you that the tools and technologies in the Devops are not the first thing. Yes, we love to talk about it, and it is convenient for us to talk about it: we are all technologists, programmers, we are immediately drawn there, let's look at the configs.



However, problems are in the behavior of people. How to change it so that from two camps - programmers and administrators - one process turned out? And so far no one affects us: firstly, in principle, it is not very clear how to affect this, and secondly, such a report by the standards of JUG.ru will be branded with light and soft skills.



I hope that the opening keyout is just that. At least, my and Leonid Igolnik closing keyout will not be 100% about technologies. But the question remains here.



Kirill Tolkachev: There are reports at other conferences that can be called BizOps. Conventionally, I, as the head of a large company, talk about the advantages of introducing a devops in my company with numbers explaining the formula for success. Listen, do we want this?



Baruch: Very dependent on the report. Just to my groan about the fact that we have solid tools from the “people-process-tools” triangle: such a report would have been very cool for people and process, if it were not just chatter, “I told my subordinates, and they at first they were against ... ”, namely, with calculations, numbers, processes, what has changed, who was fired and who was hired. This is all, I think, it would be not just a good report, but an excellent keyout.



Alexander: This is an interesting look from the outside, with the upper-level. Very often, people who work in ordinary positions simply do not understand what problems there may be and why large companies make certain decisions that seem illogical at first glance. If this is beautiful and well talked about, it can be very interesting.



Baruch: Or maybe make some kind of pair report? Roughly speaking, someone of a fairly high level on the business side, someone on the development side. And to show this discussion: on the one hand, how can developers persuade bosses, and on the other hand, how is it difficult for bosses to work with developers? Or even gather a few C-level people and have a panel discussion?



Alexey: Can we do a survey on whether this discussion will be interesting to our audience?



JUG.ru: Yes, no question. Readers who have an opinion on this issue - please follow the link and click on one of the options, you will help us to make the conference better.



Returning to the “reports are tied to the instrument”: will the speakers be mainly those who actively use these tools, or those who create them?



Baruch: There are different cases. We have speakers from HashiCorp, a company that produces a very large number of very good devops products that we all love. I hope we will have one of the developers of the Google Cloud Platform - naturally, they are also very fond of them. There will be even a person who was involved in the development of JFrog Artifactory, believe it or not!



JUG.ru: Due to the fact that you yourself work at JFrog, and with the fact that some other speakers will present their own projects, there are probably people willing to say "let there be a terrible marketing, no good." Want to answer this?



Baruch: Well, it goes without saying that we are striving to make the reports as deep and interesting as possible, and in no case by any advertising product pitch. Reports are selected by their technical components, we do runs and rehearsals to be sure that they will not be a product pitch. Those who were at other conferences of the JUG.ru Group could already be convinced of this.



But certain people think that if you represent a company and mention the name of its product in a report, it doesn’t matter what you say about it, you are evil and you need to be thrown in tomatoes. Sorry, sore!



I will say this: if you have used any project or are planning to use it, then the report on this project on DevOops will be interesting and useful for you. If you don’t use it and don’t use it, then you are simply not going to this report. We will have several tracks, you can always choose. But I have no doubt that if a person uses Terraform or Packer, then he with great pleasure will go to the report of a person who works at HashiCorp.



And thanks to the fact that the conference in Russia, we are more or less protected from the onslaught of those who want to advertise. In Russia, the development of products for devops is still underdeveloped. We practically do not have someone who serves himself "so I want to tell you about my product." Most of the products that will be discussed at this conference - both CI servers, and scanning tools, and virtualization - have been developed abroad. And so the speaker from this company can get to us only if we invite him. And when we invite him, naturally, we take all the necessary measures to ensure that this is not a product pitch.



Alexander: There are still cases when a person doesn’t seem to drown very much for technology, but the report leaves a sugar-cotton feeling that everything is so wonderful, take it straight and will work right away, no pitfalls ... As a rule, such reports fall into the category “101 ", These are overview reports, or entry level reports. They are useful to people who know nothing about this technology or know very little.



And for those who are already studying something themselves, use in production, internal implementation details, and especially pitfalls, are more interesting. Therefore, it is great if the speaker does not only well know his product, library, technology, and tells the positive sides, but also knows the problems of users and can tell about various trade-offs that exist in any engineering solution.



JUG.ru: At other JUG.ru conferences, for example, Joker , there have already been "okolodevopsnye" reports. What happens now when there is a separate conference - are they all moving there, or will they still be seen on Joker?



Baruch: This is a very good question, which I, being in the program committee of both conferences, see from both sides.



On the one hand, yes, there is a great desire to move all devops reports to DevOops. But, on the other hand, when the topic is interesting, I don’t want a person who will come only to Joker and was not going to go to DevOops, to leave without these topics in general. Therefore, we try to leave those reports that are relevant to both devops and Java to Joker, and to DevOops to bring those that are not related to Java.



Oleg: I will add that even if the topics at the two conferences turn out to be the same, then at DevOops they will be mostly about processes and some management-operational parts, and at Joker there will be more hardcore and programming. The theme is the same, but will be considered from different sides.



JUG.ru: Thanks for the replies. Would you like to add something else?



Alexey: That after DevOops a feedback gathering will help us answer all the same questions for the next conference. Let's understand in practice what those people who really came, were enough for DevOops, and what was not enough.



JUG.ru: That is, from the people who come to the first conference, it really depends on what the second one will be? Good incentive to go.

---

DevOops will be held for the first time on October 20 in St. Petersburg, tickets are already on sale (and they get more expensive with time!). Key topics:



- Containers, Orchestration (Docker, Kubernetes, Clusters, etc).

- Virtualization, Cloud technologies (AWS, Azure, Heroku and others).

- Monitoring and auditing of applications (Prometeus, OkMeter, DataDog, BPF, Dynatrace, XRebel, Glimpse, Zipkin, OpenTrace and others).

- Continuous Delivery (Jenkins, TeamCity, Bamboo).

- Configuration Management (puppet, chef, ansible).

- Security (Vault, etc.)

- Debriefing on examples of large projects that implement DevOps: successful and failures.