Agility and flexibility
It is important to provide a concrete definition of DevOps first otherwise it exists as an amorphous term. I define it as reducing the amount of friction in the processes we have between developers and customers.
The role of a DevOps is typically focused on introducing agility and flexibility to build and deploy – and fail – fast. The aim is to deliver business and generate value to our customers. To get the right application management strategy in place to provide these business needs comes down to continual integration.
Adopting a continuous release and an operational mindset are important, even for software that is legacy and mainframe. We want to be constantly releasing incremental improvements to the software, thereby making things more secure, increasing performance and tracking KPIs.
The best of both worlds
More established financial services businesses are averse to going ‘all-in’ on the cloud, instead choosing to part-focus on modernising their traditional data centres and to make them more efficient and secure.
This attitude will naturally impact DevOps and create difficulties. Yet, this is nothing to be alarmed at as I think it is a simple matter.
Most people conflate the terms cloud with public cloud exclusively and that is a mistake. Cloud is a mindset and an experience. It can be driven from private or public – and ultimately where we want to end up, a hybrid cloud scenario. This is a blended model offering the best of both worlds. It is also the most favourable option for capex and operational expenditure control.
The truth is that the public cloud represents several different proprietary silos. For example, Azure is not translatable to the work of Google Cloud or AWS. The work you do on-prem does not directly relate to all these things – not without lock-in. Therefore, to be cloud ready you need to be cloud agnostic, which means trying to make sure the
infrastructure is not the barrier and that data centres are just another aspect of your cloud.
Let me be more succinct. Infrastructure is how we get things done. We need to host our applications and processes, however, the days of tying all that to one provider are over. It’s not always possible, and it’s not always desirable, but as a design principle it should be the goal – and this strategy makes you cloud ready.
Unsurprisingly, the challenge is trying to get to that state. It won’t happen overnight, but if you start now and work towards it, then you can embrace the best of breed market for tomorrow.
Removing misconceptions around DevSecOps
People often talk about DevOps and DevSecOps independently. It’s a horrible misconception that a lot of people are happy to perpetuate.
DevSecOps is a noble and essential initiative that entails bringing more security into our processes to deliver value between developers and customers. But to distinguish it from DevOps is just false posturing. DevOps is the mindset for how we get things done. So DevSecOps is always implicitly a part of it.
There are a variety of terms out there – NetDevOps, Rugged DevOps, and so on. These are all just part of DevOps and part of the drive to ‘get things done’ – and certainly not separate to it.
Security is part of the absolute design, testing and automation of the development build. This needs to be the same test for monitoring and production, so we are shrinking the distance between development and production. If you can reduce friction between the developers and customers, that’s the horse we want to ride in on.
Catching security breaches in deployment
In DevSecOps there is the need to catch security breaches in deployment earlier, namely the reduction of mean time to detection (MTTD).
We want to get out of a reactive stance of adding security in production to detect what has happened. That is too late in the process.
The more intelligent practice is to get security implemented in development. For instance, in the test buffer overflow. Test that with every build and make sure to validate every build. The entire stack needs to become part of this security analysis.
Check nothing is built on outdated systems when apps are deployed. It is vital to build in metrics and instruments as part of development so if something should happen – such as API usage exceeds normal levels – this could be a clear trigger that a security breach has occurred.
By going to this proactive design and testing method, the production monitoring becomes just another aspect of development testing. This means we have ultimately shrunk the distance between both.
Expanding influence within financial services
I can happily end on a positive as DevOps’ expansion and influence within financial services over the next three to five years is inevitable.
Today it is viewed as a very technical domain, with its tools and new methodologies. But that’s just the current attack surface of where we’re making the most influence. I see it becoming a ‘Zen thing’ – a shared value that brings down silos of responsibilities.
DevOps will not evolve into a technical domain, but ultimately into a full business domain. This will make it less technical and more of a mindset that can be expanded to colleagues and business sponsors. If they understand and embrace this concept, and if we make them partners in our reformation and sustainability, then a financial services business can run as efficiently as possible and release value to the customers.
Mark Lavi is a DevOps, Internet, and service engineering expert, and now the Principal DevOps Advocate at cloud transformation specialist, Nutanix.