DevOps still remains an elusive term, and the technical and cultural change it necessitates within businesses is still being grappled with. And, with the DevOps landscape continuing to evolve, these challenges only look set to remain.
In the DevOps Q&A Series by Third Republic, we discuss this landscape with industry experts, and discuss their perspective on the DevOps universe, both past, present and future.
We recently caught up with Aubrey Stearn, Head of DevOps at Arcadia, to hear her thoughts.
Third Republic (TR): Firstly, can you give us an overview of your background, and how you got into DevOps?
Aubrey Stearn (AS): I first started out as a network engineer, back in 2004, because I had a lot of experience programming throughout my childhood and college. During my time in this role I was pretty hands on in doing an Novel/Windows NT4 migration – which was a bit of a dark art at the time – and begun to start writing some of my own scripts to migrate thousands of accounts, permissions and drive mappings, so I guess this was my first experience of the fusion of Ops and Code. I decided to make the jump to pure development and moved to role in a small agency which – due to its size – didn’t have an Ops team, so I actually ended up working as a blend here as well because there were such a wide variety of tasks that needed to be done.
Then, in 2010, I made the move to a FinTech business called Risk First, as a developer and TFS engineer. Risk First eventually had a cull of their teams and made the Ops division redundant, and I was asked to step in in the interim and take over the IT Operations. To be honest, I was initially worried about moving from Development into Ops – this was all before the advent of ‘DevOps’ as we know it now – but decided to step into the role and built a team around me. Looking back, I think I always had that blend of Development and Operations, even though I didn’t realise it at the time, so I guess that’s how I got into DevOps!
TR: And how do you define DevOps?
AS: I think people are generally still struggling to define DevOps; but to me it is platform engineering – or site reliability engineering. I think this is the most prevalent emerging term that we are seeing in regard to what DevOps actually is, and I think this will slowly become more known outside of the industry over time. When we focus on the current problem, we end up being closer aligned to the agile manifesto and able to deliver value much sooner.
TR: Over the past 10 years, what are the biggest changes you’ve seen in the DevOps industry?
AS: I think the shift from native applications to web applications has been huge in the development space, as well as the shift from monolithic style tooling like Microsoft Visual Studio to smaller open source efforts like Visual Studio Code, Atom & Sublime In general, I think Microsoft’s prominence in the marketplace has decreased significantly because of the ease of access, and speed to get up and running on new platforms, and this has definitely been interesting to watch.
The term DevOps has also always remained one of the biggest, but also muddiest, changes. When people have spoken about DevOps in the past they haven’t always understood what they are talking about – some say it’s a culture and others say it’s a tooling. I personally prefer the SRE term; I love the idea of an engineer who can write production code and also practice system engineering whilst distilling that skillset into the traditional development team.
I think something that is still in the process of changing is engineers’ mentality – many are still focused on making something modular or extensible to protect against potential flaws, but I believe that we now have to be engineering for the current problem rather than for what hasn’t happened; we should really optimise for deletion. This principle of engineering for today and not the future is something that is still being recognised.
TR: And looking forward, what emerging DevOps trends are you most excited about, and why?
AS: Definitely just more people buying into what SRE is and understanding that platform engineering is fundamentally the future – and that to get this future you need to be able to code at a production level.
I also think people are slowly understanding that part of the SRE role is educational, and they are placed in a DevOps team to be learnt from. Being able to build a DevOps culture where people are dropping their mentality of being defensive and protective of their area and are pairing up to work together and learn from each other, is definitely becoming more prevalent in the industry and is fundamentally key to the future of DevOps.
I think there is always a gradual change in terms of how we are building platforms, what they look like and what they fundamentally are. This is really an emerging problem in terms of scalability, and a lot of the struggles businesses have at the moment in DevOps is with scaling. Maybe, just like Agile doesn’t lend to scale, development platforms are the same. Personally, I think the future this should lie in a micro platform of sorts; where you don’t have to scale the platform itself. Having this main platform layer with micro platforms that share this layer (or common runtime) feels like the most predominant pattern – and one that a lot of successful companies have leveraged already – and I think it will be interesting to see how this develops as DevOps continues to adapt.
TR: With these trends in mind, how do you see DevOps fitting into the era of digitalisation and digital transformation?
AS: I think we have seen a pattern of businesses trying to do huge platforms, and it rarely working. Especially in digital transformation, where everyone knows they should be doing it but don’t quite know what to do, or they try and roll out huge changes that ultimately fail.
I think DevOps can help establish a mentality of doing something by taking the smallest slice of functionality and using mechanisms like traffic splitting and the strangler pattern to prove new or refactored functionality and value as quickly as possible.
I’ve seen some people just adopting other people’s methodologies for digital transformation and this is definitely a dangerous approach – especially with instances like Spotify’s model which was home grown. Enterprises need to go Dev first and reduce their problem into a smaller scale and then fix it; just like how neural networks strengthen when something is successful, businesses should approach their digital transformation problem by jumping from known to known, rather than trying to do an end-to-end overhaul just because they think they should.
I think adopting this DevOps mentality of devolving something into smaller problems, making it work, and moving away from the thinking of having to deploy a unified set of tools for a full-scale transformation, will be fundamental.
TR: With all these changes, where do you envision the future of DevOps?
AS: I think that your traditional engineers, that are more on the Ops side, will become more niche, and we will see a lot more developers shifting into the DevOps space. It really makes more sense for these developers to be picking up these DevOps skills than traditional Ops people; the traditional barrier of specialist hardware to enter the Ops world is fading away and is become abstracted and codified.
I also think the DevOps bubble will burst eventually, when there is no more proliferation of skills and we recognise this skill set as just being part of development, this will lead to DevOps professionals becoming more of a commodity and cheaper.
TR: So, why do you think there is more of a shift of ‘Ops’ people moving into ‘Dev”, and not the other way around?
AS: Ops has, typically, had a much higher barrier to entry – it’s always been about whether you could afford the kit to train yourself up and get into that world. Development, on the other hand, doesn’t really have kit – with the advent of the cloud, you have abstractions of traditional kit that are represented by code, so that low barrier means cloud ops is incredibly accessible in comparison to on-prem.
What this ultimately means is that if you’re not an on-prem engineer and you want to work in the cloud, you’re going to ultimately need to learn to write code, thus we see the migration from ops to dev.
TR: What must any company must have when setting off on a DevOps journey?
AS: The first thing is a single cloud provider; a lot of companies try to use multi-cloud, but this often conflates an already complicated problem. It’s much easier to start with one thing and then outgrow the requirements, so businesses should start with the smallest thing that meets their current needs and then outgrow it!
The second thing is a very clear idea of what your company is actually trying to solve. Introducing DevOps is great, but you need to know why you are introducing it, and what it is going to bring to your business. Ensure that the problem is both operational AND development related before you decide to just roll in DevOps!
TR: In your opinion, what is the biggest challenge for adopting and scaling DevOps in an enterprise?
AS: Empowerment; I think businesses really have to empower their DevOps teams if they are serious about bringing in this fundamental culture change. For instance, if you want to bring in a CI/CD pipeline, the business needs to empower the DevOps team to deliver on it and educate development to leverage it effectively and safely, and the dev hygiene level needs to be set much higher when you’re pushing new code to real customers multiple times a day.
TR: With 6 years’ experience building teams, what do you think makes a successful DevOps professional?
AS: You need to be able to write production code, and you need to be able to work on the platform application that you are supporting. You can always be effective in the DevOps industry, but to be a rockstar you need to be able to code and that’s the biggest challenge. Too many people have rolled over from the Ops world and say they’re an SRE, but when you question them you find they don’t truly understand what a platform engineer does, or they can only write in Bash or Python. If you want to be successful you now need to truly make yourself a working platform engineer.
TR: And, considering the well documented skills gap in DevOps, what are your current challenges in hiring the people you need?
AS:I don’t think there’s such thing as a perfect hire; I don’t really mind what languages someone can code in as this can all be taught. But I think the struggle lies in finding someone who can be the operational engineer – who provides the solution – and the developer – who will think about things like what a good experience is and how to best leverage cloud components to solve development challenges. This blend is still difficult to find.
TR: So, would you say the skills gap is more skewed towards soft skills than technological skills?
AS: Yes – there is a definite benefit of sitting with people and nurturing them through something they haven’t worked through before. DevOps as a culture is already met with resistance, and I think it’s too easy for DevOps professionals to forget that they are fundamentally orchestrating a culture change. To do this you need be able to push the DevOps agenda forward in the right way, and if you don’t have these skills you just won’t succeed. I believe that technical skills can always be learnt, but it takes the right sort of person to orchestrate DevOps.
TR: What sorts of people do you tend to look for when you hire them?
AS: I generally always look for someone who can write production code, but I’m pretty unconcerned about the actual language they can code in. I’m mostly concerned with finding real programmers who have deployed applications into the real world – that’s always been my primary ask. The other thing I look for is someone who is a fantastic communicator; I need people who can make developers comfortable and receptive into moving into the Ops space, and who can show fallibility and maturity working in a space that is still being defined.
TR: If you could give yourself some advice when you first started your DevOps journey, what would you say?
AS: Be nicer to people! There is huge value in the skills that are non-technical, and I don’t think I realised this until late in the game. I would also tell myself that it’s ok to choose a tactical solution rather than the perfect solution; this took me a long time to willingly accept, because it’s hard for engineers who are perfectionists to learn to compromise, but not doing so can be a hindrance.
