The inevitable changes that happened to DevOps with the onset of the pandemic have become an occasion for discussions by specialists of new standards and requirements in this professional field. Naturally, *instinctools, as part of its Techtime project, could not ignore this hot topic and gathered experts from different companies to talk about how the work of specialists in DevOps has changed, what new requirements for newcomers and their subsequent growth have appeared. We have collected the statements of experts that were heard in the discussion in this text.
The conversation was attended by Head of DevOps Advocacy, Developer Advocate, JFrog, DevOpsSpeakeas podcast host Baruch Sadogursky, Head of SRE, Flocktory Dmitry Zaitsev, Senior Security Architect, Microsoft Victoria Almazova and Systems Architect Viktor Vedmich.
The need for automation has come to the fore
The need for automation came to the fore. It became such a pain that it pushed the development of the technical part, which is related to DevOps. According to our observations, everything has changed a lot, since it has become more painful and harder to do work with hands. As in the literal sense – this is to go and “kick” the server, and as for access to all sorts of environments that are less accessible remotely. This all led to the fact that people began to care more about automating everything that is possible.
Baruch Sadogursky:
I had a case when a customer deployed to production only from the office. And the guys who worked in the local office came to the office on Saturday just to deploy to production. During the pandemic, they were forced to make remote access to production.
Viktor Vedmich:
One option is to make remote access to production, the second is to stop deploying by hand. This is the incentive to work on automation, the pipeline, and everything that is the technical part of DevOps.
Baruch Sadogursky:
Automation requires an increase in the level of knowledge of security officers
A lot of security people are used to working in the “perimeter”. And of course, there was a demand for security. But it turned out that security guards need to be done somehow differently. And this, in turn, requires automation skills and an increase in the level of knowledge of the security guards, who have been sitting in the “perimeter” for 15-20 years. And they simply do not have this knowledge, so we see different situations – either we open everything, or we install VPN and other solutions that do not work. There is also a security overhaul approach, but it takes more people to overhaul security.
Victoria Almazova:
The demand for new security solutions has emerged, increased and will continue to grow. Now we are working remotely, and this is a different kind of access and resilience. And if we start to open access, then this causes more interest on the part of the initiators of hacker attacks. And another moment. In order to contain a security policy, to configure firewalls, you need fewer resources to provide protection than would be required for process automation.
You need to know related areas
In my experience, some of the best security guards in DevOps today are people with developer backgrounds and paranoia. Knowledge of related areas helps to understand the essence of tasks and problems. For example, if an employee used to sit on “paper” security and suddenly he needs to help the developer, then he will not be able to look at the task from his point of view.
Victoria Almazova:
The problem is not that he will start helping, but that he will not be able to help. Security guards who come from the law rather than technology have a completely different mindset. Everything is very difficult with them in terms of any changes towards DevOps.
Baruch Sadogursky:
Using AI to automate DevOps is not always possible
Good developers and engineers simplify business tasks to technological tasks. And this editing process is the most difficult cognitive task. If it was easy, everyone would do it. AI is wildly far away from this. With other tasks, such as understanding the context and making the right decision, it copes much easier. That is why it seems to me that AI is going there and it is already getting better and better at it. But in the matter of reducing business tasks to a technical abstraction, a person is needed.
Baruch Sadogursky:
In my understanding, business is a bit of creativity. And as we know, AI is very bad at creativity. Everyone says that AI is aimed at automating tasks that are not interesting to a person and do not require a lot of abstraction and creativity.
Victoria Almazova:
Business automation is not a DevOps issue, let start-ups and other entrepreneurs deal with it. We are engaged in the reduction of business tasks to technical tasks.
Baruch Sadogursky:
There are fewer and fewer cool senior engineers in DevOps
We have AI development solutions, like Copilot, and we’re starting to use all this magic. But there is no fundamental knowledge. I see that there are fewer and fewer cool senior engineers who do not just understand the tools, but have fundamental knowledge.
Victor Vedimich:
I’m starting to get scared by the fact that people know the tools but don’t know the concepts behind them. Let’s look at the question from a historical point of view. If we look at the same containers, rewind a couple of decades back and remember Linux and FreeBSD, there were also jails, there was also a chroot. Tell a modern person what jails are, what chroots are – and he will reflect. Everyone knows what a container is. I worked with Amazon Cloud and now work with Azure and I can say that knowing the concept helps to learn new tools very quickly. It’s just like with languages: you will learn the first three languages and the fourth will be very easy for you, because you know the constructions and the concept. And we are going to start outsourcing everything. Doesn’t that make us very weak people?
Victoria Almazova:
No, it doesn’t. We have a deep specialization in complex things. And we have an understanding. In the US, during the pandemic, 10% of residents went to apply for unemployment benefits, and the old systems written in Cobol fell through. And there was a trend to search for a Cobol programming specialist for any money. After all, it was necessary to repair the systems. But this trend lasted two months, and now all systems are rewritten, for example in Java. Yes, we read in the news that they are looking for Cobol programmers, we laughed, but this does not mean that Cobol will continue to be used. One incident with a system crash and the search for a specialist is enough to rewrite the system in another language in the future. Learning is easier when you’re 17, not when you already have a family and a cat
Baruch Sadogursky:
If you plan to grow, then it would be good to invest in a base. It seems that investing in knowledge is easier when you are 17 years old, and not when you already have a family and a cat.
Dmitry Zaitsev:
I do not urge to study the entire history of IT and know where Linux came from. I am for the knowledge of the concept, the basis. At the age of 17, I invested a couple of nights to understand the concept. And now these investments are paying off, I learn tools very quickly. A new product comes out, but it’s still the same “egg”, only in a different color. Yes, with new features, with automation, but learning this functionality is much faster. For example, with regard to security tools, today specialists very often have an idea about them only in terms of where to click with the mouse and what command to write. This is when compared with those who come and start learning some instrument from scratch. People simply do not have an understanding of how the tool works, they have a panic attack immediately when the tool doesn’t behave as described in the documentation. Based on my experience, I will say that understanding the basis allows you to save time on learning. If I started from scratch now and went to work as a DevOps engineer, then I would have a reasonable question – where to start, where to look? Lots of tools and directions. Even Amazon or Azure is 600+ services. This does not give rise to enthusiasm, dazzled and it is not clear where to start working DevOps in order to learn and be in trend.
Victoria Almazova:
I would advise beginners to go to a company where there is an internship. As a rule, these are large outsourcing companies or banks. But after the internship, you need to remember to “go” to a technology company that can do projects well and quickly.
Dmitry Zaitsev:
Beginners must have knowledge of Linux
We have a lot of good resources for DevOps beginners. Cloud providers are interested in newcomers to DevOps, and they have good resources to get started. Their solutions are very user friendly and a pleasure to use and start with. Yes, some Linux solutions will be needed, but a little knowledge is enough – and it can be used. But you need to start with cloud solutions.
Baruch Sadogursky:
We often look for systems engineers and interview a lot of people. And I see that beginners should have knowledge of Linux, knowledge of at least the minimum Yandex Kit course on networks and the ability to write in Bash, Python and Go. Clouds are definitely a good option. Providers will teach you how to make systems better. But in order to start the server, you need to give it user-data, and this is a bash script. And someone needs to write it and know what you are writing. Well, Linux is a key element. Everything else is easy to learn, and understanding what to take in the cloud to solve some problem is secondary. You can contact the technical support of the provider, and they will explain how to solve your problem, even with excessive knowledge.
Dmitry Zaitsev:
Any security needs a periodic audit
If I were asked about the best tools in the framework of the basic security approach for DevOps, then I would advise you to focus on the sisd pipeline with the implementation of tools there as package management scanning. Further, I would recommend using Sast (static security analysis) and Dust (dynamic security analysis). It is mandatory to focus on what packages and libraries we use in the code. These are all first party and open source, and it is better to use security tools that scan them. And not only for security, but also for a license. We often forget that some open-source libraries have a habit of changing licenses. And, accordingly, SaS tools will also help track these changes and scan the code for security and vulnerabilities. Dust-Tools is a light version of Pentest. The CI/CD pipeline is the heart of security and quality. It is necessary not only to think about what to put in the pipeline, but also about what rights the pipeline has itself and where, as well as who has the right to edit and run our pipeline.
Victoria Almazova:
Any security needs a periodic audit. In my understanding, in addition to the necessary new checks that are added to the pipeline, there must also be people who generate additional checks. An analogy with QA suggests itself, where, despite the fact that we have automated all the tests, we still have exploratory testing. People find where it can break and what needs to be tested. It seems to me that pen testers are about the same in the security paradigm.
Baruch Sadogursky:
