“Sometimes operations would get a release and not know what to do with it. Sometimes they would know what to do with it, and it wouldn’t work. Needless to say this created a lot of tension,” she said.

Opening up lines of communication

To improve things, the company held meetings to open up the lines of communication between the parties, but this only improved things so far.

“Part of the problem is we would get a release to put into production, and people would know the release wasn’t ready. They knew there were problems, but they wouldn’t tell anyone because we have to hit our release dates,” she said.

“We needed to establish trust between the teams. So the next step was bringing them together. We got them hanging out and helped them build rapport.”

Again, getting these disparate teams to spend time together led to a degree of improvement, but there was still something missing, she said.

“We [realised we] needed a team that was just focused on releases, and we created a release engineering team – a group of familiar on the development process, understood what the developers were doing, and were experienced operations folks,” she said.

“They helped to bridge the gap between development and operations. It took a lot of communications to help everybody understand this new team were there to help them product higher quality software and get it out to market faster.”

Why resist?

The resistance Porsche, in particular, experienced during the early days of its DevOps transformation is understandable, said Nigel Kersten, chief technical strategist at Puppet.

Speaking to Computer Weekly at PuppetConf, he said the best thing IT leaders can do in that situation is to be empathetic to the reasons why people are fearful of change.

“If you’ve spent 30 years doing a job, doing it the same way then we should have empathy because it is hard to change,” he said.

Individuals may have some misconceptions about how different their working lives will become, under a DevOps regime that could be relatively straightforward to deal with.

“In some ways, [the DevOps] term creates fear amongst operations people, because they think ‘oh no, I have to be a developer now?’, but in ops we’ve always written code: We’ve written batch files, we’ve written shell scripts and log-in scripts to set up printers, but we just didn’t think of it as programming or development,” he said.

“No-one is expecting sysadmins to become enterprise software architects, but you just need to know something about development and the principles of software engineering.

“In reality, if you learn a few of these software engineering principles, the stuff you already do can be easier, better and completed with more reliability,” said Kersten.

The technology of DevOps

The technology part of a DevOps transformation is often considered to be relatively “easy” to fix, compared to dealing with the people and process side of the equation. This is despite the fact many enterprises are grappling with heterogeneously complex IT environments.

They may be running a mix of on-premise and cloud technologies, sourced from multiple providers, while experimenting with containers and other tools as they set about modernising their IT estate.

Such setups sometimes make it difficult for enterprise operations teams to automate and manage their IT estate using Infrastructure as Code (IaC) principles, which is considered a must for organisations intent on speeding up their software development and delivery cycles.

“Sophisticated operations teams have always known what they have, what their infrastructure is, and what it’s doing, but we’ve definitely seen one of the barriers to adopting infrastructure as code and automation [is people saying], ‘I don’t even know what my servers are all doing and I’m afraid to touch any of them’,” said Kersten.

The technical preview of Puppet’s Discovery tool made its debut at PuppetConf and is designed to provide organisations with real-time insights in how their infrastructure is performing. As such, its dashboard provides a breakdown of how many servers the enterprise is running, where their cloud instances are, and can help them keep track of container-based file changes, for example.

It is fine-tuned to work across VMware vSphere, as well as Amazon Web Services and Azure-based cloud environments, with Puppet promising support for Google Cloud in due course.

“The more we give people tools that go –‘ here is what you have, here is what it looks like and here is a way to bring it up to management, that is only going to help,” he said.

Scaling up through automation

During PuppetConf’s opening keynote, the firm’s CEO and president, Sanjay Mirchandani talked about the company’s plans to help enterprise automate even more of their application and infrastructure estate.

This includes the roll out of Puppet Tasks. This is a family of products geared towards helping organisations automate more of their infrastructure and applications. Included in it is Puppet Bolt, which is aimed at companies just getting started on automation or are running relatively small-scale IT infrastructures who have one-off or ad hoc processes that need automating.

By helping firms cut down their reliance on using manual processes to manage their infrastructure, this may help them take any small-scale DevOps success they may have enjoyed to-date enterprise-wide.

“I talk to CIOs every day and the essence of the conversations around DevOps and automation tends to be, ‘I’ve got pockets of success here and I’ve got pockets of success here, [but] how do I expand that and how do I scale that across my enterprise,” he said.

The process is often more straightforward for “born in the cloud companies”, said Mirchandani, because they lack the legacy technology constraints of older enterprises.

“They tend to have only one of anything – process or technology – and they standardise and they simplify and they automate, and they… rinse and repeat manically,” he told the 1,000 or so PuppetConf attendees.

“Traditional companies tend have at least one of everything, [and that’s] putting pressure on ourselves to become integrators. Is that what we signed up for? Nobody wants to work that way. There has to be a smarter way.”

Anxiety over automation

Automation can help, because it brings consistency and predictability to the act of creating deployment environments, as well as contributing to the creation of more efficient software development cycle.

Puppet’s push, however, to increase its pervasiveness throughout an organisation’s infrastructure and application estate may prompt alarm from individuals in the IT departments who remain fearful about what this may mean for their future job security.

“Everyone is always being asked to do more than they can do right now and automation isn’t going to get rid of any jobs, it’s actually going to cause you to get the jobs done the business wants you to do,” said Kersten.

“The reality is we’re going through a period of disruptive change, and some people are going to be resistant to that – not everyone gets on board, and it’s not going to be easy for those people.”

For this reason, he said it is important for those “sold on the benefits” of DevOps and automation to be empathetic to the people having a hard time dealing with the changes and make an effort to bring them along the journey too.