A new spell called DevOps has appeared in IT. After ITIL, Agil, ISO, Security, ServiceDesk, SLA ... we still need DevOps. Why? Because DevOps is being talked about, the competition boasts that DevOps is introducing, or already has in place, customers are threatening that if we don't have DevOps, they don't want us. Is DevOps a new fashion or a useful "tool" for IT? And "what" is DevOps actually?
Certified lecturer Ludmila Vráželová will try to answer so that you can form your own opinion and decide whether DevOps practices could be useful for you, or you should skip them. Please note in advance that the article is intended for beginners and in order to maintain clarity and digestibility, the whole topic is very simplified and slightly lightened.
A set of practices and tools used in IT, especially to dramatically speed up IT operations. Dramatic in the sense I have an acceleration from releases once every six months to releases 10 times a day. Suppose you are a bank or manufacturing company and employees who need IT services such as e-mail, WIFI, SAP, reports and more, instead of waiting for a change or new functionality for half a year, they will get it on the same day they asked her. Utopia? Not with DevOps. DevOps uses a set of practices and tools that remove barriers to delivery speed. We can divide them into 3 areas - automation, agile control and culture ("soft factors").
I'm sure you'll agree with me that automation is accelerating dramatically. If you walk from Prague to Brno, it will take you 44 hours (measured in Google navigation). If you drive, it will take you over 2 hours. When you make paper by hand, I don't know how long it will take you, but compared to an industrial line, for a very long time. The same principle applies in IT, both in development and in operation. The more activities you perform manually, the longer it will take you.
DevOps includes tools that can automate the entire process from development to operation, from the moment the developer writes the code, or even from the assignment for development, to the moment when the code appears on production and the customer can use it. These tools can automate the operation, ie maintenance, administration, monitoring and correction of errors in operation. Practices called "uninterrupted delivery", "infrastructure as code", "containerization", "cloud" and others are used. Of the tools, I will list Docker, AWS, Git, Puppet, Chef for all of them.
Automation alone will greatly help acceleration, but it is not enough. In order for the customer to get new functionality on the same day, you have to develop so-called "agile", which is the opposite of "linear" or waterfall deliveries, where we first collect all change requests, analyze them, design solutions, program and deliver them to operation. Agile delivery means collecting only part of the requirements and processing them immediately and delivering them to operation, so that the customer can use them immediately. The SCRUM methodology is most often used for agile deliveries. You can learn more about the SCRUM methodology in trainings.
You have automated, you develop agile, but this in itself is not enough. If you do not have a properly set up corporate culture in IT, or mindset - the thinking and approach of every IT, but also many non-IT employees, you will not achieve dramatic acceleration. Why? Imagine a situation where a customer comes to IT that needs a new report. Because you already have agile control and automation, you are able to technically deliver the report within an hour. JUST the data requires data from various departments and consultations with these departments are required for them. The management of several departments will refuse to provide you with information, officially for data protection reasons, unofficially, because the information means "power" and they would have to give it up. Others refuse the consultation, stating that some information about their functioning does not get out and that some problems may be encountered. These are attitudes, beliefs, and behaviors that are typically part of a company's corporate culture and conflict with DevOps. And this is just a small example, there are many different attitudes and behaviors that conflict with DevOps and often significantly slow delivery. DevOps defines what attitudes, beliefs and behaviors of specialists and management need to be set in order for dramatic acceleration to occur.
So how do you like DevOps? Did you find in the text a reason whether it would be worth exploring further? Or do you suspect that your IT DevOps practices would be suitable? If so, I recommend an introductory meeting with DevOps in the form of a 3-day DASA DevOps Fundamentals training, which is designed to be found in it, any IT specialist from the Service Desk, operations to development, architects and all levels of management.
See an overview of all the courses we offer as a DASA Accredited Training Partner.
Certification holder:
- DevOps Master
- ITIL Expert
- PRINCE2
- COBIT 5
- Six Sigma Black Belt
She has more than twenty years of experience in IT not only in the Czech Republic but also abroad.
