Has the rate of change in DevOps led to a boom in non-standardised technologies?

Bryan Ross (BR): I’ve worn many hats in my career; software developer, database administrator, etc, but my real passion has always been infrastructure, particularly managing things at scale efficiently using automation.

Perhaps a little different from the stereotypical sysadmin, I always appreciated good aesthetic design and believe that our job as IT professionals is to simplify infrastructure, making it easier to understand, consume and manage.

Like many of my generation, I started my career in the dot com era, where I met some great guys whom I latterly set up a software-as-a-service company with after the bubble inevitably burst!  As a very small company, it was vital that we all respected our individual skills and had an appreciation of what was happening across sales, software and the platform.  Our approach, tools and practices wouldn’t look out of place in today’s DevOps world!

BR: When I was working in the software-as-a-service company we had a very safe environment where we empowered the team and avoided any blame culture. The most important thing I took from those times was the importance of a strong team culture.

Today I run four engineering teams where my goal is to emulate much of that early success:  hire smart people, trust them to make decisions and foster an environment where the team pulls together when things don’t go to plan.

BR: From a technical perspective, I think it’s very telling that – if we look back 10-20 years – system administrators would pride themselves on server uptime; everyone wanted four digits.

Today, however, it’s all about how quickly and how often we can rebuild entire environments from scratch, and I think that says a lot about the introduction of DevOps toolsets and perhaps the decreasing importance of the operating system.

The other thing I’ve noticed is that IT and whatever you’re producing now simply has to be nice to use; whereas in the past it was sufficient to be technically superior or most cost effective, but this emphasis has shifted significantly today.

BR: The biggest thing for me is artificial intelligence, and I’m incredibly excited about recent developments in this area. I think we’ve come a long way since the likes of Microsoft Paperclip, and we have a long distance to go, but we’re now layering technology into our daily lives in a more sympathetic manner.

We’re harnessing it to enhance decision making, to drive new ecosystems, and to let systems interact with us and our surroundings more intelligently, and that’s exciting.

Within the context of DevOps, we’re seeing a move from traditional threshold-based analysis of individual server performance to an increased reliance upon anomaly detection to find issues with large, distributed systems (e.g. micro-services).  I really think we’ve only scratched the surface of what’s possible here, so I can’t wait to see how that advances.

BR: Looking at the 6 to 12 months mark I think we’re going to find more standardised tooling around working with Kubernetes. There is already a plethora of open source tools, with more being released every day, but I’d hope we see some convergence looking forward.

Looking further afield a big thing I hope we see is a change in how we consume public cloud; moving towards a dynamic economic market rather than the natural monopoly of the big players we have today. In an ideal world, companies could sell their spare compute cycles to the highest bidder, who can then use these to provide public cloud services.

For example, by offering the same “economies of scale” in terms of compute power afforded to the likes of Google, Amazon and Microsoft, could we see a small company act as a competitor to Google BigQuery?

BR: Yes, I think it’s natural to see an explosion in tooling as new technology becomes available, before teams begin to settle on a few.  The landscape is also always changing; so, as we begin to standardise in one area, another sees explosive growth.

Not so long ago, there was a plethora of configuration management tools, both new and old, which we saw convergence towards the likes of Puppet and Chef.  As teams began shifting from configuration management to “repaving” their environments, more generic tools like Ansible and Terraform have grown in popularity.

So, in that respect, Kubernetes is still on a phenomenal growth pattern, but I think we’ll reach stabilisation/standardisation that we’ve seen with other disruptive technologies, such as virtualisation.

BR: In my experience, digital transformation projects tend to be large, multi-year programmes costing millions and often missing their mark.  Worse, they threaten to achieve their goals by being “Agile”, without really understanding what that means.  At its core, digital transformation is as much about changing culture as it is about delivering technological change.

So, if we can learn anything from Agile and DevOps, it’s to start small and to work closely and collaboratively with anyone in the business that wants to help you, building upon successes and learning from every iteration.

In essence, Agile tells us to “break things into smaller more manageable increments that deliver value each time” and DevOps says, “let’s work together to build something robust, that does what we need right now, and can be improved later”.  We need to ensure we’re implementing the foundations of Agile and DevOps to get digital transformation right, rather than just steaming ahead with grand, long-term plans.

BR: It’s important that you have a wide breadth of knowledge and understand the fundamentals of infrastructure, software development and how technology relates to the business.  With the rate of change in technology, it’s less about what you know and instead how you quickly learn new technologies, apply your experience to new situations, and have an ability to break down complex concepts and communicate with people from various backgrounds.

Above all else, you need to be user focused in your mindset and constantly be looking for ways to make technology easier for users and colleagues through standardisation, automation, visualisation, documentation, etc. The way I see it, technology is largely irrelevant if it doesn’t meet the needs of its users or it’s too complicated to be managed efficiently at scale, so a good DevOps professional needs to be able to make the technology relevant.

BR: Yes, there’s certainly a challenge in finding people that not only have a solid technical competency in infrastructure, but who also want to embrace modern software development practices – all whilst being able to confidently build relationships with users and colleagues from across the business!

BR: For me, if we can find someone with a passion for automation and an appropriate level of foundational knowledge, I’m confident we can teach them new technologies; but I know that we can’t change culture as readily.  I generally look for individuals that can demonstrate they’ve been learning and adapting, rather than those who have deep knowledge in particular technologies.

Interestingly, my recruitment style hasn’t changed significantly – I largely follow the same model that we used when we were building our small company!  During interviews, I will generally focus less on the candidates’ CV and previous work experience and more on what inspires them.

Often, we’ll end up talking in depth about some interesting blog post they’ve read, or a personal home automation project!  In many cases, the engineers that come work with us are those who have previously wanted to automate or improve something but who weren’t given the support to do so. In essence, I look for smart, passionate people who I can trust to make decisions, and who will work for the benefit of the team.