DevOps has come a long way in the last 10 years. From its humble beginnings at a tech conference in Toronto, Canada the mash-up between development and operations has grown into a major focus for businesses all over the world.
Today, more than 70 per cent of companies claim to have adopted DevOps, and it’s easy to see why.
The latest State of DevOps report from the DevOps Research and Assessment (DORA) team showcases the incredible impact it can have on your software development cycle. By comparing low performers with those at the very top, the report found that elite performers have:
- 46 times more frequent code deployments;
- 2,555 times faster lead time from commit to deploy;
- Seven times lower change failure rate;
- 2,604 times faster incident recovery.
Sadly, most organisations are failing to hit these numbers. Here’s five key ways businesses are still getting it wrong – and what they can do about it.
1. The culture clash
The first hurdle companies face is the huge task of changing their internal culture. In most cases, development and operations have worked in independent silos for years, speaking different languages in different domains with completely different ways of working. So when they suddenly come together without the right people around them, the business suffers.
“It’s about bringing together dev, ops, security, marketing and many other specialisms and aligning them on one shared objective”To make matters worse, leaders are often reluctant to take the necessary risks to drive positive change and innovation. Instead, they possess a command-and-control mentality that can make something as simple as downloading a new piece of software a headache for employees.
So what’s the solution?
First, businesses need to understand that DevOps is really about creating product teams. It’s about bringing together dev, ops, security, marketing and many other specialisms and aligning them on one shared objective: to improve your customer experience. But for this to really work, leaders need to change legacy processes, give teams more autonomy and adopt the fail-fast mentality that makes DevOps so successful.
2. It's all about speed
In today’s business landscape, time is money. Companies are facing growing competition from lightning-fast startups, so teams are constantly looking at ways to improve efficiency and productivity.
DevOps is a massive part of this. It enables teams to automate processes and speed up cycle times so they can get products to market faster. But what happens when teams get blinded by the race to the customer? What happens when your time to market becomes the only metric that matters? In short: quality suffers.
We often describe DevOps as a balancing act between speed and quality. Speed is great until quality starts to suffer, and quality is only worthwhile if you can reach the customer in a reasonable timeframe. To truly get the best of both worlds, you need to automate your software engineering, and measure and report key metrics from both the pipeline and the running system, such as MTTR, MTBF and test coverage. Nothing should be manual.
3. Security gets forgotten
Security is an essential part of IT. But when teams focus all their attention on faster deployments and shorter cycle times, it often gets ignored until it’s too late.
“By making security part of the DevOps mix you can help instil a security mindset in your developers”This is often the result of a partial DevOps implementation. Developers and operations are brought together to speed up time to market, but when the product reaches the customer, it has a whole host of security vulnerabilities that the team missed. This not only leaves you exposed to a breach, it also means teams have to rapidly identify affected customers and services before rolling out a series of last-minute fixes.
We help teams prevent this issue by integrating security processes throughout the development lifecycle. And, by making security part of the DevOps mix – often referred to as DevSecOps – you can help instil a security mindset in your developers to further strengthen the stability of your output.
4. Teams think there's a magic tool for DevOps
As an Atlassian Silver Solutions Partner, we understand the power of great tools. They can enable collaboration, automate processes and improve efficiencies throughout the development process. If, however, you’re looking for a tool to improve areas such as productivity and collaboration to make all your DevOps dreams come true, you’re not going to find it.
“This is one of the biggest misconceptions when it comes to DevOps. Many businesses buy into a tool thinking it’s their DevOps solution – either because its benefits have been hyped-up by an overzealous salesman, or simply because they don’t fully understand what DevOps is.
5. The cloud becomes a fog
We’ve all heard the benefits of the cloud before. It treats computing as a utility rather than a USP, does away with the burden of supporting your own server room and helps to reduce your time to market. Although, all of these should come with one big caveat: the cloud alone won’t solve all your problems.
It’s a common misconception that the cloud is a like-for-like swap for traditional infrastructure. So when teams take on their first cloud project, many parts of the organisation don’t understand why the need to adapt – and this includes leadership teams. Instead, developers are only able to execute a half-baked adoption, so rather than realising the benefits of the cloud, they end up lost in a fog of disillusionment.
“It’s a common misconception that the cloud is a like-for-like swap for traditional infrastructure”If you really want to get the best out of what the cloud has to offer, then leap as far up the cloud curve as you can in one go. If you can use serverless compute now, do it.
However, not everybody can take such a leap but almost all companies we see can get a huge boost by migrating from in-house infrastructure to Platform-as-a-Service offerings such as managed databases, app servers and messaging.
The fact is, if you’re considering doing a ‘lift-and-shift’ from physical to virtual, you’re already too late, and you need to think again about chopping your application up into manageable components, or just using a Software-as-a-Service product to replace it.
