Do you use the DevOps approach at home? Here's the husband code deployed to work. Infrastructure wife prepares fried eggs, brews coffee, ironing shirts. The monitoring cat slips from under its feet in time, cleans its tray and loudly indicates when the wife deviates from the established protocol.
On the first day of Slurm DevOps, I met Artyom Galonsky, STO Bureau of the Bureau. He lectured on CI / CD and the introduction to automation. He talked about factory assembly line assembly and their application in IT. And at the same time he shared practical examples, such as building a “common” pipeline.
After the speech, I caught him on a coffee break and asked me to tell about the place of DevOps in his professional activity, and at the same time what requirements he sees for the post of DevOps engineer. Artyom dumbfounded me by stating that DevOps engineers exist in the same universe as pink unicorns. And for him, " there are no DevOps engineers, there are good admins who understand Kubernetes ."
You have been in development for 11 years. Started at Bureau Bureau?
No. He started as a freelancer in 2008, then picked up several startups. "Otfermery" was such a startup. It existed for 2 years and took shape. In 2011, he began to engage in CRM systems for an insurance agency. There was a small team - 4 people. In 11-12 he became a team leader. He was a leading developer, head of the development department of the company. In 2017, it became the STO company RedStart in Kaliningrad. And at the beginning of 2018, I moved to the Bureau of the Bureau.
What attracted you?
Next step. They offered interesting conditions. The opportunity to assemble your team. Plus interesting projects. I moved from Kaliningrad to Moscow. He worked in Moscow for six months. Then the directors of the Bureau of the Bureau and I decided that we should open a back office in Kaliningrad.
Why?
Firstly, I myself am from Kaliningrad. I know more high-quality and strong professionals in Kaliningrad than in Moscow. Maintenance of any needs is cheaper in Kaliningrad. And the IT community is strong there. And the free economic zone is slowly advancing.
We at Southbridge believe that the province’s potential has not yet been fully unleashed. That there is a huge number of talented and intelligent people who, for a number of reasons - psychological, social, financial - cannot move to the capital.
Yes, it’s not even psychological or what reasons ... People just don’t want to move.
Yes, I’m talking about this. Not everyone wants to move.
And this is not some kind of problem - psychological or financial. A person simply does not want to.
Yes. I agree. “Problem” is a bad word. Rather, "installation."
A person simply does not want to. He is comfortable there. I worked for six months in Moscow, collecting a team. It was difficult for me in the morning to spend 40 minutes on a trip to the subway. Or in traffic jams on the car even longer. I am now in Kaliningrad these forty minutes walking through picturesque places, past lakes, past beautiful houses. And these forty minutes I enjoy life. And breathe clean air. 20 minutes - and I'm at sea. 40 minutes - and I'm in Europe. Plus, many of the guys who live in Kaliningrad when they found out that I was returning, said, “ OK, come on, we will be happy to return to your team and continue to work with you .” And for a year now, our back office - development, testing, analytics, support managers - has been located in Kaliningrad. And we are happy and happy.
And in Moscow?
In Moscow, we have a front office. Management, project managers, director account, interface designers, designers and system administrators.
And how is the interaction?
Nothing interferes. Everything works almost perfectly. It all depends on how to configure.
You yourself, as a service station, whom do you prefer - remote employees or at the office?
The main thing is to establish the right exchange of knowledge. I omit Workflow - because if the workflow is not established, it does not matter how knowledge is exchanged. Nothing will work anyway. But the exchange of knowledge so that people share their practices - what they invented, understood, done - it is better inhouse when they are sitting in the same office. One way or another, they will begin to communicate on this topic. And when people are remotely, they may not share. Therefore, it is important to create a knowledge base. It is necessary to motivate people to share this information. Every Friday, technologicalization, that is, everyone who does not have a “burning” project, is engaged in self-education in the second half of Friday. And then it shares with others.
How do you motivate?
I motivate development. Frankly speaking, everything changes very quickly in the “web”, and if you do not develop, then you will remain at this level forever. And in terms of money you will not grow, and in terms of development.
One of my favorite quotes from Lewis Carroll from “Alice in Wonderland”: “Here you have to run as fast just to stay in the same place, but to get to another place you need to run twice as fast.”
We have almost the same. In the 11 years I have been involved in the web, technology has changed dramatically. Two years ago, relatively speaking, we did not know what Kubernetes is and how to implement it. Now it is everywhere. And in a year it will be necessary for everyone. Because the load will increase. If you do not pump knowledge and use it in your projects, then you will be left behind. Starting each project, we try to introduce something new. Working constantly on one product, it is quite difficult to introduce a new one. And it’s a little easier for us - starting a new project, we introduce new technologies that we have studied and tested. And we are developing from project to project.
What technologies do you use now, which do you consider relevant, necessary?
We have what we are doing now, the stack is quite simple - the react.js frontend, for the backend we used PHP partially before and now, now we are fully trying to switch to Go. This is such a straight line, where we are moving, to leave PHP completely on Go and to develop in it. This is a new, good, stable technology, which gives an excellent increase in speed - both in development and in the speed of the product itself. That is, our stack is React.js, PHP and Go. This is for programming languages. Well, as well as the standard technologies of Redis, PostgreSQL, RabbitMQ.
You can recall technologies that are already outdated. We recently talked with the guys - so they teased each other because they were once pros in Perl.
Yes. Well, probably someone else is using Perl. The same JS, which is constantly evolving ... What was before ES6 is deprecated, or the same jpl. The same js came to the “node” and became node.js. The same php, well, someone doesn’t like it - version 5 was bad, now 7.2 is developing under current trends. For me there is not one that is completely out of date. Morally, perhaps yes. Or I grow out of technology. Previously, 10 years ago I used MySQL, now for the projects that I am laying down, it is useless almost everywhere. The technologies that I had ... Most likely, I just grew out of them than they were outdated.
What do you like about Go now?
Speed ​​of execution, saving. To everyone. What I see, communicating with my architects, leads and developers, let's just say that what we are used to seeing in script php, it remains in Go plus the features of compiled languages ​​are added. Goroutines, multichannel. That which was not in php, and we did it through php-fpm, relatively speaking. Plus strong data typing. And also a quick compilation of the binary itself.
What is a good developer for you?
For me, a good developer is someone who can switch to a new programming language somewhere in 2-3 months to understand it. Naturally, he will not do anything for 2-3 months. He will be at the stage of "June", do simple tasks. Quickly pumped - and begins to close complex, good tasks.
Which company do you relate to - orange, turquoise?
We are not turquoise for sure. Rather orange. With vertical control. I myself am a little authoritarian in management. We do this and that - and if they don’t come to me and prove with obvious examples that it’s better in another way, it will be very difficult to convince me. If not proven, then this is not necessary. Suppose an employee comes and says: “Artyom, we need to do this. For this and this reason. You suggested a bad idea. Yes, you are the director and architect. But you did not come up with a very good idea. And you need to do this. ”And if they have not clearly and 100% proved to me, then I will push through my decision. So not turquoise for sure.
Say, relatively speaking, a new technology has appeared. And how can an employee prove to you that it is worth using if few people still use it and there are no representative examples and practical cases? But the technology is supposedly promising.
Show pet project. Well, not just: “ Look, that's what I did .” This should be already put together. In order for a person to consciously do this, he tried to put it on production, to give him a load. He came to me and said: “ I found such a feature, language, technology. I created a small completed product or microservice . " Then I listen. There is still a problem - when working with a serious business, established technologies are needed. We can go forward and move. And our customers - they are sometimes monstrous, due to the fact that they are very large, especially state ones - they are ready only for stable technologies and do not like experiments. I remember, two years ago, I suggested react.js to someone - and the sharp answer is “ No. We will not work. What for? This is some kind of library for UI. No. Html, Css, Js - it suits us. " In large corporations, state structures it turns out that the development of new technologies is a bit late. As long as the technology is not stabilized, until they find a person who knows this technology and supports it from the inside, they will not risk it.
When is it easy for you to work with a customer?
I think when there is a good architect on the customer side. Then it becomes interesting to work. Then we get a good order, good tasks, and good solutions. And they understand how this will be implemented. And when at the customer’s place there is only management and a product analyst who want something like this, then it’s more difficult. The systems are very large. And we deliver a product that will be part of the system. And they tell us: “ Oh, and connect these two products together. So that the user clicks on this button and he has this… ”And there is a lot under the hood - authorization, data transfer. And you ask: “ Guys, okay, how should it happen inside? What exactly do you want? "And they answered:" Oh, we don’t know. The main thing is that everything should be beautiful. And what's under the hood - you tell our information security. Let them check whether it works well or not . ”
Can you recall an example when you quickly and originally solved a problem?
We have projects in which authorization is only by ESIA. And ESIA often lies down. When a person logs in, we verify that it is he who logged in. And there is a reconciliation of data from the ESIA that his passport or other documents have not been updated. And then ESIA messed up something. And we have a group of customers who tried to log in, received the message “ Your data has changed. Please confirm . " ESIA began issuing new first name or middle name or new passport data. And we cannot do anything, because our system is so tuned that ESIA is the center of truth for us. And we stopped authorization for a while. ESIA quickly decided everything. Our admins at the level of the user balancer have thrown to the page " Sorry, temporarily does not work ." And we quickly finished it so that only old customers could log in without updates temporarily. And new users were not allowed. Well, this is not really our situation, but we connected there for a solution.
Tell me, what was the most interesting challenge project for you lately? What did you get professional pleasure from?
A: I enjoyed it ... We did a personal account for Siemens Finance. A subsidiary of Siemens, which is engaged in leasing in Russia. Together with them we developed a personal account. Here the pleasure is that Siemens gave us the opportunity to build a good architecture, the customer did not intervene, and broadcasted “ Guys, we trust you .” We made a good UI and UX for them. Very nice work with the customer. And that was not a challenge or overcoming. Then I really enjoyed the work. From the product that is ultimately received. And now the product works, lives. Everyone likes him - and I like him. And so the challenges we have are constantly. When working with large companies without this in any way. Each company has 12 departments - there is an IT department, there is an infrastructure department, a business logic department, and something else. Plus there are a bunch of vendors, people like you who integrate their CRM. And to coordinate any changes with all these departments is a challenge. You offer your architecture, communicate with the architect of the main company, interact with vendor architects ...
But shouldn't the architect of the customer company deal with this?
Not always. There is such a fashionable topic - digital transformation. For example, the company has an architect, and he was directly involved in the architecture of his solution. For example, billing or banking. But he, as the architect of the entire system, does not have the necessary experience and competence. But a good specialist begins to learn. And who is not very or already in age, here is a little more complicated - because they are poorly watching the new trends. And you have to communicate for a long time and explain, they say, guys, let's try this progressive solution. And somewhere there are young architects who grew up on the modern "web". It’s quite simple there - conditionally, we synchronize like this, connect these modules like that. And they quickly and competently resolve.
So you already see two different generations of developers?
On the web, yes. Because now everything is moving to the web. Now even internal systems are gradually moving into microservices that communicate by API. And the API is most often http and https. Architects must understand how this works. And the easiest way to listen to those who worked on the web. In my opinion. Very often this situation occurs. The customer wants a new cool site. He sees which site a competitor has, how this site works. And he comes, demands that we establish the entire digital history of the site, right up to CRM. And we only deal with the site. We are ready to integrate with someone else's CRM. And it turns out that we become a driver of changes for a particular company.
Digital transformation - how much do you think it is needed?
Like any hype theme, it is fashionable and necessary. We have a very large number of orders to make an excel download. An incredible number of companies work in Excel. And they need to make sure that this "excel" is loaded, parsed, turned into a database and then you can work with it, and then unload it. Digital transformation should lead to the transition to normal work systems - CRM, content systems, CMS. And abandon excel and live in a normal web-world. There is such a good example. In the previous company, where I worked before Bureau-Bureau, we had two client companies. And we were able to track in detail how everything happens. In one company, customer service went through Excel. There was a large database. It was 2012-2013 year. Normal CRM wasn’t suitable there - a lot of workflow and it took a very long time to configure it on ordinary CRM. And one company went to work at Excel. And the second spent half a year - and wrote her CRM. As a result, the first company six months after they reached the peak of sales, and they began working with customers - they collapsed. It’s just that their call service was not able to provide a good and fast service. And the second company with its CRM, on the contrary, quickly tracked with one button, what kind of client, how he got to them, what managers answered him. They survived this peak of growth - and are still working. Electronic document management is also a trend. Time saving. Who operates faster with information, he earns faster. So in everything. If there is no good monitoring and no good logging on the project, then the engineers will not be able to quickly understand what the problem is. And the survival and success of the business really depends on it now. So it’s necessary not only to fuck a beautiful website, but to build the right website and the right logging system. Digital transformation is needed. It is necessary to keep up to date. If there are such technologies, we must try to introduce them.
What technologies do you see now that will be promising in the near future? For example, two years ago Kubernetes was considered promising. Now it is simply necessary.
The future is machine learning and AI. In five years it will become relevant. A year ago, there was crypto and there was machine learning on hype. Now everything is quiet. But still, in the next five years, machine learning will shoot, as I think. Work is underway - experience and solutions are accumulating.
It is believed that with machine learning and artificial intelligence, many professions will simply disappear. This applies to both teachers and economists. And lawyers say that blockchain technology will move certain areas in jurisprudence. What professions in IT, as you see, will disappear?
Covers, as I think, will disappear. It seems to me in the next three years. As the saying goes, remember this tweet. (laughs) Most likely, machine learning will be written soon, which will be good layout. They’ll come up with something. And then, probably, programmers of simple systems will disappear. But still, there will always be programmers who will design and program the microchip core. There will always be programmers.
Now on the market there is a certain shortage of DevOps engineers ...
Listen, I am categorically against such a thing as a DevOps engineer.
Why?
DevOps is a practice, it is a philosophy. DevOps engineer - who is it? Is it a pumped admin or is it a well-pumped "backend" that can be in the admin? There are no DevOps engineers for me, for me there are good admins who understand Kubernetes. But Kubernetes are not DevOps. The only thing I accept for myself is the DevOps evangelist. Who can come to the company and say: “ Guys, we need to move in this direction. Learn to communicate and interact . ” Because DevOps is not about technology. In general, the whole philosophy of DevOps is about interaction. To learn how to communicate, development and QA, and further support. And all these DevOps engineers remind me of hype by scrum-masters about three years ago. Everyone needed scrum-masters, no one could work without them. Or five years ago, everyone urgently needed a Jira setup manager. And if there is no person who sets up a “jira” for us, then the work will not move. And all that with the DevOps prefix is ​​just to increase your value in the labor market.
That is, you think that a year or two and fashion will subside?
Well, the hype will leave. But people will begin to pump. Again, what is Slurm for? People are pumping, people will understand what a “cuber” is, where it is needed and where it is not needed. They will understand what pipelines are. What I talked about yesterday at Slurm DevOps. I just don't know what a DevOps engineer is. For me it does not exist. Everything else is pure hype. In two years, there will simply be an admin with knowledge of Kubernetes.
What deficit do you see in the coming years, which IT professions?
The shortage will be for programmers of all levels. Programmers will definitely be missed. Universities graduate very few people. And now everyone will need them. As in the early 90's, admins were needed.
If you select employees, do you look closely at where they studied?
In this regard, I feel a little easier. I am in Kaliningrad. I realized that the Kant BFU is excellent at cooking. I have about sixty percent of the guys out there. And they are at a very good level - about analytical knowledge, analytical and logical thinking. They may come a little raw, like programmers. But after a certain time, giving them serious tasks, giving them serious loads, they grow. Just time tested for me. But in fact, I am not a supporter of test tasks. We hire a person and see how he will work. On a test assignment, in an interview, a person could get worried. And in the first week, in the first month, we see what it costs. And whether he has a higher education or not has a higher education - this is absolutely uncritical.
An interesting conversation turned out. Telephone operator, chariot worker, calculator, water carrier, human alarm clock - we can hardly understand what these professions were, just guess by the name. And soon, after them, dozens of others will stand in line for extinction. Layout designer, entry-level programmer, proofreader, statistician, accountant, build editor. And there will be hundreds of new ones, some of which we do not even suspect. Can everyone not get lost at such a rapid pace of technology development and find their place? “Time will tell. Sooner or later time will tell. "©