Tooling up for DevOps
As organisations look to DevOps for continuous development, delivery and integration of business functions, careful control is crucial
Organisations are moving from traditional waterfall and cascade software development, where code is produced over defined time periods and combined with operational systems management and application management, to more agile approaches.
With an increasing need for rapid functional provisioning via continuous integration, continuous development and continuous delivery, many businesses are looking to adopt a DevOps process.
DevOps aims to bring together the development, test and operational teams to streamline the movement of code and functional apps through the three areas.
However, the process needs large levels of control with the right feedback loops in place to ensure that everything runs smoothly, delivering the highest positive outcome for the business with the least negative impact.
Developer-led switch
The problem for organisations is that DevOps is growing rapidly – and is doing so from the bottom up, rather than being controlled from the top down.
Many DevOps tools are available as open source software – there are no hurdles in the way for an individual in an organisation to download a tool that appeals to them as an individual and start using it.
For many staff in development or operations, this is too good an opportunity to turn down. Developers have been looking for downstream systems that they can plug into their existing integrated development environments (IDEs), whether these be commercial systems such as IBM Rational Software Architect or Microsoft Visual Studio, open source systems such as Eclipse or Anjuta, or software project management software such as Atlassian Jira Software or CA PPM.
This has led to an increased use of tools such as Jenkins, Chef and Puppet by developers and operations staff. Jenkins provides an automated set of processes that manages software versioning – complete with plugins to accept existing versioning tools such as Perforce, CVS, Subversion, Git and Accurev – along with streamlined processes for continuous delivery. Chef and Puppet started off more focused on the “Ops” end of DevOps, using configuration management tenets to create functional packages that can then be automatically provisioned to the operational environment.
Expanding options
The capabilities of such tools have improved a great deal since they first hit the market in 2005 (Puppet), 2009 (Chef) and 2011 (Jenkins, which was essentially a continuation of work carried out in the Hudson project started by Sun in 2004 and now owned by Oracle).
Their capabilities now cross over each other far more than they did even a couple of years ago, and the need to bring in other point tools to create a complete DevOps environment is less than it used to be.
Increased support for teamwork and full feedback loops means that what essentially started out as point tools for individuals are now fully supportive of groups – even across distributed sites and groups working across companies, such as contractors and consultants.
Alongside these three behemoths, there are other tools available under various open source licences that fit the same area, such as Ansible and Salt, as well as tooling built in to the likes of container software management systems from Docker and Kubernetes. For a Ubuntu-integrated, enterprise-supported approach, Canonical offers its own distribution of Kubernetes via JuJu. Kubernetes is rapidly becoming a new force in the container orchestration field that can be used in a DevOps environment – it is supported by the Cloud Native Computing Foundation (CNCF), which has the likes of Amazon Web Services (AWS), Google, Microsoft, IBM, Intel, Twitter and others as members.
Cloud Foundry is another open source system – also available as a commercially supported system, like most of the open source tools mentioned – that provides a set of automation capabilities that fit in well with DevOps, being able to provide high levels of support for other upstream and downstream systems. Although Cloud Foundry is also a member of the CNCF, it has a degree of crossover with what Kubernetes does, but has a far greater reach in going beyond containerised environments. A separate project within Cloud Foundry, called KuBo (Kubernetes on BOSH) provides an integrated Cloud Foundry/Kubernetes stack for those working in heterogeneous application code, virtual machine (VM) or container environments.
Too many tools
Dealing with a situation where individual developers and system administrators have gone their own way, leading to a mix of different tools across the IT environment, can become a problem for organisations. This can be dealt with in one of two ways.
First, be prescriptive: Decide on one set of tools to use and lay down the law – all developers and system administrators must use the same set of tools. Unfortunately, this is pretty much doomed to failure – remember that you are dealing with developers and system administrators here. Look in the top drawer of their desk and see the number of CDs and thumb drives with non-sanctioned software on them that they find useful to themselves in their day-to-day lives. They may seem to agree with you on the necessity for a single tool, but they may well then carry on in their own manner when you are no longer looking.
Organisations then fall into the perception of righteousness: having instructed everyone to do as they are told, they assume that this is so. Then something goes wrong, and the forensic postmortem of the event uncovers the problems: disjointed islands of functionality with no single form of oversight in place.
Second, be pragmatic: Accept that it is already too late to put the genie back in the bottle and figure out a way of making a chaotic mix of individually used tools into something more enterprise-ready.
Many of the open source tools, through their increasing use of plug-ins or through use of open application programming interfaces (APIs) can accept input from other open source tools at a reasonable to high level of fidelity.
Where greater levels of control are deemed to be required, along with full enterprise levels of support, then either a fully supported subscription to one of the distributions of the open source software – such as CloudBees, with its support for Jenkins and its extra layered components – can provide the extra “enterprise-ness” organisations are looking for.
Open systems offer longevity
Beyond this, commercial systems are also available that enable a good degree of openness to support existing tools. One example is CA Automic, which offers a good automated approach to DevOps process streamlining while accepting different underlying tools in an open manner.
The capability for such systems to enable the swapping in and out of different underlying tools is a key point: five years ago, not many people were talking about Chef and Puppet, and Kubernetes was only released three years ago. What is the market going to be like in another five years? If the over-reaching umbrella system is a closed system with hard links to defined tools, then you could find yourself being left behind. If it is open and allows plug out/plug in functionality, you can move to embrace new tools as they come along.
There are plenty of other companies operating in the DevOps space. For example, HashiCorp has several tools, including Terraform and Vagrant that help make a DevOps environment more simple to operate. Perforce has branched out from its heartland of version control and has launched its Helix portfolio of tools that provide a broad range of DevOps functions.
In the world of evolving older-style systems management configuration management software, BMC has its BladeLogic automation suite. Modernised to embrace cloud computing and containers, BladeLogic Server Automation – particularly when mixed with other BMC products, such as Atrium Orchestrator, Control-M Automation and the TrueSight portfolio – can provide DevOps functionality.
HPE’s composable infrastructure bridges the hardware/software chasm, enabling logical platforms to be easily configured and physical, virtualised or containerised software provisioned to it through the use of OneView.
Of course, there are also in-the-cloud DevOps options. IBM offers a broad set of capabilities via its BlueMix platform. AWS, Google and Microsoft offer tooling directly on their platforms, while many of the tools already mentioned are available for implementing via self-service modes on their cloud platforms.
DevOps is becoming a major means of providing the business with what it wants and needs: continuous development of new functionality that can be delivered quickly as required. A quick note: it really should be “BusDevOps” – those needs and wants must be dictated by the business, not by the developers.
To gain the most out of such a BusDevOps environment needs rigorous tooling – and this is unlikely to be via prescriptive or proscriptive rules. Be pragmatic: provide umbrella systems that can apply order to the existing chaos, and allow developers and system administrators to work in the way that makes sense to them.
Source: https://www.computerweekly.com.
