Danila Migalin (@miga) lives in Vilnius and works as an engineer at Uber.
A long time ago, the office that was engaged in the Russification of games did not take him to work as a translator. The next day he got a job as an administrator, because at school he was fond of programming. “Russian IT is a big village, the same people move from company to company. Before Uber, I managed to work at Yandex and Microsoft, ”says Danila.
Since 2006, he has been involved in IP telephony and admin work. In his free time he wrote in Pearl, then in Python, did his own pet projects. Some of them even went into production at both Yandex and Microsoft. It wasn’t until he joined Uber that he started writing seriously in production. “The place I was offered at the company assumed knowledge of Golang. I was not embarrassed by the fact that I was going to the position of a developer as an administrator. I thought: great, finally it will be possible to tie up with the admin business and calmly write the code. “
We talked with Danila, and he told why there is no division into devops and ops at Uber, whether it is difficult to master development if you have been an admin all your life – and why Golang has become the standard in the field of Devops.
Is it difficult for an administrator to become a developer, and a developer – an administrator
– Here you are in a world where devops program no less than developers.
“Now we are all called Software Engineers and we write code every day. At Microsoft we were called Service Engineer (no longer Operations, but not yet Software Engineer) and we were doing devop work. We wrote to developers different automation for deployment.
Now in my environment there are practically no devops left. At Uber, we don’t have Ops or Devs. All engineers write, deploy and customize their product inside and out. Teams are responsible for the entire product lifecycle. There are no more evil admin uncles or kinder devops uncles who will do something for you, deploy, monitor. And I love it.
The good thing about this system is that there is no dilution of responsibility. There is a product, the team writes it. The same team is responsible for making it work. If something is broken, you know that either your colleague or yourself is to blame. Has the product you are using broken? You can go to the guys and clarify everything. They know how it is written, they can fix it. Earlier, you come to the admin who is oncolite with his problem – he will shrug his shoulders, say about the error in the logs, redirect to the guys who will be there only in the morning.
It’s good for a product when people know that they will get up at night if something flies. The team begins to approach development more seriously: sooner or later all the cut corners will end up in your pants.
– I opened vacancies for the backend and realized that now the backend is not just coding and a database. These are coding, database and devops. How can you stuff so much knowledge into one head?
– Computers and services are getting more complex. The demands on developers naturally rise. I think this is normal. When Yandex switched from the classic “admin and developer” model to devops, and programmers started to be put in oncol, many people left. They really didn’t like it! They were hired to write code, and everything else burned like a blue flame.
There were no shifts in Yandex, we had the concept of “responsible for the service”. This person was supposed to be available 24/7/365. In those days, I really went everywhere with a laptop and a power bank. In any wilderness, I was fully armed.
It’s cool that Uber is on duty, as they say, follow the sun. When it’s night with us, the guys on the other side of the ocean are on duty. We have a day left. Before that, we were on duty around the clock. We had projects that we did in Vilnius and there were projects from San Francisco. We oncalled for our projects 24/7 and the guys from San Francisco oncalled for their projects 24/7. Then they held a series of webinars, told what was what to each other and started talking in the daytime for their own and for the American, and they “with their” day – for theirs and for Vilnius.
– Many people want to work as devops, but not everyone is ready for night shifts.
– If being on duty a couple of times a week is not a problem for you, then this is your competitive advantage. Not ready? Okay, there are many companies on the market that will provide you with other jobs. But for me it is better when you are responsible. It’s more difficult, you should know more, but this knowledge still fits into one head. It’s not such a hell of a rocket science.
Plus, adult products don’t just break down. With streamlined processes, the rotation of oncolers becomes calmer. You know – all alerts have been studied. That’s when you came to a startup with a young, unsettled system that falls every hour, and everything is on fire, and you are on fire … Mom dear, will I spend so much money on doctors? I’ll go find something simpler.
Either you come to a wild startup as a firefighter, or you go to a cool, well-dressed enterprise and run smoothies there.
– It seems to programmers that devops is a dark forest and a completely different set of skill set. If you want to learn, you will have to start a lot from scratch.
– To function normally at the full stack level, not to depend on the admin, you don’t need much knowledge. In practice, this is comprehended in six months without much effort. Administering is not a great science. But this is just the tip of the iceberg. There is also a very large amount of direct system knowledge, a basic understanding of how computers work. Secret admin stuff that isn’t taught in universities.
I recommend everyone to read Tanenbaum’s thin book “Modern Operating Systems”. The book is old, but still relevant. Written in an interesting, artistic language. I read it, and now you already know the computer quite well.
Most importantly, you need to accustom yourself to responsibility. Your program is not code that you wrote and forgot, it is code that runs somewhere safe and beautiful. Understanding this would simplify a lot in the industry.
– Developed – these are people without any responsibility. There are bugs in the code – the testers are to blame if the product crashed – the devops is to blame. Everyone is to blame, and you are lounging in bed.
– It has always been that way.
– There is a trend for changes, developers are gradually being taught.
Now you can’t find a backend job without a docker. Okay, does it work the other way? You haven’t done product development in the conveyor sense. It was difficult to?
– I did not experience any particular difficulties. I will not say anything about knowledge of algorithms for data structures and other computer science, but to be able to express your thoughts in a programming language and be able to find an algorithm is necessary knowledge. And I had it.
I interviewed people, good powerful admins from well-known companies. And often they did not have the skill of solving some problems using programming.
I remember one social security program with the administrator of a large Russian technology company. I asked him a simple problem, most likely to make a rate limiter, and noticed that the guy was in a stupor. He just didn’t know which side to approach. And in terms of system knowledge, he answered well. Somehow the task was finished. Then I defended him, offered to take him at least as a middle. For 10 years of practice, a person somehow mysteriously managed to avoid programming. It is easy to train, given that you will have tasks, there will be people nearby who will be able to mentor you. This is not such a great science in comparison with the huge layer of knowledge that he received during his administration.
– Look at this case right away. Your name is to make an interesting project. You need to build everything in Java, and also manage javists! Would you take it, believe in yourself, could you learn the language?
– It seems to me that there is no particular problem in learning +1 programming language. I wouldn’t be intimidated by Java.
Why Golang Became the Standard in Devops
– There is a June disease, when you learn one language and it is very difficult to decide on something else. A mature developer works with any stack.
– When switching from Python to Golang, I was not afraid. Golang is a thousand, a billion times easier than Python. You can literally open http://tur.golang.org/, go through it in a day and write to production in the morning. I’m not kidding, it really is.
But there is one “but”. Golang is very simple and therefore not expressive. Personally, it annoys me.
– I know guys who switch from Java to Scala, then to Haskell, then to Idris, and still they lack expressiveness.
– Yes, I am constantly suffering. I write the code and think, damn it, I’m doing nonsense! If it were Erlang, I would use pattern matching, everything would be nice and nice. With Golang, no aesthetic pleasure. It’s not about elegance. It is in Python that you can write some kind of comprehension and, leaning back in your chair, admire it for 5 minutes: how cleverly it turned out. There are few opportunities to show at least some kind of creative streak. I am sure that the clumsy Go was one of the goals of creating the language, so that Google guys, this whole army of programmers, would not be involved in creativity, but would simply write clear and reliable code.
– Do you also do development and automation of devops on Golang?
– Yes, specifically in our architecture there is no such division. It’s all a service. It’s just that one serves user traffic, the other orchestrates containers.
My team is engaged in database automation. We provide databases as a service inside Uber. We have our own orchestrator for this. As kubernetes, only clean up! We write this orchestrator every day. We write it on Golang.
There is one difficulty in Go that you can really get into – this is working with memory. On this occasion, there is a separate article on the documentation page, and there is one short paragraph on how to do it so that everything is correct.
And then comes a sentence that I really like: “If you need to read this documentation further, then you are too smart! You are doing something too smart. ” So it is written in English.
– I often have a problem: I need to make a decision that I really don’t want to make, it hasn’t become a problem yet, but I already need to act. If the decision takes the tongue – it’s great.
– You noticed well, Golang is very opinionated. It is made with such a tough vision. You name the variables, align the text, organize the interaction between threads and that’s it. You can forget about the rest. This is good at reducing cognitive load.
– It seems to me that this is why he stopped by the Devops. Programmers love solving problems like figuring out how to format their code. And if a person needs a script that automates a simple thing, he doesn’t want to think about how to collect, pack, format, and so on. If someone outside the industry asks you about your profession, what will you answer? Developer, devops or admin?
– I think a person outside the industry has no idea who a devops is. I’ll say a programmer. That’s what I say. Everyone understands this.
Join the our community in the cart – very cool engineers there regularly share their experience, analyze various problems and tasks from the Devops sphere, and also tell things that will be useful both in interviews and in work.