DevOps: The right tools, the right teams

Just as accepted definitions of what DevOps entails have morphed and grown over the years, so too have the toolsets and management approaches employed to build and manage a DevOps culture within the organisation.

Where developers used to manage their interactions with cloud services largely on their own through Web dashboards. DevOps tooling not only automates this process but wraps it in a monitoring cloak that makes it easier to track ongoing infrastructure costs in real time.

Read the previous pieces in this series:
DevOps: Delivering cloud reliability at all costs
DevOps: Keeping your cloud transformation under control

Indeed, thanks to maturity on the part of the cloud providers themselves, such tools are fast becoming mandatory because the process of cloud provisioning has become intensely API-driven.

“You have to create infrastructure by code,” says John Sullivan, business division product delivery manager with MYOB, which has built DevOps into its iterative software-development process for years.

“You can't do it through the dashboard and you can't do it by plugging in boxes. So whilst you don't necessarily have to have true DevOps in place, you are going to be using development practices to configure infrastructure as soon as you start entering into using the cloud as a provider for infrastructure or services.”

DevOps in the cloud

Thankfully for those interested in embracing DevOps, service providers and software houses are working hard to imbue cloud environments with the capabilities necessary to make it happen.

Rackspace, for example, offers a DevOps Automation Service, while Amazon Web Services (AWS) offers its widely used OpsWorks toolkit.

Many companies are formalising their DevOps capabilities. Bulletproof Networks, for example, last year launched a Bulletproof Professional Services offering that incorporates internal teams of DevOps practitioners that consult with customers on the transition and help them leverage internal tools for easy cloud-service provisioning.

Other providers are bringing capabilities such as security to the table. In January, Tenable Network Security expanded its Nessus cloud-visibility and system-hardening tool to allow visibility of workloads, applications and assets running on Microsoft Azure, AWS and Rackspace cloud environments. Deployable agents provide a continuous stream of information to enable monitoring of available cloud resources in real time.

HP, which has gone all-in on DevOps as a way to unify its myriad technology and consulting capabilities, is also pushing the case for a stronger profile for security within DevOps processes, citing user research that found integrating security throughout those processes would improve applications and service quality and performance, decrease security risk, and speed identification and resolution of issues.

Third-party developers are also finding opportunities in the DevOps space: Australian developer GorillaStack, for one, has built a strong export business around an eponymous tool that helps DevOps-focused teams track, control and cost AWS resources as they are created and used throughout everyday operations.

New instances are tagged as developers create them, with central reporting and integration with chat platforms like Slack allowing managers to see at any point how much their infrastructure is costing.

“DevOps people are extremely talented and do a lot of things, but when it comes to optimising costs and determining how much they are spending on the cloud, it's not really a key concern,” explains product manager Oliver Berger.

“As the company grows, the DevOps environment can get very large and very unwieldy, very quickly. DevOps people do a lot of repetitive work and our goal is to automate that, so they can focus on things related to their core strengths and competencies.”

Page Break

As well as supporting the transition to DevOps, IBM has taken the idea a step further by building the DevOps philosophy into its BlueMix cloud platform, an integrated environment designed to deliver rapid application development through the use of intelligent objects – microservices, as IBM Australia CTO for cloud computing Andrew Kupetz explains – whose infrastructure dependencies are hardcoded.

“We now have the traditional world with its traditional technologies, and we have cloud-native technologies,” Kupetz says.

“Many of those are designed with DevOps and continuous delivery embedded for push-button deployment. But you can go so far, straight from development through the different stages into production, within a minute – and we're finding that you really need to inject DevOps with discipline and policy.”

By pushing the provisioning of cloud services into the background, Kupetz says, BlueMix was designed to help developers and business leaders to focus more on building functionality than worrying about back-end infrastructure.

Containers contain patterns that code for inter-module dependencies and tap into a range of cloud-based services such as mobile integration, messaging security, analytics, and cognitive computing based on IBM's Watson analytics engine.

“We're seeing the industrialisation of business and IT,” says Kupetz, noting that streamlined development is already delivering projects “20 to 100 times faster and cheaper than things that are being done today.”

“You can pick and choose pieces that may come from different ecosystems and vendors,” he says.

“Put them together; choose the tooling you want to use and the policies and workflows you want; and code for your uniqueness; there's a new solution that is wrapped up with DevOps.”

Business support

While the market for DevOps tools and services has ramped up along with the mass migration to the cloud, those wanting to make the jump do need to be sure they've addressed common issues such as garnering the involvement of business organisations and ensuring that all relevant parties are involved in the DevOps process.

In many cases, existing business structures can work against the implementation of DevOps: MYOB’s Sullivan ran into such issues when he tried to introduce DevOps years ago, in a former role as development team manager.

“In that case there was a true operations team that wanted to manage the infrastructure, and the biggest problem was that there were two lines of management involved,” he recalls.

“Getting a true DevOps capability into the company failed because there were two lines of responsibility there that didn't work together.”

“You need alignment from both the operational side of the business and the development side of the business to get the process to work properly,” he says.

“But DevOps is such a general term people talk about it from different angles, and with different agendas. You can be having conversations at cross purposes when you're talking about it; find people on both sides of the court to get involved.”

Depending on corporate culture, resolving those differences can be anything from a piddling task to a monumental and often frustrating undertaking.

Some organisations get hung up on which business division – development or operations – should drive DevOps, when a fundamental precept of the new philosophy is that a new DevOps team be built from the previous structure.

“As with any cultural change, you need patience,” says Ashok Vasan, APAC vice-president of application delivery with CA Technologies, which has followed the DevOps evolution in Australia and releases annual studies tracking its progress here and abroad.

“The architecture that CIOs have to grapple with is very complex, especially when you're talking about new services. Set realistic expectation at all levels so people don't think this is a magic bullet that is going to fix all their aspirations overnight.”

CA's analysis has defined nine key points that must be addressed for DevOps to be considered a success.

These include a well-defined strategy and objectives; business stakeholder education; IT-business alignment of priorities; relevant IT knowledge and skills; cross functional IT processes; cultural harmony within IT; the right infrastructure and tooling; the right suppliers and support; and security and compliance measures.

Implementing each of these is a complex undertaking in itself – and changing them even more so.

“There is so much process and tradition standing in the way of using a DevOps approach that it seems nearly impossible,” writes AppDynamics developer evangelist Dustin Whittle.

“From an operational perspective, my first instinct is to understand the application architecture so I can start thinking about the proper deployment model for the infrastructure components. From a development perspective, my first milestone is to make sure the ops team fully understands the application and what it takes to deploy it to a pre-production environment.”

Willingness to continually revisit corporate objectives and design conceits is crucial to making Agile development processes work – and effective DevOps makes it all possible.

CA's Vasan recalls one financial services customer that built a mobile app that turned out to be poorly received by customers. A second go saw the development team more actively engaging user feedback and, as a result, producing an app that was seen both as more relevant and more effective.

“They wanted to come up with a new app after the first one failed,” he recalls. “A mobile app is a direct touchpoint with the end user, and that drove the way the service was designed; what kinds of features were going to be offered; and how it was going to be developed, tested, released, and promoted.

“Those were business decisions, and developers need to be brought into the conversation much earlier when a new service or business is being centralised. It's ideal for key strategic business owners to involve developers and even test people early in the design stage.

“It's not just about buy-in; top management need to take serious ownership and drive it within the rest of their organisation because it's going to help make sure their strategic initiatives come to fruition.”