Why enterprises should care about DevOps

As part of the famed site reliability engineering group at Google, Nigel Kersten led the design and implementation of one of the world's largest Puppet deployments. The experience was so life-changing that he joined Puppet over nine years ago.

Today, Kersten, who is now Puppet’s field CTO, travels the world, espousing DevOps practices and serving as the bridge between customers and Puppet’s product and engineering team.

The Australian, who grew up in Malaysia and Australia, recently relocated to London, with 70-80% of this time focused on customers in Europe and Asia-Pacific (APAC). In a wide-ranging interview with Computer Weekly, Kersten offers insights on the state of DevOps adoption in APAC and explains why DevOps does not signal the end of IT operations.

Based on your interactions with customers, do you see any differences in DevOps adoption in APAC and elsewhere?

Nigel Kersten: One of the things I’d say is that there’s a lot of variation across the APAC region. Five or six years ago, I started working much more heavily with customers in Singapore when we started building up our presence here.

I was talking to financial services companies who felt they were behind Australia and New Zealand. And at the time, Australia felt further ahead of the US. It could be because Australia always had a strong operations culture, or perhaps Australian companies have always had to do things on their own without having people in their time zone.

But I’ve noticed that Singapore’s rate of acceleration and appetite for change is so much greater than Australia’s now, possibly because of a huge mandate to be a smart city and a tech hub. Singapore has a very pragmatic IT culture. Once there's executive buy-in, the tools are much more easily adopted.

Since the last time I spoke to Puppet, there’s been a heightened focus on security. Could you talk about the security related practices that your tools are facilitating to ensure security is baked into DevOps?

Kersten: I’d say the interaction between development and operations was the biggest bottleneck and it was the most obvious source of dysfunction. But we’ve improved that as an industry.

Security became the next most obvious bottleneck that is being addressed now, particularly in regulated markets like financial services. Once teams started getting development and operations working alongside each other, the next candidate for improving the whole software delivery lifecycle was security.

One of the interesting things has always been that even though Puppet didn’t have an explicit security product for a long time, given that we help to manage the desired state of machines and automatically mediate configuration drift, we’ve always been friends of security people.

One of the frustrations I have is that large companies are not looking at improving their legacy environment, thinking that legacy systems will all go away some day

Over the past 10 years, there’s been an increasing appetite from security people for robust IT automation and configuration management, because they’re facing similar problems that operations people have been facing.

Software is being deployed across different environments, and the mindset of having perimeter firewalls is also shifting with more stuff being moved to the cloud. And as companies become more distributed, security teams need automation in order to do their jobs well.

When we talked to security teams, we noticed there was a real interaction problem. When security teams have a list of vulnerabilities, they put them into a spreadsheet and send them to the operations team. But the operations people don’t really know which ones they should address, how quickly they can address them, and the relationship between a vulnerability and the rest of the IT landscape.

So, we came up with Puppet Remediate, an operations tool that serves the needs of security teams in a much simpler way where vulnerabilities automatically appear on a dashboard. The operations team can leverage content that they could use across conflict management or task orchestration systems during the remediation. This tool has been taken up very, very well in the APAC market.

Are there any integration points with messaging systems that DevOps and security teams use to communicate with each other?

Kersten: Absolutely, it’s that same desire to improve cycle time by using different APIs [application programming interfaces]. One of our customers in Australia, Transurban, has built an incredible system that people can use to make change management requests through ServiceNow. The system automatically provisions through Puppet, and notifications are sent through Slack. This provides developers and operations teams with situational awareness about what’s happening, and the ability to create and deploy changes in a sophisticated manner.

Open source companies, particularly open source infrastructure companies like ours, have always understood the power of APIs because they allow our community to build solutions that increase value for everyone.

Enterprise technology vendors have also crossed that bridge with simple-to-consume APIs. For example, it has become easy to integrate ServiceNow with Puppet Enterprise and that’s going to be the big game changer over the next few years in the enterprise space.

Customers without huge teams of developers will be able to produce sophisticated self-service solutions by using Puppet Enterprise’s engine to drive automation across the business. Even if they’re not directly interacting with our graphical consoles, they’re interacting with the APIs and solutions that internal teams are building on.

DevOps is the way forward for many enterprises, but there are some quarters in the industry that are saying that we should really be gearing up for NoOps. What are your thoughts on that?

Kersten: We’ve been hearing the term NoOps for a long time. It was originally coined by Adrian Cockcroft when he was at Netflix, but that was a very different situation. If you’re a relatively modern company that primarily delivers a SaaS [software-as-a-service] solution and you’ve hired a whole bunch of developers who understand modern cloud-native practices, your capabilities and your constraints are fundamentally different from those of an enterprise that has been around for decades.

So, I would say that there’s always the business context that operations reside. When it comes to a bank or any large enterprise, that context is incredibly important. Ultimately, we’re going to see a world where infrastructure developers are a kind of developer.

I’m seeing the needle swinging away from having lots of microservices, because managing distributed systems is difficult

That’s the world we’re moving towards. The old days of manually doing everything as an IT person are gone, and companies that are still operating that way are undergoing transformation. But I don’t think we’re ever going to get rid of operational concerns. It’s just going to be that rather than doing things manually, or through graphical consoles, you're going to work via APIs, scripting languages and automation tools like Puppet.

And in many ways – and I say this quite a lot – DevOps has made operations people feel that they must become developers to get their job done. But it’s more about embracing software engineering principles. It’s about version control, release management, branching strategies, and continuous integration and delivery. We’ve seen this repeatedly, and that’s why we added features to Puppet Enterprise around continuous delivery, because the most successful customers were those that were adopting infrastructure as code.

But it doesn’t just mean writing code to manage your infrastructure. It means taking software engineering principles, understanding unit tests, smoke tests, and building enterprise guard rails that we've known for a long time to deliver software – and now infrastructure – quickly.

2019 had been a year of Kubernetes. The year was marked by several notable developments in this area, particularly efforts by enterprise technology suppliers to try to become the dominant Kubernetes platform. How do you see the so-called “platform wars” in the Kubernetes space playing out?

Kersten: I would say Kubernetes has been incredibly powerful in providing a common control plane for distributed applications. But I’m not convinced that we have an easy-to-use version of Kubernetes that enterprises will run on-premise. It’s clear that if you’re using Google or Amazon, it’s relatively easy to use Kubernetes because you have someone else taking on the operational burden.

That said, there are big companies with small teams that are doing a great job running Kubernetes, whether that be in public cloud or on-premise, but I’m also seeing less sophisticated teams really struggling with it.

I’m also seeing the needle swinging away from having lots of microservices, because managing distributed systems is difficult. And sometimes, you’re not making the right bet in terms of complexity versus the business value that you’re delivering.

The reality is that legacy systems are still powering many businesses today and one of the frustrations I have is that large companies are not looking at improving their legacy environment, thinking that legacy systems will all go away some day.

Yet, the biggest gains enterprises will see from a small degree of automation – and more robust monitoring – are in legacy environments. These can have a huge impact because you probably have thousands of people interacting with legacy environments, where the lack of automation is causing people to spend a lot of effort on patching, compliance and change management. You don’t have to go fully cloud-native to adopt the mindset and techniques of cloud-native in your legacy environment.

That’s a good point, but are enterprises buying that view? After all, tapping the latest and greatest technologies gives the CIO a higher profile rather than refactoring an old clunky application.

Kersten: We can be a very fashion following industry in some ways. The term I’ve been quite fond of is “resume-driven development”, where people deploy a Kubernetes application because they need Kubernetes on their resumes.

The role of senior leaders and executives is to take a more mature and longer-term approach. While it’s critical to invest in the future and there’s no denying that you can get huge gains out of cloud-native refactoring, migrations and even greenfield deployments, the companies that are succeeding are those that are taking a hard look at their legacy environment and investing time to improving those.

Now, that may not be the most fashionable thing to do. But once you have quantifiable results, where you can show that this much manual labour was reduced, this much change management was improved and applying DevOps principles had enabled you to deliver software more quickly and reliably, those are the things that will progress your career, not whether you can list the most fashionable keywords on your resume.