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

Although the notion of DevOps is already far from the first day, the debate about it still does not stop, starting with the question "what is it all about." The phrase “DevOps-conference” also raises questions: for example, if “dev” and “ops” converge here, is the event aimed at viewers with a background in development or administration?

There is a circle of people who know all this firsthand: the program committee of our DevOops conference , which will be held for the first time this fall 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 the conference itself - so that it becomes clear to everyone what to expect from it. The conversation was attended by:

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

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

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

Baruch Sadogursky: In my opinion, what is DevOps, everyone has long been decided.









Alexander Tarasov: And in my opinion, they still perceive a bit differently. We all have different backgrounds, and we all see different things. As with any word, which is a pretty big generalization. Of course, people have a common understanding, but in the details it is sometimes very different, and the ways of implementing this idea on a real landscape are generally a zoo.




Baruch:I agree with you that if you start saying “okay, how do 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 exactly how 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 maintenance in general, which can be different). But for me this is a broader concept: for Continuous Delivery and other similar 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 support in the form of monitoring and other pieces. Although there is nothing about QA in the word “DevOps”, even if you simply open Wikipedia, you can immediately see three circles on the diagram, one of which is QA.



JUG.ru: Different sides converge in the devopa - and with what comes the main activity? From people from development or from administration?

Baruch:Most devopsniki come from the administration side. Roughly speaking, what is our task in devopa? We want the developers, instead of throwing what is written on the system administrators, to be able to drag it all into production, and if it fell there, then this is their problem.

This means that they must learn this second half: roughly speaking, they must become new sysadmins. There’s 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 inside their office? The same former administrators, now sometimes called devops engineers. That is, people who come from the administration side become devops enablers, they configure everything and tools and processes, retrain the culture, walk around and tell why you now need to do this - these are just former admins. And former programmers will use this all, roughly speaking, in order to fulfill this devops.

Oleg Anastasiev:But I fundamentally disagree with Baruch, there must be intrigue! I will say that it is rather the opposite: this movement comes from programmers. Because admins, prior to the emergence of this term, traditionally performed some kind of manual procedures, they had their own processes, their instructions, they solved them manually or in half-scripts. And programmers are bored of executing commands on machines through the admin, they get such a damaged phone: when the admin reaches the border 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 dates, but what shows, but ...

Once in the thirtieth such execution of commands through the Skype console is crippling, 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 programs, and we wrote some of these programs that make life easier for us, then we also wrote them, somehow modeled it, built the architecture, screwed it up, twisted it here - oops, and the devo turned out. And then they taught administrators how to get it all done, installed and configured so that they too began to receive benefits from these programs.

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

Oleg: Well, I don’t know, here in Odnoklassniki it’s somehow the other way around. On the listed tools, I have nothing to argue about personalities, I just don’t know them that well, but still my point is that if only administrators needed it, then no one would do anything. It is important here that synergy is obtained when both camps have their own benefits.

Baruch: I’ll say this: business needs it.

Alexey Hakobyan:I want to add this. In my opinion, it is important that in recent years there have been many services that are replacing products. Traditionally, the bulk of the software business was packaged products, which the team wrote, then gave out in an unlimited number of customers, they had to deploy somewhere. Accordingly, instructions were needed because the admins were primarily on the customer side. And now the industry is evolving quite strongly towards public services (and internal ones too). Accordingly, we are more often faced with the fact that there is a service with which users often interact through the only deployment spread in some cloud that needs to be supported. And this, in my opinion, gave a very big impetus to the whole ideology of devops: joint ownership of not a code, but a working service.

JUG.ru: And what does all this mean in relation to conferences? Who is DevOops primarily for: people with backgrounds in development or administration?

Baruch: Traditionally, almost all Western DevOps conferences (like DevOps Days, DevOps Enterprise Summit and so on) are very focused on DevOps from the administration. There they discuss the guts of their tools and, roughly speaking, "how to train programmers to do the correct devops."

And it seems to me that it’s interesting in our conference that we will have programmers as well. The main audience of all JUG.ru Group conferences is generally programmatic. The approach "even if you are not admins, come to the conference on devops" is generally always correct, but it is especially correct and interesting for us: 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 limit myself to "developers and administrators." It seems to me that it should be interesting to a large circle of people who, in principle, are interested in automation issues, improving the organization of the development and implementation process to accelerate 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 that will monitor ten thousand services.” Others are more interested in solving organizational problems. Although technical reports predominate in our country, most often the problems in this area are both technical and organizational, because there are many parties involved, each with common interests and with their own.

JUG.ru: Already from 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 a listing of “Jenkins, TeamCity, Bamboo.” Are more general performances not tied to a specific product supposed to be?

Baruch: It seems to me that there are two components. Firstly, talking about some kind of general Continuous Delivery - they are abstract, about 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 JUG.ru Group conferences, are, firstly, usefulness, and secondly, hardcore. And some general reports will not be very useful, not very technological, not particularly hardcore.

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

But in an 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 tools and technologies in devops are not the first thing. Yes, we love to talk about it, and it’s convenient for us to talk about it: we are all technologists, programmers, we are immediately drawn to it, let's look at configs.

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

I hope that the opening keynote will be just that. At least my closing keynote with Leonid Igolnik will not be 100% about technology. But the question remains.

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

Baruch:Very dependent on the report. Just in time for my groaning that we have solid tools from the “people-process-tools” triangle: such a report would bring people and process very cool if it weren’t just a chatter “I told my subordinates, and they at first they were against ... ”, namely with calculations, numbers, with processes, what changed, who was fired and who was hired. That’s all, it seems to me, would be not just a good report, but a wonderful keynote.

Alexander: This is an interesting view from the side, from the upper-level. Very often, people who work in ordinary positions simply don’t understand what kind of problems there may be and why in large companies one or another decision is made that at first glance seems illogical. If it’s nice and nice to talk about this, it can turn out very interesting.

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

Alexei: Can we do a survey on the topic of whether our discussion will be interested in such a discussion?

JUG.ru: Yes, not a question. Readers who have an opinion on this subject - please follow the link and poke in one of the options, you will help us make the conference better.

Returning to “reports attached to the tool”: will the speakers be primarily 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 devobs products that we all love. We hopefully will have one of the developers of the Google Cloud Platform - they, of course, are also very fond of. There will even be 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 the fact that some other speakers will present their own projects, there are probably people who want to say, “let there be solid horrible marketing, no use”. Would you like to answer something?

Baruch:Well, it goes without saying that we strive to make the reports as deep and interesting as possible, and by no means some kind of promotional product pitch. The reports are selected according to their technical component, we do runs and rehearsals to be sure that they will not be a product pitch. Those who were at other JUG.ru Group conferences could already be convinced of this.

But certain people believe 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 a representative of evil and you have to throw tomatoes. Sorry, pent!

I will say this: if you have used any project or plan to use it, then the report on this project on DevOops will be interesting and useful to you. If you do not use and do not think to use, then you simply do not go 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 will go to the report of the person who works at HashiCorp with great pleasure.

And thanks to the fact that the conference in Russia, we are more or less protected from the onslaught of those wishing to advertise. In Russia, product development for devops is not yet sufficiently developed. 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 — CI servers, development tools, and virtualization — are developed abroad. And therefore, a speaker from this company can get to us only if we ourselves invite him. And when we invite him, we naturally take all the necessary measures to ensure that this will not be a product pitch.

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

And those who already study something themselves, use it in production, are more interested in the internal implementation details and especially the pitfalls. Therefore, it is great if the speaker not only knows his product, library, technology well and talks about the positive aspects, but also knows the problems of users and can talk about the various kinds of trade-offs that exist in any engineering solution.

JUG.ru: At other JUG.ru conferences, for example, Joker , there were already “near-European” reports. What happens now that a separate conference has appeared - are they all moving there, or can they still be seen on Joker?

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

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

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 more about processes and some management and operational parts, while at Joker they will be more in hardcore and programming. The topic is the same, but it will be considered from different angles.

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

Alexey: That after DevOops collecting feedback will help us answer all the same questions for the next conference. We will understand in practice what was really enough for those people who really came to DevOops, and what was not enough.

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

---

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

- Containers, Orchestration (Docker, Kubernetes, Clusters, etc).
- Virtualization, Cloud technologies (AWS, Azure, Heroku and others).
- Monitoring and audit 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 the examples of large projects implementing DevOps: successful and failed.