How does a non-tech person describe DevOps?

How does a non-tech person describe DevOps?

How does a non-tech person explain DevOps? 
Why do we necessarily need DevOps, how does it boost our business’ productivity and incomes and which are the main DevOps tools in use?

1. I’m not a tech expert, explain DevOps to me?

A tool? An approach? A role? Few questions in the world have such a diverse of answers, and “What is DevOps?” is one of them. Let’s finally answer this question and find out why adopting DevOps will lead to faster product delivery and higher quality. 

Why look for the DevOps approach and what are the benefits of integrating it into the software development process? Does any Business need a DevOps approach? How do we manage to achieve the flexibility and operational efficiency of the business infrastructure, being minimal costs served by a solid dose of professionalism, responsiveness and active collaboration? Let's dive into some explanations and divide DevOps into three levels of abstraction: DevOps as a philosophy, as a set of practices, and using the right tools.

DevOps's core theme is its philosophy: to create an agile and scalable system, incorporating both operational and development engineers in all stages of product creation, from idea to release. 
To integrate this philosophy into the workflow, you use certain practices — CI/CD, automation, infrastructure as code, microservice architecture, etc.  
And, finally, there is a bunch of tools to implement those practices: Docker, Jenkins, and much more. 
What does DevOps philosophy mean for your company? This means that the task of the operational team no longer begins and ends with the setup and the support the basic infrastructure, and not caring about the products at all (as it has been for quite some time). And, of course, the development team’s task no longer ends at pure creation. 
Now, both parties are constantly working together as a unified DevOps team, improving development and delivery, making them as efficient as possible, sharing responsibilities and a deep understanding of each other's processes. 
Thoughtfully implemented, this results in a huge productivity boost at all stages-from fixing a small bug to implementing a whole new module, from processing users’ feedback to reacting to last-minute changes. 
2. What are the advantages of applying the DevOps set of practices to our ongoing management? And more importantly-how does that contribute to your business?  

  • Smooth collaboration 
This is the foundation of the approach and its biggest benefit. Well-established communication between teams and team members saves a lot of time. And, as clichéd it may sound, time is money. 
It also avoids a lot of frazzled nerves, because the less time spent on waiting, the more focused and motivated the team stays. 
  • Scalability 
If DevOps practices are implemented from the beginning, the opportunity for expansion is built into the infrastructure and architecture. When a lot of processes are automated (testing for example), you won’t waste your time maintaining an expanded system. 
  • Flexibility 
Products built using the DevOps approach consist of small, independent and easily configurable modules (microservices), which developers can quickly replace, change, or add whenever they need to. 
Infrastructure, in the DevOps approach, is also agile and can be easily configured at any moment. 
Flexibility is also manifested in quick reactions to users’ feedback or sudden issues. 
  •  Reliability 
Ideally, the process is set up in such a way that you always have a last working copy of the product, you immediately receive a report about any issue, minor or major, and release/deployment processes are completely automated. In that case in an event of a disaster, you can instantly perform recovery or rollback and have the system up and running in no time. 
  • Speed 
No matter what you are doing — adding new features, switching environments, fixing bugs, etc. — you can do it much faster using the DevOps approach than you can without it. And the more complex and evolving system you have, the more you need DevOps. 
3. Enough abstractions-which are the main DevOps practices and how to use them? 
  • Continuous integration and continuous delivery (CI/CD) 
Continuous integration means that developers regularly merge their code changes into the main branch, and each merge is followed by automated running and testing. 
In other words, after finishing the task, the developer saves the changes into the working project copy. Then the tool used for CI detects the changes and runs the project. If there is any issue, the developer is notified with its description, or just confirmation of a successful run, in case no error is occurred. 
This is how continuous integration helps to detect and resolve errors at the earliest stage possible. 
Continuous delivery stands for the regular, automated deployment of a new version into a production environment. 
Implementation of CI/CD provides a high level of automation, reduces the human factor and allows the team to concentrate on creation, minimizing the time and effort needed for manual operational work. It results in faster development and more frequent and less risky releases. 
  • Infrastructure as code 
Usually information on infrastructure configuration was stored in one of two places: the memory of system administrator or some machine (from where it could be read only by a system administrator). But a person can get sick, and a machine can be stolen or broken. This leaves us with a big and insoluble problem, and if we can still find a solution, it will definitely not be in time for our projects. 
It seems clear that we need to store this information in a way that any team member can read and edit it, so that it won’t depend on the vulnerability of an expert or hardware. 
Infrastructure as code practice implies that system resources and infrastructure settings are defined via machine-processed definition files, which allows the DevOps developer to configure them as program code. Those files can be stored in the same version control system, where code is stored, so they can also be reviewed and reverted. Moreover, changes in configuration files are automatically deployed into the production environment. 
  • Microservices 
Microservice architecture implies that the application is divided into small parts, each built around one elementary function. They can even be written in different programming languages, use different frameworks, and operate under different operating systems! 
Microservices are easier to test, maintain and reuse. The dependencies between them are reduced to a minimum, so adding a new one requires no change in the existing parts. However, this approach can’t work without thoughtfully designed testing. 
A project built on microservices is always ready for growth and significant changes. 
  • Configuration management 
This practice requires detailed recording and updating of information, describing hardware and software (released updates, versions, environment settings, etc.). Simply put, the company always possesses up-to-date detailed information for all of its resources. 
Those records provide great insurance in case any major issues arise, because you can always perform a rollback and recover any configuration version. Sometimes, when a server is down for one second, it can lead to a million-dollar loss, so configuration management gives the system high reliability. 
  • Monitoring and logging 
No test can provide information the same degree of reliability and volume as actual data from actual users. Gathering, categorizing, and analyzing logs lets the team detect issues, come up with new features and improvements, and continuously make products and processes better. 
  • Automation 
Basically, the whole DevOps approach involves the complete removal of extra manual work. Version control, testing, deployment — if anything can be automated, you automate it. It may require some resources at first but will give you a noticeable difference in the near future. If your goal is to create a truly scalable and flexible system, automation is the best investment you can make. 
4. What DevOps tools do we use at ITGix? 
 The tools are only means to an end. In order to achieve the methodology we need the tools, but the tools are not the methodology itself. 
  • Docker for containerization 
  • Jenkins for continuous integration and continuous delivery
  • Terraform and Ansible for server provisioning and infrastructure
  • Puppet for automating the configuration and management of the infrastructure
  • Nagios for Open Source IT monitoring, network monitoring, server and applications monitoring
  • Icinga for open-source computer system and network monitoring
  • and many more