According to the definition, DevOps (DEVelopment and OPerationS) is a set of practices - in literature often referred to as a culture - that combines software development and IT operations. To a large extent, this methodology puts emphasis on close cooperation and communication between IT maintenance specialists (e.g. administrators) and those responsible for software development (programmers and testers).
Sławomir Sendor - a Senior Software Engineer / DevOps at Comarch Healthcare tells us about how DevOps works, which technologies are useful and why automation is important in this culture.
Let’s start with your definition of DevOps. What is it in your opinion?
In the simplest terms, DevOps is a methodology of software delivery that combines its production and maintenance in one consistent process.
What is then the main advantage of introducing the DevOps approach to business and development?
The DevOps approach allows us to significantly reduce the time necessary to deliver new functionalities as well as to improve the product quality.
Let’s suppose that I am about to introduce the DevOps in my company. What practices should I apply at the beginning?
The DevOps approach is inseparably related to the automation of the whole process: testing, static code analysis, new version release, implementation and monitoring. A well-automated process will oblige your team to use good practices, it will reduce errors occurrence and improve efficiency.
What is the role of communication in this approach?
Communication is very important because the team needs to receive feedback on the product they’ve created. Such feedback can come from clients, analysts, or the monitoring system. Automation allows fast delivery cycles, which result in quick feedback and consequently - fast corrections/modifications. These corrections concern not only the product itself but also the production process. Why? If there is an error in the production environment, it means that the process did not fulfill its protective role.
Putting together the Dev and Ops competences in one team improves communication. It's always faster and easier to communicate within the same team than between two individuals coming from completely different areas.
Is it necessary for a person working with the DevOps methodology to have certain skills or aptitudes?
Without any doubt, in order to implement the DevOps approach, you need to be well familiar with both aspects: development and operations. On one hand, you’ll need to know about the technologies used for creating applications, and on the other hand - have a good knowledge of implementation environments and how to work with them. Last but not least, you need to be a fast learner and have good problem-solving skills.
What technologies and what tools are used for DevOps? How important is CI/CD/CD?
We start with software development, so we must have a programming language in which we will code the application, and scripts that can build and test it, and release a test version for implementation. Currently, Docker is the standard implementation format. Once we have the image ready, we’ll need the right tools/scripts again. It can be the usual Bash or Python, or Ansible for example. You also need an environment on which to implement your application. It can be a regular virtual machine or a k8s cluster. Once a version is implemented, it needs testing. An example of popular testing technology for a rest API is JMeter. During the tests, we monitor the application: we check how it behaves in a real environment, e.g. using Prometheus and Grafana, and we verify the logs, e.g. the ELK / EFK stack processes.
We also need something that will act as an automation engine, i.e. make these next steps of the process run. Most popular solutions are Jenkins, or the built-in GitLab-ci.
The entire process described above is called CICD. Whether we use Continuous Integration (CI), Continuous Delivery (CD) or Continuous Deployment (CD) is largely a business decision.
How does this philosophy fit in improving software quality?
As I’ve mentioned, an automated process forces you to improve your quality all the time. When it’s a machine that stands guard and verifies every single commit that tries to enter the master, there is no way around. You simply must meet the required criteria.
DevOps is not only a technology but also a work culture. How do you introduce the DevOps culture at Comarch?
We introduce the DevOps culture by collecting the Dev and Ops competences in each team. Every team is responsible for their service from start to finish. This approach helps avoid the endless shifting of responsibilities between different teams.
Given that, is a DevOps engineer more of an administrator or a programmer?
In my opinion, a DevOps engineer is a programmer rather than an administrator. Remember, we want the code to include everything: apps, scripts, processes and infrastructure. Knowing how to code is absolutely necessary.
There’s been a lot of talk about automation. Why is this issue so important?
Automation is important for several reasons. First, you can’t obtain decent quality and repeatability without it. Machines are perfect and tireless for repetitive tasks, while people are completely unfit for this. When done by a human, practically every repetition of an activity will be a little different. People are slower than machines and they get bored and tired quickly. And when they do - human errors tend to occur. Second, if everything is automated, the team can fully focus on building the product. Last but not least, being able to work efficiently and waste no time on repetitive and boring tasks increases the team’s well-being.
DevOps methodology is often said to only make sense in large organizations
I disagree. We’ve been using the DevOps approach for several years in different-size teams. The effects are indisputable. I’d say DevOps works even better in small teams, where the time of every single person is priceless.
What’s the labor market for DevOps specialists and which way will the DevOps philosophy go in the future?
Nowadays, more and more companies take up the DevOps approach knowing that without it they will lose effectivity and in the long-term: risk their business feasibility. Given that, there are plenty of job offers for experienced DevOps engineers.
In my opinion, DevOps philosophy will aim at a further merger of Dev and Ops competences, as well as QA, UX or InfoSec competences, within a single team. In terms of technology, I expect further adoption of the IaC and the Cloud - whether private or public.
To finish with, I would like you to give us a few suggestions of materials that young DevOps engineers could use to learn more about this methodology.
If you want to learn more, the best way is to observe your more experienced colleagues. There is no better way to learn than practice. The Internet is a huge source of information too. Those who don’t seem to grasp the DevOps philosophy completely should definitely read the book „The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations”.