“Kubernetes in all fields!” - an interview with the DevOops conference program committee
What is interesting to DevOps engineers now? The team of superheroes - the DevOops conference program committee - fell into a devilish trap in Hangouts and answered questions for an hour. (Who are all these people - it is written in detail by reference ).
Under the cut - an interview, colored with crayons. Each expert has his own color:
Baruch, what do you think was happening in the world from the past of DevOops?
It seems to me that the most interesting thing from the obvious is that Kubernetes takes off in all fields, and from the non-obvious - less noticeable, but no less important, is the doker consumerization.
That is, before the docker was not for everyone?
Not. Previously, the docker was a cool, youthful thing in itself. And then somehow the docker has ceased to be interesting, that is, it is there, it is for everyone and in everything, it has all microservices, Kubernetes, devops, whatever. But by itself, a docker as a technology suddenly somehow interests no one anymore. Do not run the same java on the servers, it is clear that the containers. It really mesmerizes me.
People usually discuss what they have problems with or direct tasks. There were no problems in the docker, and were they there?
There were many problems in Docker, and they really decided. In addition, we stopped using those parts of the docker that were painful. Docker had things he could do very well. And there are those that are bad.
Give an example.
For example, jails in unix-processes - everything is very good and smart there. It really works very cool. But for example, the connectivity between microservices that run in containers, clusters, deployments, it was all hell and nightmare.
Do you mean the Swarm, with which they tried to keep up with the Kubernetes?
Yes, I mean Compose, that was all a nightmare and hell. And we decided not to use it, but to use only what works, what is clear and free. And the docker has become very cool on the one hand, and on the other hand has ceased to be interesting. Docker and docker - well and good.
Now, when you look at a new software, first of all you are looking at whether there is a ready container. It is desirable from the manufacturer of this software. Then you look at how to unwrap it and poke it with a wand. Docker delivered us complex services to poke on a working machine. Now it’s not so important whether you have a makos or Linux. The same Sentry consists of 5-6 components, which you are separately charged to run. And if your task is to just see how good it looks, send a signal and watch how it decomposes there. Now it will take 15 minutes - launched, unwrapped it, and the piece will be on Ruby, a piece on Java, God forbid, some Elasticsearch - which will die with the same docker.
Most importantly, he will die later.
Yes, this is a separate charm. Previously, it was possible to spoil yourself in the system so that there was nothing in / usr / local. And it will still rise - from someone in / opt, from someone in / usr / local, from someone else. And your system is swelling, overgrown with all unnecessary. This is one thing, and the second is that the more unnecessary you have, the larger the vector of attack on you, which is why you can be offended. And since we are all launching it now in dockers, then security is here, and clean, and you don’t carry all sorts of nasty things with you.
Listen, ladies and gentlemen, you are doing a conference on devops, and there if the docker has become boring and uninteresting, now what will the docker not have?
First, the docker will be everywhere. The fact that it has become boring and uninteresting does not mean that it will no longer be used. On the contrary, this means that we now use it and do not pay attention. That is, he is everywhere. He is not the subject of a separate conversation at conferences.
Does he have any reports? If I enter the program now and write the word docker, will there be nothing?
Write it. Let's do this great experiment.
Wrote, and it says: Practical steps for securing your container deployment
This is a reflection of the fact that docker allows our modern systems to be safer in a natural way. In addition, it reflects one more thing that may have changed too lately ... Devops has become more. Let's just say, they have become increasingly imbued with large companies. And along with them, there were more and more conversations on the topic of security, which a devops can bring or, on the contrary, break this security. Liz's report is about how to properly prepare this devops so that your guards would be happy.
Do you personally know the speakers? Who is Liz Rice?
Liz is quite an important figure in the landscapes. She is the head of all KubeCons. Actually, Liz is, first, a very good speaker. Secondly, she works for Aqua Security, which deals with the security of containers. We will not find the best person for the story about the safety of containers than the one who specifically deals with it. What is interesting specifically about the reports of Liz, I have seen many of her reports - this is what she is trying to solve a rather complicated problem. The problem is that today security is, firstly, complex, and it becomes more complicated and more difficult, as attacks become more sophisticated. Accordingly, it becomes more difficult to defend against them, we must encrypt our information via REST, we must encrypt in-traffic, all kinds of TLS, https, certificates, protocols ... all this is complicated. With the letter A at the end. Firstly, it’s difficult, and secondly, there’s no way out of it, because you can’t say now: “Oh, I don’t know, let me not do https. Well, who cares who I need. ” Since the same nasty Chrome will immediately shout at all your users that everything is not secure for you. And this is a combination of complexity and necessity, it freezes, because it is not our concern, we are not all safe. On the other hand, it lies with us, because we cannot just ignore these aspects. In her reports, Liz is trying to simply and clearly convey key aspects of container safety to people who are far from safety, and this is very cool.
There is another problem that people are dragging containers into their mouths from anywhere. They often do not even know what is inside there. It's one thing if you want to stumble with your wand on your laptop. And another thing - to drag it in production. And, unfortunately, many are pulling anything. That is, you need something that is difficult to assemble, they take ready and well, if from the manufacturer who took care of and took the normal base containers. And this is the vector to attack. For example, we may soon find a new wave of containers of the same name, as was the case with peep modules, with het modules. As was the case with domains, everything is the same. That is, this is not a new problem, it is still the same old one. And when a service becomes a commodity, when it spreads like this - people come there who punish those who don't follow security. By the way
And what else is there?
We still have a secret management solution from Seth Vargo. By the way, there will be a security roundtable with him.
Is Seth the same person from Google who used to work at HashiCorp?
Before that, he worked at Chef Software and was a star there when Chef was at the peak of popularity. He left a mark on almost every cookbook. Even some people disliked him for this activity. Then he inherited a lot in HashiCorp. And this trail HashiCorp behind him still stretches. Here he will talk about the product HashiCorp. About Google, he will not tell. But in the title he will have Google, so it adds weight.
By the way, what happened to Chef?
In some places, Chef was killed by those very containers.
Chef applications where they were written and work - as far as I understand, they can continue to work for a long time, because configuration management itself has not died.
Guys, I can tell you by a live example. We have something that is not in docker, then under the Chief. Because the server-snowflakes did not go anywhere.
You just said what happened to Chef. That which is not under the docker, then under the Chief. But under the Docker we have almost everything.
Everything is correct, but still there remain long-lived servers, servers with data that no one wants to shove. Here they will still live for some time with Chef, because everyone who has been in the normal world does not want to return to the manual control room.
By the way, does Ansible use any of those present?
Yes, Ansible too.
We use.
And How? Why Ansible?
Delightful ability to turn into trash with wild speed. Here is the impression Ansible leaves. Such a convergence to hell, I have not yet met in my life.
It seems we have a report about it!
Exactly. And it helps just not to turn the result of working with Ansible into what I mentioned. And this is amazing, sorry, I did not see him when we wrote this all good .
You say that everything starts up under the docker, but the servers themselves, in order to start the hypervisor on them, need to be configured somehow?
No, you take in Amazon ...
And, cheater, in Amazon. Clear.
Or Terraform - anywhere.
Most advanced. And about this, we also have a report .
Terraform closes this need, that there are a lot of providers, they run virtual machines in different ways, and you use Terraform to close the layer when you have a car. Then you have a provisioner in Terraform, the same Chef, the same Ansible. Some provisioner pours the next layer, and then Docker flies to this minimally finished machine. Profit
And the report is led by the person who did aws-modules for Terraform?
He did a lot for the Amazon modules, but this is the community part. And this person is interesting as follows: since he lived with Terraform for a long time, then in the community, where he hangs out all these years, certain best practices have been formed, and around Terraform these best practices are just not enough, because he is so simple in places It does not allow you to make unnecessary movements, which sometimes the description is too complicated. You will have either a footcloth, or vice versa, a very complex interconnected structure. And we hope that Anton Babenko, who will be just tellingabout all this, it will help to sort through how to live with Terraform and not suffer from it. How to develop your modules for personal needs, so that they continue to remain clean, readable and, by the way, there, of course, nobody tests anything either.
Nobody tried these terraform footcloths from a more convenient metalanguage to generate?
There are such ideas. And we try not to do that. There, in fact, Terraform has data structures that can still do without generation, but it is difficult. Imagine that you have several vpc in your Amazon in different regions, you need to peer between them, and here you begin the adventure. In each API region, the entry point is different, and Terraform as if you are talking about one. That is, you need to resolve these entry points in the description, describe each vpc and another peering, the connection between these vpc in different regions. And all this must somehow be described. We have done this with our own modules, and with this somehow it became possible to live. Generally, hard, difficult. But if Terraform would give even more possibilities, if there ... What is it called when a variable inside a variable clears up?
Kotlin DSL.
<all hell laugh>
Variable, or interpolation - depending on what you mean.
In general, this is not a full-fledged language, it is very truncated. He makes you write as simply as possible, unlike Kotlin DSL, where you have a full-fledged Kotlin in your hands.
Well, with all the limitations of Kotlin DSL, which you understand, are solved by what?
Than?
Groovy DSL are solved naturally!
Many people used TeamCity from here?
Yes of course. Gruvy DSL, Kotlin DSL, we have a report about it!
And of course you do it?
I do not do it, no! We will have just TeamCity with Kotlin DSL and its comparison with Groovy DSL in Jenkins.
Someone from JetBrains arrived?
Not. This is a separate charm.
We have real users, no marketing.
All I give up, who else can make a report about TeamCity?
A small company, commonly known in Russia as Tinkoff, uses. Here, in the program it is .
Yes, and a little bit to tell, compare with all the hated, but ubiquitous jenkins and his Groovy DSL.
We must go, listen and find out what role Baruch's charisma played in the choice of technology.
None I abstract completely from this all. Everything will be honest, without flies.
I mean that in Tinkoff they took all these hipster technologies for a reason, TeamCity is not some kind of enterprise twenty years ago, as is customary in banks.
Tinkoff is the kind of bank that did it right from the start. Bank for hipsters from hipsters. Accordingly, the technology there is fresh and correct.
Guys, I really use TeamCity every day, and in the latest version it has become beautiful. TeamCity DSL has become available to use. See what the problem was before the latest version. In the previous version, if you switched to Kotlin DSL, you didn’t have the option to continue using the interface. As soon as you stepped over the line, the only way to write further was only on Kotlin.
Everything, you stepped on the Dark Side.
Yes, the documentation was at a minimum, and it was adok. Therefore, we tried and rolled back immediately to the XML configuration. In the latest version, when you switch to Kotlin DSL, you continue to use the web interface, and there it patches under the hood, patches these structures right in the repository. Then you can safely continue to write on Kotlin, if you have already mastered something somewhere. Those who have not yet dedicated, can continue to poke in the interface. This is great, guys!
This is the beneficial influence of Anton Arkhipov.
By the way, they mentioned all sorts of practices here. Do we have any reports that are not about tulling, but about processes, culture, and the human side?
Naturally. First, we have a great closing keynout of Sasha Titov and Kirill Tolkachev, in which they will discuss whether everything is bad in the devos or there is still hope.
It seems to me important to say that DevOops is probably at the moment almost the only professional conference organized by the JUG.ru Group in which it is allowed to talk about social things and process issues, moreover, at the official level.
To do this, we had to talk tightly with the leadership of the JUG.ru Group, but the result is obvious.
In addition to this excellent keyout, we also have a report from Dell EMC, there is also much about the processes there. This is about a team within a company that writes services for internal use. It's one thing to write this service, and another to start using it, because all people are busy, they have no time to master hipster technology. Accordingly, write a service, and then sell it within the company. Users will come to you, they will begin to have all sorts of non-standard needs, and now you have a dilemma - to develop the service so that many of them can use or satisfy this particular team. We are expecting a light there too.
There will be a description of a terrible two-year history, which is no longer as sick as it was at the beginning.
Baruch, do you also talk about social issues?
Lenya Igolnik and I have a report on how to start measuring correctly, this is all the ugliness that happens in our devops. Naturally, we have some metrics to which we bring with us from dev and which we do not use and have never used. We have metrics to which we bring with us from ops, with which it has always been much better. The question arises, what are the metrics devops? What does it mean? Is it easy to take those and take others, or is it something new, some new metrics? In short, data-driven devops .
Baruch, sometimes readers, visitors are indignant that comrades from the program committee read their reports, they consider this to be dishonest.
We really took it all to attention. At the very least, we are trying very hard to bring as many diverse speakers as possible, which are not only from the program committee. But at the same time, we still want to see some PC participants as speakers. For example, Alena Prokhorchik, Principal Engineer at Rancher Labs, who probably have the most experience in the world with multicloud Kubernetes deployments. I think everyone wants to hear about it, and she has something to tell.. As a program committee, we enjoy its expertise in evaluating reports. Probably, when the entire conference consists of speakers from the program committee, and each of them has five reports, this is really not good. But if we have a good speaker who wants to help the program committee, I honestly don’t understand why we have to choose one or the other.
Baruch, you work, plus you constantly travel with the reports, plus you work in the program committee. Do you have any life at all? How do you manage to do everything?
Volunteering for conferences JUG.ru Group is very nice, because it delivers a lot of pleasure - and besides, I learn new things. The reports of people who know much more than me are very useful.
Clear. Anyone want to add anything to our monologue with Baruch?
I often say that I have heard reports that no one will ever hear .
Yes, the program committee hears not only what then enters the conference. The competition was one to three. It can be said that this happened because there were many quite interesting among the applications. We recommended some of what we filtered to other conferences.
Were there any topics that you had to filter by quantity? Kubernetes, for example. Is there anything else?
Monitoring We had a battle for monitoring.
A bunch of reports. Everyone loves to monitor.
Who won in this King of the Mountains?
Alexey Kirpichnikov, the report “What we have learned while we made our own system of notification of abnormal situations” .
Is there something that I would like to have in the program, but there are no experts?
You took off the tongue. There is a reverse side of the coin, our favorite serverless, which seems to be under the HYIP, but no one who has a good understanding and practically applied all this, has not appeared. I hope at least one we pull out. But in general, there is little industrial experience in companies. Baruch, what about evangelical experts? Neither are they? Or just nobody came to us?
This whole story with visas spoiled the situation to us very much, including from developer advocates, who wanted to come and tell about serverless, specifically from Amazon, about lambdas. On visas, unfortunately, everything has died down.
And there were such reports in which you really learned something new for yourself, which was not there before? Or some breakthrough things that are remembered?
I, as one of the most non-technical people in the program committee, constantly find out a bunch of new things that I bring to my engineers, and they say, this is 101 that you brought to me. But not always!
Tatiana, you did not say anything, tell me what new things did you learn in the PC process?
Probably, from almost every report I found a lot of interesting things, which I did not hear. Sometimes less, sometimes more. From some reports, we took something good for ourselves. Especially the one that is associated with Ansible , which has already been mentioned. We also have Ansible, and we also started to cook it incorrectly. It is interesting to listen to the report of Oksana , because I work in a department that does something similar. But we have a slightly different orientation: as far as she understood, Oksana’s department deals with those who came to them and those whom business demands. Our department, on the contrary, is trying to process everyone who is in the company.
Actually, no, I work in the same department, we have it in the same positions. We are officially a large unit, which is entrusted to distribute these services, including in some places by force. We will talk about this at the conference.
Required.
And Borodin was discussed?
Not yet. Vladimir Borodin talks about the database in the clouds . By the way, on cloud technologies, this is probably the only report we have.
Report on stateful in the cloud, and it is such a game-game that no one can do.
Nobody wants to do this, because nobody wants to potentially lose data. And so the emergence of such a managed PostgreSQL in Russia ... Under the conditions that many services simply had to move to Russia some time ago to be allowed to work further - the appearance of such a service closes the last element of the puzzle. If there were a lot of clouds in Russia, then reliable storages that can be trusted are not easy to name.
Baruch, you always listen to something, tell. Tell me what struck you the most?
We started with this. I’m very interested in Kubernetes pacing the planet, I’m very interested in the docker's consumerization, these are very cool things. And, of course, I, too, as one of the less technically savvy and less hardcore-oriented representatives of the program committee, really tried so that we would not avoid the theme of culture and the correct construction of processes.
The time allocated for the meeting is rapidly approaching its end, and it is time to sum up. Can you wish something to those who are reading it now? Any final thoughts, any reports worth looking at first?
A very simple way to join the great is to hang on the live broadcast of the first hall. Naturally, the suitability will be not only in the first hall, respectively, it makes sense to look at other reports too. But it seems to me that the main difference between viewing reports (including broadcasting, no matter, free or paid) from the conference call is all that is happening between them. JUG.ru Group is famous for the activities that take place on the site outside the room where the report takes place. This is communication with the speakers in the discussion areas, and any meat that we have prepared after the closing of the conference. There we have a lot of interesting things. We will have round tables, discussion boughs (BOF). About such patient topics, for example, how devops differ from SRE. There are technical reports about security, but there is a much more global problem - what should we do about it, because, as I said, none of us are specialists, and we all have to do it. In addition, any fan, for example, will be a karaoke-battle in which everyone can participate, a geeky party - as expected, everyone will stand in the corners, drink and be silent :-)
All those present here will be able to meet or someone will not go?
Most likely, I definitely will not.
“Most likely, precisely, with high probability” - this is fine, I think.
Still saw this picture?
Yes, all these words vary depending on the culture of the country in which it is all pronounced. It's like that.
Interestingly, when it comes to, say, some guts of the Java Virtual Machine, the BOF turns into another report. Here, most likely, bos will be bofs in which everyone can participate and say something.
The point is not the JVM guts, but the fact that some speakers are absenting the bof format to make a report out of it. We, as a program committee, will do our utmost to prevent this from happening.
The idea is that devops are processes, and this is exactly what you need to grind on the sidelines. It seems to me that this should be directly emphasized.
All right, great remark. For DevOops conference, chatting on the sidelines is even more important than for all other conferences. I totally agree with you here. Just because here are the people + processes, the reports are much worse than the discussion zones, baffs and everything else.
It probably makes sense to emphasize this, because I looked at the same Artem Kalichkin on TechTrain, and the discussion area was comparable in intensity to the report itself.
I agree, I was also in this discussion area. There, after the report, maybe it was even more interesting than what he was broadcasting to the audience. But what he told on TechTrain, here we would not go down much. You have to understand that TechTrain’s audience was completely different. This is a new format for the JUG.ru Group, this is not a conference - this is a festival. There was a lot of mixed stuff there, it was very cool. I was there both days, and everything was very interesting and good. There were reports, but many of them were light, to a youth audience, in order to interest and provoke discussion.
It would make sense that the discussion can begin with a short report, and then the whole space of Expoforum is your “discussion zone” (if we speak in terms of our conferences).
Yes, it was. There were also light-reports in the zones next to the stands for literally twenty minutes, after which, too, I happened to witness a report about how a person wrote Bach chorals. We discussed it with him for half an hour - he was just unlucky that I was passing by.
Invite him to DevOops next time!
Rather, he should be invited to Joker, because he wrote to Java. And the man, by the way, from the wonderful company Leroy Merlin is an exceptional IT company.
They do a lot of things, they speak at many conferences and, probably, the next DevOops from there you can invite someone interesting. You know, every company is a software company, and for sure they are doing something interesting there.
Thank you all for the interview! We will repeatedly cross with us in the preparation of articles, but with our readers from Habr we will meet only on DevOops. Best regards, and see you soon!
DevOops Conference will be held October 14, 2018 in St. Petersburg. If suddenly you liked the program that we discussed here, then be sure to come. Tickets are on the link .