For the past few years, DevOps has been something of a hot topic in the IT industry. As increasing connectivity and the power of the cloud pushes businesses to move at a faster rate, many companies have started looking at DevOps as a way to be more agile and responsive.
But what is DevOps? In a nutshell, it’s about merging two core areas of business IT: development and operations. The idea is to have the staff that build the applications directly collaborating with the teams that deliver and maintain them; in other words, having coders and UI engineers working side-by-side with network specialists and database architects.
In theory, this should enable an IT department greatly speed up its release cycles. By integrating the two teams, monitoring and testing of new code can be done while the application is still in development, which allows new builds to be shipped exponentially faster – a practice that is known as shifting left.’
If you want to know what DevOps should look like in practice, however, the answer depends on who you ask – IT Pro has seen a room full of engineers and DevOps experts argue over that exact question for hours. Some argue that it’s a way to structure teams, others say it’s a set of practices and workflows, while yet others maintain that it’s more of a philosophy than anything else. Many successful companies tend to view it as a mixture of all three.
DevOps team structures
There are many potential forms that a DevOps team can take – some viable, some not so much. One popular structure is to build teams around products, rather than roles. Rather than having a product being worked on by people within wider development and operations teams, this structure would have one dedicated team assigned to each product, including staff from every discipline.
Another commonly sought-after team setup is to have Dev and Ops collaborating extensively, whilst still maintaining a degree of separation. Each team retains their individual roles but also works closely with their counterpart to work through problems. This requires Dev and Ops to be familiar with the other’s role and skillset, to think about what their challenges might be, and to try and work around them.
DevOps is closely related to (although not synonymous with) continuous delivery and agile development strategies, and it shares a lot of its common elements with these approaches. Although there is no universal, agreed-upon set of processes for DevOps, a DevOps workflow is typically divided into 7 separate stages. These stages include:
- Planning, where the use-case, requirements and success metrics for the application will be hammered out;
- Creation, which involves the programming of the actual software itself;
- Verification, which is where the main bulk of quality assurance and testing happens;
- Preproduction, when the software is finished and ready for packaging;
- Release, covering the actual deployment of the application;
- Configuration, where any post, release infrastructure provisioning and changes occur;
- And monitoring, which involves observing user experience and application performance. Data obtained at this phase often feeds back into the planning phase of the next release, starting the whole process over again.
These stages form the basic DNA of most DevOps tool chains, which often involve heavy use of containerisation, virtualisation, continuous integration and automation tools. They also help inform some of the core elements of the DevOps mindset, such as continuous testing, rapid deployment and strong metrics.
Implementing a DevOps strategy is a cultural change first and foremost. While it may involve using new tools and processes, it is almost universally the behavior and attitudes of staff that have to make the biggest change.
Traditional IT models – sometimes known as siloed structures – can often foster a sense of distrust or resentments between departments, with teams blaming each other when things go wrong. In order for a DevOps structure to function, however, this mindset needs to completely change.
Dev and operations need to trust each other in their spaces, putting aside any feelings that certain areas of the business are their territory.’ Similarly, they also need to be willing to take suggestions and criticism from the other and ensure that any criticism they give is helpful and constructive.
There also needs to be compromise on both sides. While developers are generally in favor of frequent, rapid changes, ops tend to feel the opposite way, preferring predictable, established methods and processes. Both teams need to meet in the middle when it comes to the rate of change, or a DevOps culture will not be sustainable.
Benefits of DevOps
There are a number of key business benefits associated with establishing a DevOps culture; the first of which is that you can greatly speed up the frequency of your releases, as less time is required for testing and QA than with siloed models. Faster releases mean you can deliver more features to your users in a timely manner, and a well-equipped user is a happy user.
Greater speed also brings with it greater business agility, allowing you to respond quicker to market shifts and emergent technologies. By iterating faster, you can keep your business ahead of the curve and, crucially, ahead of your competition.
Faster development can occasionally lead to problems and failures, but one of the beauties of DevOps is that even your failures are faster to recover from. According to Puppet Labs, organizations with high-performing DevOps teams recover from failure more than 25 times faster than their competitors.
There are downsides to embarking on a DevOps transformation, though. DevOps requires fairly massive structural changes, which can be difficult for large, legacy organizations with international offices to pull off. The concept of reorganizing your entire IT structure at a single stroke can be a daunting prospect.
The cultural shift can be difficult to manage as well. Workplace attitudes are often deeply ingrained, and it can be hard to convince previously distant teams to collaborate if they don’t want to do so. DevOps can also be a tricky concept to sell to the board.
While there are no hard and fast rules for which software should be included in a DevOps toolchain, the same options tend to crop up in most DevOps environments. There’s a huge variety out there, but these are some of the biggest names in the DevOps biz.
Used as a configuration management utility, Puppet is central to many DevOps teams. It’s excellent for spinning up new servers and virtual machines and features its own language that is used to define the specific system resources needed.
Another commonly-used alternative to Puppet is Chef, and while they’re widely considered to be neck-and-neck in terms of popularity and sophistication, many argue that Puppet is best suited to operational tasks where Chef favors uses that lean towards development.
Docker is the technology that has been spearheading the uptake of containerisation within the enterprise. The beauty of containers is that while they’re similar to virtual machines, the fact that one OS image can host multiple containers makes it much lighter on resources than spinning up multiple VMs.
The reason Docker, in particular, has proved so popular with the container crowd is that it’s made it a whole lot easier and safer to create, manage and scale container-based applications, which can save IT departments huge amounts of time and money. Its flexible and scalable nature has also made it popular within the DevOps community.
Jenkins is an open-source tool used for continuous integration of code. It includes support for a huge number of plugins allowing it to work with a massive amount of systems and projects.
This is one of the reasons it has become so invaluable to many DevOps tool chains, along with its ability to trigger builds based on a of factors. Like many of the tools used in this sector, it’s heavily focused on automating as much of the software development process as possible.
This article was written by Adam Shepherd from IT Pro and was legally licensed through the NewsCred publisher network.