What is DevOps?

There are multiple interpretations of DevOps (development and operations). Essentially, many features of this approach already exist in most well-functioning cloud organizations. From this angle, DevOps looks more like an evolution than a revolution in the way the company IT sector works.

DevOps can be viewed from three angles – people, processes and technologies. Seen through the prism of human relationships, DevOps is a philosophy that seeks to break down traditional organizational silos, and especially the strict separation of teams engaged in application development and infrastructure management. It is common to see development teams as messengers of change, and admin teams as guardians of stability, or as two teams with opposite goals, which leads to inefficiency. The DevOps approach changes that. When it comes to processes, DevOps integrates agile development principles into mode. As a standard, agile principles are used to continually create code ready for the production environment, but with DevOps this thinking is transferred to managing the entire infrastructure.

Lastly, DevOps involves the application of a variety of technologies that enable more efficient operation and automatization whenever available. Thus, Git is used to manage the source code, to view Gerrit code, and to manage configuration tools such as Puppet, Shef, Ansible, and SaltStack. The technological basis for DevOps mode includes VMware vRealize Code stream tools for application publishing, as well as vRealize Automation and vRealize Operations for resource allocation and infrastructure monitoring.

Why Companies Need DevOps?

With constant and changing technological trends, there is strong competition and every company wants to advance and outperform its competitors. Companies want to release their new features as soon as possible. This can be quickly achieved through DevOps. DevOps incorporates agile practices and eliminates bottlenecks, making software delivery as easy and straightforward as possible. Therefore, any software-based company today should embrace DevOps.

Common practices that DevOps uses

Below are some of the most important practices that DevOps uses

Automatization

DevOps relies entirely on automatization and tools to enable it to be implemented. If there are tasks that are often performed in the same way and produce identical results, then there is no reason to waste time and perform them manually each time. This saves time, but also avoids possible human error. When it comes to development, automatization is very important. One of the most common tools used is Vagrant, with this tool it is quick and easy to tweak the development environment. It is of paramount importance for every developer to get a finished image with a preinstalled system and all the necessary components that will allow him / her to focus on development within 15 minutes. In addition, one of the tools that is standard among DevOps engineers is Jenkins – a tool that enables the creation of so-called jobs for continuous integration, continuous delivery, continuous testing and similar.

Waterfall Development

Before continuous integration, development teams would write a bunch of code over three to four months. Then these teams would put together their code to release it. Different versions of the code would be so different and have so many changes that the actual integration step could take months. This process was very unproductive, this is why the Waterfall Development is used to divide the project activities into linear sequential phases, with each phase depending on the results of the previous one and corresponding to the task specialization.

Continuous Integration

This is one of the most important practices in DevOps, which essentially means: as often as possible to commit, push and merge code that we work on. For each task, the developer creates a separate, so-called feature branch, which after the desired changes and the most basic testing on its part, is first pushed to the remote repository, to make the branch visible to others, but also merge into some larger codebase. This cycle in agile development is repeated several times a day, of course – all depending on the volume of work in a particular task. This actually means that every developer needs to actively monitor what the rest of the team is doing to integrate their code seamlessly with others, but on the other hand, this approach significantly improves team communication and allows the baggy code to be identified and corrected at the earliest possible.

Continuous testing

As Scrum dictates, pre-release is always at least one week scheduled to test active features. However, as with previous theses, testing should be a continuous collaboration between the developer and the QA engineer. Also, testing in DevOps context does not mean classic click-to-click testing – automatization is the key. Of course, there is nothing wrong with this, every team must have QA people who will continually go through the application and determine that it is behaving according to requirements. However, more recent practices also include test-driven development, that is, automated tests that also run through a tool, such as Jenkins, usually after every build. This makes it more convenient to immediately identify the critical feature and eliminate it from codebase before any major damage occurs. On the other hand, not only are new features tested, there are load, stress, and probably some other tests that will automatically show how an application behaves when exposed to certain circumstances.

 

Continuous Delivery

This practice builds on the previous two and represents the deployment of stable and fully tested production code, with the goal of keeping it as short as possible. The time period should be between the two deployments, which usually depends on the release of the individual product plan. Basically, delivery happens at the end of each sprint, which means once a month or once a month and a half.

Monitoring

After deployment and commissioning, the next step is monitoring. Of course, it all comes down to automatization and tools, your custom tools, open source tools, proprietary tools. The bottom line is that you have to constantly monitor production work and have measurable results that you can use to prevent many unwanted things, or improve the environment in the next cycle. However, monitoring is not only on the back of the Ops team – each team member could monitor the production environment and, based on what is shown, conclude how the environment behaves and what it is doing at that moment. For example, if it is a web application, you can easily monitor the performance of all servers currently active and, if necessary, run scale-up / down to maintain the desired responsiveness at minimal cost. On the other hand, alerting systems should always be provided that will notify the Ops team when there are downtime or problems at key points in your system (e.g. dead locks detection, etc.).

What Is the Goal of DevOps?

DevOps is there to enhance collaboration between all stakeholders from planning, delivery and automatization of the delivery process to:

• Improve mean time to recovery
• Improve deployment frequency
• Lower failure rate of new releases
• Shorten lead time between fixes
• Achieve faster time to market

Benefits of DevOps

Security
Move fast while maintaining control and maintaining compliance. Your company can adopt the DevOps model without sacrificing security using automated compliance policies, fine controls, and configuration management techniques. Using infrastructure as code and policy as code, you can define and monitor compliance.

Speed
As a business company, you also need to move and think faster than your competitors in order to innovate customers, better adapt to changing markets, and grow more efficiently in achieving business results. The DevOps model enables your developers and operating teams to achieve these results. For example, microservices and continuous delivery allow teams to take ownership of the services and then post updates to them faster.

Reliability
Ensure the quality of your application updates and faster infrastructure changes so you can reliably deliver your applications at a faster pace while maintaining a positive end-user experience. Tracking and logging practices help you stay informed about real-time performance. Use practices such as continuous delivery and continuous integration to check that any change is functional and secure.

Express delivery
Increase the frequency and pace of releases to help you innovate and improve your product faster. Continuous integration and continuous delivery are very important practices that automate the software release process, the faster you can respond to your customers’ needs and build a competitive edge.

Improved cooperation
Enhanced collaboration builds more efficient teams according to the DevOps model that emphasizes values such as ownership and responsibility. Developers and operating teams work closely together, share many responsibilities, and combine their workflow. This reduces inefficiency and saves time.

Most used DevOps technologies & tools

To achieve all these benefits, DevOs uses special tools:

• GitHub
• Docker
• Jenkins
• Consul
• Curl
• Samba
• Cifs
• Nfs
• Zookeeper
• Bash
• Netstat
• Htop
• Iotop
• Telnet
• Ngrep
• Ping

Differences between Hardware and Software DevOps

• Software is easier to change than hardware. The cost of change is much higher for hardware than for software.
• Software products are being developed through multiple releases by adding new features and rewriting existing logic to support new features. Hardware products consist of physical components that cannot be “rebuilt” after production and cannot add new capabilities that require hardware changes.
• Designs for new hardware are often based on earlier generation products, but usually rely on new generation components that are not yet present.
• Hardware designs are limited by the need to install standard parts.
• Specialized hardware components can have a much longer acquisition time than software.
• Hardware design governs architectural decisions. More architectural work has to be done in advance compared to software products.
• Software development costs are relatively flat over time. However, hardware development costs increase rapidly by the end of the development cycle. Software testing usually requires the development of thousands of test cases. Hardware testing involves far fewer tests.
• Software testing is done by specialist quality assurance (KA) engineers, while hardware testing is usually done by product creation engineers.
• The hardware must be designed and tested to work in a specific time and environment, which is not the case for software.

 

Author: Miloš Denić