Puppet on why people, process and technology are mission critical to DevOps success
Source – computerweekly.com
When making an organisation’s agile software development ambitions a reality, practitioners commonly hold the view that success in DevOps requires adopting a strategy that addresses people, process and technology.
Over the course of this year’s two-day PuppetConf partner and user summit in San Francisco, attendees were treated to pointers on how to address all three of these areas, regardless of whether they are just getting started or wanting to scale up their ongoing DevOps endeavours.
Given the people part of the DevOps equation is commonly hailed as the trickiest of these three areas to address, it is – perhaps – unsurprising that infrastructure and application automation software provider Puppet devoted a fair portion of the event’s agenda to advising enterprises on how to foster a business culture allows DevOps to take hold and thrive.
The second day keynote was thrown over to Puppet customer stories from luxury carmaker Porsche, and secure, online virtual whiteboard provider Diligent, who shared details of how they overcame the “people problem” during their DevOps transformation journeys.
Thorsten Biel, manager of cloud and integration services at Porsche, said the firm’s DevOps push is part of a wider scale business transformation that is seeing the firm roll out apps and digital services to enhance its customers’ car-owning experiences through its Porsche Connects initiative.
“Our IT organisation plays a key role in this transformation,” he said. “We’re moving from an organisation that was mostly serving our internal customers in a reactive way to one that is more proactive, innovative and more focused on customer experience.”
As part of this work, Biel’s team has already overhauled the way it is organised to become less structured and more agile, while assisting Porsche with ramping up its use of cloud to deliver its sales and customer-focused applications.
Using cloud to boost localisation
The company currently relies on a datacentre in Germany to deliver these services to its customers all over the world, which can cause problems from a latency and performance perspective.
“The latency between Germany and more remote locations such as Australia and China [where our customers are] is very high. Moving the application to the cloud, removes the latency. We’re effectively moving the application towards the customer,” he said.
These changes have taken time to push through, with Biel citing the people and culture piece as the most challenging part.
“My team has already embraced a more agile way of working. We’ve gone far on the journey of automation, but a large number of people at the same level with no experience of agile methods and have done things the same way for a very long time have reservations about change,” he said.
During his summing up, Biel said a piece of advice he has kept front of mind Porsche’s digital transformation is that you cannot mandate people to embrace DevOps, but creating a culture of trust in the IT organisation means the concept stands a better chance of catching on.
“We’ve reorganised our team a bit to create a culture of trust. We’ve created a DevOps enablement team, made up of solution architects, product managers, and technical consultants who can talk to other projects’ developers, managers and project leaders on how they can implement their projects with DevOps in mind,” he said.
“The combination of creating a trusted DevOps enablement team, redesigning our processes and accelerating our automation journey has enabled us to change in a way not possible before.”
A Diligent approach to DevOps
Tricia Burke, vice-president of production operations at Diligent, shared details of how her organisation – who makes cloud-based tools that allow boards of directors to securely share presentations and communicate – has gone from releasing four software updates a year to around 50.
“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.