What is DevOps?
How the merger of development and operations could help your business
In any sector, there are certain terms that come from nowhere to start cropping up in what seems like every other conversation between colleagues. For the IT sector, one of those terms in recent years has undoubtedly been “DevOps”. Everybody talks about it, but what exactly does it mean?
DevOps is a contraction of software development (Dev) and IT operations (Ops) both linguistically and practically. It is a method through which development and operations teams work in unison, and has been adopted by businesses to streamline the creation of apps and software for faster and more effective results than in the more traditional environments where those teams remain siloed.
This DevOps method applies not only for the initial stages of writing software but as part of an ongoing programme of patches and updates, enabling them to be rolled out at a quicker rate. It allows the rapid building and curating of apps, as well enabling companies to react quickly and effectively to changing user needs.
Accelerate your SAP S/4HANA journey with automation
Get to S/4HANA faster, at lower cost, with less riskDownload now
The concept of DevOps was conceived more than a decade ago, but only in recent years has its adoption accelerated – and with impressive results. Major tech companies have finally begun adopting DevOps into their app-building processes, moving away from traditional structured waterfall development methods.
The origins of DevOps can be traced back to startups in Silicon Valley, but more established companies have now picked up on the trend and are feeling its positive impacts in terms of streamlining the development process. It puts into place bootstrapping, making it such an attractive option for businesses with small budgets.
A further appealing notion comes in the form of a means of developing and testing new features at the same time, which means the time developers spend on waiting for a particular feature update or bug fix to be signed off is slashed. Much of this is done in a live environment too, allowing a business to quickly adapt its product to active needs.
To accomplish this, the development teams responsible for writing the software merge with the operations teams who test and manage it, hence the name DevOps. The idea is that testing and monitoring is done as part of the development process so that any errors are detected before the software is finalised. Combined with the heavy use of automation for tasks like integration and deployment, this greatly speeds up the rate at which teams can release builds.
Rather than releasing a massive update every six to twelve months, DevOps methodology favours releasing many smaller, iterative updates over the same period. This creates a steady stream of bug fixes and new features, which allows businesses to respond to changing customer needs or market opportunities with much more agility.
Everything can be completed at the same time, significantly reducing the waiting time and ensuring businesses can be more responsive. For example, if one element needs to be changed after obtaining customer feedback, it can be quickly tweaked and tested immediately, without having to jump through hoops for approval.
There is some contention around why DevOps works so well. Some believe its success is down to how teams work together, while others think it's the practices and workflow that make it so effective.
However, the most successful implementations are a combination of teams and workflows, with the methodology's flexibility to address changing trends and needs making it arguably more superior to other project management techniques for developing software.
DevOps team structures
To ensure DevOps remains to be a flexible and fluid way of developing projects, there isn't any formal organisation of teams. For example, there's unlikely to be a single job role that consistently manages a certain aspect, or that has the sale responsibilities in every DevOps environment.
To ensure it's as fluid as possible, there's also no standardisation around team set-ups either. Each business can create teams based upon what they need for their projects and of course, how their company is set up already. So in one organisation, this could be a team for each product, while in another, it could be a single product team that changes slightly according to the type of product at any time.
However, what is a pretty standard set-up is that there will be multiple skillsets in a single team, including at least one from development and one from operations.
But even this isn't always the case in every company using DevOps. Others may partially split the dev and ops teams out, but then forging a direct collaboration between the two. Although the focus of DevOps is to have development and operations teams working as closely together as possible, there are some parts of their roles that require some independence from the other.
What is vital is that however closely or independently the two teams work, there must still be a clear understanding of what the other's job role entails, so the model can work as efficiently as possible, without any misunderstandings or conflict.
The way you decide to organise your teams will depend upon the existing structure of your organisation and the individual project. For example, if the dev and ops teams already work closely together in partnerships and understand each other's skillsets, you may wish to partner individuals from each team up for the most efficient running of a DevOps structure. However, if they work closely with their own teams, it may be best to keep them separate to obtain the highest levels of productivity.
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, finally, 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 behaviour 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 favour 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 quickly 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, organisations 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 organisations with international offices to pull off. The concept of reorganising 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 favours 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 variety 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.
AI for customer service
IBM Watson Assistant solves customer problems the first timeView now
Solve cyber resilience challenges with storage solutions
Fundamental capabilities of cyber-resilient IT infrastructureFree Download
IBM FlashSystem 5000 and 5200 for mid-market enterprises
Manage rapid data growth within limited IT budgetsFree download
Leverage automated APM to accelerate CI/CD and boost application performance
Constant change to meet fast-evolving application functionalityFree Download