All You Need To Know About DevOps

Today, we expect our software to work wherever we are and in any mobile or desktop device we use. As a result, IT organizations have to follow several different steps to meet these customer demands. DevOps aims to do just that by allowing organizations to produce and release high quality code better and faster.

What is Devops?

Most who are new to the term ‘DevOps’ tend to question whether it’s a culture? Is it a tool? Just a way of thinking? Or is it a job title? The author of “What is DevOps?” Mike Loukides, states

“It’s a still evolving movement, born of the need to improve IT service delivery agility, the DevOps movement emphasizes communication, collaboration and integration between software developers and IT operations. Rather than seeing these two groups as silos who pass things along but don’t really work together, DevOps recognizes the interdependence of software development and IT operations and helps an organization produce software and IT services more rapidly, with frequent iterations.”

The ultimate goal of DevOps is to build trust and reduce the friction between dev and ops by having proper collaboration and communication.

In the above mentioned scenario, once a new feature, a bug or an enhancement request comes, it goes through a set of stakeholders; Also it will go through the development, build, QA, system integration testing, user acceptance testing environments before it gets to production. The customer, who is now using the software, will start giving feedback depending on the way it has been utilized. And we can use that feedback to improve. DevOps proposes that we improve a two things;

1. 1. We improve the product itself

Once the customer starts using the product, we might get feedback on,

1. 1. • How it is performing
      • How it is functioning
      • Is it meeting our expectation of the problem it was supposed to fix?
      • If it is a bug fix whether it fixed the bug or introduced many other bugs

Using that feedback we can improve the product itself. If using an agile development methodology, we can use that feedback to plan and prioritize the work for the next sprint.

1. Utilizing the feedback to improve the delivery/deployment process

The process is not simple as we write code and send it back to production. There are a whole set of stakeholders in between. People who are involved in creating and delivering software, coders, business analysts, release engineers, deployment engineers, testers, operations, infrastructure engineers etc. So we need to get the software from one environment to the next which involves a process. So the second aspect is to use the feedback to improve the process. And we can improve it in two ways,

• Reduce the number of rework
• Reduce any kind of overhead

Reduce the number of rework

This can be explained using an example. There was a software company that follows the agile development methodology and end of each day they had a new build/ integration release which was ready for the QA team to be tested. It took three days for the QA team to provision the environment, deploy the application, run all the test cases and get the test results back to the developers. The developers will keep on coding on top of the code that was in the latest build, and by any chance if the QA team comes back with a set of bug reports throughout the three days the developers has already coded on top of the buggy code,. Fixing the bug might include refactoring the code that has been implemented throughout the three days. If we can reduce the testing cycle from three days to a few hours we can reduce the number of rework.

Reduce any kind of overhead

The main task of developers is to develop code, but in a certain scenario if the same developer has to spend hours deploying software to a development environment or writing instructions on how a QA can deploy software to a QA environment that can be categorized as an overhead, And if that can be reduced by automation we can improve our software delivery process

Origins of DevOps

Some of the philosophies and principles used in DevOps come from the lean thinking. Idea of lean thinking is to constantly improve your process. It led to the agile movement and the Toyota way of doing manufacturing in factories. And now it’s leading to improve software delivery process which we call DevOps.

Where to start

What you need to look at is your entire eco system. How wide you go or how narrow you go depends upon what you’re looking at. If you’re looking at the project, then you’re just looking at the ecosystem of the project, if you’re looking at the program then you’re looking at the program’s perspective.

When you look at where your enhancement or new feature request comes from it’s probably from a line of business out there such as marketing people or who own the product. These people becomes the key stakeholders when adopting DevOps.

The actual stakeholders will be the developers, build engineers, QA team, integration testers, user testers and operation people. And each of these becomes a different environment. We need to look at how hand offs happen from people to people and how the deliver happens on software and configuration changes happen from one environment to the next. The main focus over here is the continuous delivery process. And what we need to understand is not just the physical aspect of deploying the software from one environment to the next but also the collaboration and the hand off which happens between the stakeholders all the way to the end. This collaboration, building of trust, having proper communication between the stakeholders and making sure they all on the same page, making sure they have access to the same assets, same data is a very critical part of DevOps.

Where do you start? You need to take a holistic view of all of this and you decide where you biggest pain points are. Then you need to address the issues and make sure to improve the efficiency and communication and build trust between the teams.

DevOps Lifecycle

• Check in code
• Pull code changes for build
• Run tests
• Store artifacts and build repository
• Deploy and release
• Configure environment
• Update databases
• Update apps
• Push to users
• Application and Network Performance Monitoring
• Rinse and repeat

Benefits of DevOps

“DevOps not only increases efficiency but also reduces bottlenecks.”

Improved Defect Detection

Basically DevOps figures on top of the agile methodology and thus, it can be considered as extending agile programming. It recommends several agile principles such as collaboration, iterative development, and modular programming which is breaking larger code bases into smaller manageable features. Because of that it is easier to detect the code defects in early stages.

Shorter Development Cycle

DevOps creates a culture among developers and operations that can establish a successful communication and collaboration in-between the teams. For an example, verbal communications rather than handwritten notes or email make sure the recipient entirely realizes the meaning and intent behind critical information. This becomes even more important when information transfer within and between departments. Direct information-pooling is vital to preventing miscommunications that can have serious or even fatal concerns .So they can discuss about the important and considerable points among code and service. The teams can also share new ideas, can increase the speed of moving from engineering code into executable production code.

Better service quality

Before releasing the product to production, we all have a responsibility to deliver a quality product with minimum defects so that it will increase the consumer perception. The consumer perception is dependent on two major factors,

• The availability of these services, as measured by Mean Time To Failure
• Disrupted service speed is brought back online as measured by MTTR: Mean-Time-To-Repair

Because of the fast feedback loops and high release velocity, service shortages are removed faster than in past. It means shortened Mean-Time-To-Repair! So It improves the quality of the service and improves the customer reliability about the service

Increased Release Velocity

It usually takes about 3 to 6 months from requirements to release. But it is now reduced to a daily, if not hourly, release-build cycle. Because of increased number of releases, we can meet the customer expectations.

Reduced Deployment Failures and Rollbacks

Deployment is the major role of the Software Development life cycle. The benefits gained from faster development and deployment can be nullified because of failures in deployment. However, software, when developed using a DevOps mindset, focuses on the operational perspective as well. So when combined with improved defect detection, DevOps can considerably decreases the number of pre and post-deployment issues and it results in fewer rollbacks.

DevOps supported tools

DevOps is responsible of continuous integration and deployments. So tools has helped to share tasks and information, automate the processes, cutting down on time to deploy and finally helping organizations to get closer to the continuous integration and deployment standards.

There are two possible models used in DevOps tools, they are purely script-based model and container model.

Linux users who are more familiar working with commands goes ahead with the tools that use the script based model. Commercial configuration and management-automation products fit into the script based model. A few tools based on this model are Chef (an open source model), Microsoft’s Windows Azure PowerShell CmdLets and Amazon WebServices’ CloudFormation.

The container model is based on building an abstraction of the application into what we might call a container or an object .The configuration engine then processes this container to issue commands.

It allows you to “build up a set of reusable charms that describe application deployment and lifecycle”. This can be run as and when needed, which is of great benefit to cloud providers especially.

Selecting the Right Tool

When selecting the right tool, it’s necessary to consider the company core environment and current strategies. Because using the incorrect tool can result in failure. But there is no one tool that fits all of the considerations. There are several tools specific for role based such as Continuous Integration and Configuration management, Continuous Delivery, Continuous Testing, and Continuous Monitoring.

Docker

Docker allows composing the applications from microservices, without worrying about the inconsistencies between development and production environments and is it platform independent

• Docker has two aspects. – operating system level virtualization and a container instead of a virtual machine
• Open platform for distributed applications
• Language Independent
• Build, ship, and run any app, anywhere

Challenges of Devops

• • Building the DevOps Culture

Culture is the combination of ideas and the behaviors and it is hard to identify the standard collection of requirements. There are several tools available in the industry, and it is comparably easier to select a tool which is matching according to our requirements. The main challenge is, it is difficult to change the employees’ traditional behaviors when new concepts are been introduced. DevOps is about continuous change with reconfiguring an organization’s core culture.

• • Meeting a Quick Fix Tool/App Mentality

Most of end users rely on a palette of tools to get their job done. As many are open source or offer initial trial versions, unsanctioned tools can be adopted without any internal mistake – leading to major issues down the road.
Business users believe everything can be solved with an app when making matters worse but that is often untrue. When selecting a tool it is recommendable to highly concern about the security as well. Even though if there has a suitable app, it must be properly integrated to back-end systems .DevOps must balance tool delegation and management early on.

• • From Legacy to Cloud

When business users want to use the latest tools, that is a tall order for operations. With DevOps tooling and configuration management, it is a confusion to select tools do what and how they play with each other. Because tools must be compatible with existing solutions and technologies used by the company. This is becoming increasingly complex with the rise of hybrid environments.
New Hybrid environments include tools like Amazon, Google, PaaS computer service, and SaaS Business applications. Somehow, DevOps must ensure that they all work well together and deliver a seamless experience for the business user.

Authors: Heshani Perera & Thanuja Pubudini