Section 1: Introduction
DevOps is a more intelligent, nuanced way to release applications.
If you’re like me, you’re probably a bit tired of hearing about DevOps. Sure, the word DevOps is often misused and misconstrued in the IT community. At its most basic, it doesn’t mean much more than “Software Developers and Sysadmins working together,” right?
It turns out that DevOps can be a useful framework for thinking about all sorts of problems in IT. And although some people misuse the word DevOps, you don’t have to be one of them. The engineering community is in need of people like you: people who want to get to grips with what DevOps really is, rather than talk about it.
Breaking away from Buzzword Bingo
Let’s start by acknowledging the elephant in the room – the software industry has a love of using the same words. Before DevOps came along, you were probably using words like “Scrum” and “Agile Operations” over and over again.
Agile was pitched as an alternative to “Waterfall” – where projects are defined by business executives, designed by middle managers and architects, and handed over to operations and testing. Engineers tend to find Waterfall quite demoralizing – they’re only involved when the important decisions have already been taken, and cannot be unmade.
And, as it turned out, Agile got a lot of things wrong too. Agile still meant that business decisions are passed down from on high, it micromanages talented engineers, and can be dangerously short sighted. But it did get one thing right: it got Software Developers and Sysadmins talking to each other.
The reason why DevOps gets engineers twitchy is that it sounds a lot like the kind of business-babble that gets thrown around in presentations. Kaizen. OODA. Muda, Muri, Mura. They worry that they’re about to be measured on an hour-by-hour basis on their productivity.
DevOps is a major improvement on Agile: DevOps describes a culture, rather than a process.
What Does A DevOps Engineer Do?
Although DevOps describes a culture rather than a function that someone performs, DevOps is in demand. A recent study by Puppet Labs found that companies that employ DevOps deploy code up to “30 times more frequently than their competitors, and 50 percent fewer of their deployments fail.”
Over the last five years, there has been a 75,000% increase in the number of DevOps jobs posted at Indeed.com. A 2014 survey of IT managers in the U.S, U.K and Australia found that those of those that hadn’t yet deployed a DevOps strategy, 79% were planning to do so by the end of 2015.
A DevOps engineer isn’t a combination of a Developer and a Sysadmin in one role: the respective roles of Developer and Sysadmin aren’t going anywhere any time soon. But developers are increasingly expected to pick up cloud monitoring tools alongside Ruby and Python, and sysadmins are slowly, begrudgingly, leaving their beloved bash scripts behind.
Fundamentally, it’s about helping IT succeed in a new world where infrastructure is defined and built by APIs, and where the developers’ responsibilities do not end with building the code.
In practical terms, this means that everyone is on the same page. Developers and Operations can work towards a common objective with reduced reliance on flowcharts and Trello boards. Communication might happen through a Slack chat or a GChat rather than a formal change request. And Developers and Operations understand each other’s work because they share the same tools.
How Is DevOps Changing The World Of Software?
Implementing DevOps is what you make it. DevOps provides both Developers and Operations with a lot more freedom and autonomy: though what you do with them is entirely up to you.
It’s perhaps easiest to explain DevOps by comparing it to the old world of Developers and Operations. In the old world, developers would be rewarded and measured by the frequency with which they got new features into the hands of customers.
However, because sysadmins digest with their baby food the tenet that their job is to minimize risks and errors in the stability of the system, there was a resistance to change.
Sysadmins are coming to understand that in order to be a good sysadmin, you have to be a capable developer. After all, you will be running, maintaining and caring for the apps that they are working on.
Good sysadmins are now capable of disassembling and fixing programs that have been built by other developers, diagnose issues in many runtimes, and understand kernel subsystems.
Equally, technologies such as Docker mean that developers are gaining knowledge of networking, even if they don’t intend to run their own networking equipment.
This is changing the culture of IT departments: sysadmins are becoming more comfortable with a world that does not rely on perfect stability, change management committees and outage windows; as a result, changes are becoming smaller and more frequent, but well-tested.
When deploying to production is no big deal, it can have a profound impact on the trajectory of an IT organization.
- DevOps is a term for a group of concepts that, while not all new, have catalyzed into a movement and are rapidly spreading throughout the technical community.
- DevOps came about because of an increasing need for innovation on the systems side of technology work.
- It’s a misconception that DevOps is coming from the development side of the house to wipe out operations.
How DevOps Can Support Your Business
So, we’ve talked a little bit about what DevOps is (and isn’t). We’ve thrown out a couple of misconceptions about Agile. And we’ve explored how the old world of Development vs. Operations is changing.
But we haven’t yet talked so much about how you can change your IT focus to really benefit from DevOps. One common mistake that we see people making is implementing the tools and processes of DevOps without having the principles in place first.
Indeed, with all the major technology suppliers and analysts warning about the dangers of failing to adopt a more agile approach, you may be wondering how you can overcome the business and technology barriers to DevOps adoption yourself.
And certainly, if your organization is stuck in old ways of working, it’s not just a case of saying “We’re doing DevOps now” and getting back to work. You need the buy in of the entire IT department. You’re quite likely to need an executive sponsor too.
And, almost certainly, the monikers of ‘Dev’ and ‘Ops’ are gross simplifications when it comes to describing your organization. The terms ‘Dev’ and ‘Ops’ tend to describe a variety of different job functions, who, in and of themselves, may not have much to do with each other on a day to day basis.
Even if you can get the right tools and processes in place, getting DevOps up and running normally requires a culture change too.
Case Study: Ordnance Survey
Ordnance Survey is renowned for its paper based maps, but also develops software for the iOS App Store, in house teams, government agencies, utility companies and building firms.
Ordnance Survey adopted DevOps as a way of improving communication and collaboration between its various teams.
In the past, Ordnance Survey ran a software infrastructure team, and a second team that was in charge of provisioning environments.
They found that customers were becoming increasingly dissatisfied with the service that was being provided. Ordnance Survey’s infrastructure team could not keep pace with demands from developers, meaning long lead times in providing them with environments.
These environments were also created in a manual way with semi-automated scripts – meaning that not only did the environments take a long time to provision, they weren’t always the same.
As a result, there were often disagreements between the development and infrastructure teams, as the environments provided weren’t always up to spec.
To solve the problem, Ordnance Survey created small ‘squads’ of developers and infrastructure architects. They also did away with the ticketing system that had been previously used to communicate between these groups.
Teams often find that simply sitting in the same room can be a boon for productivity – infrastructure architects see the requirements of developers, but come to understand that they are real people too!
Plan to be Cloud-Ready
DevOps is more than just culture change, though. There’s no getting away from it – being DevOps ready may sometimes require overhauling your IT infrastructure. Many analysts highlight moving to cloud as an important first step in this process.
Cloud can present a challenge to regulated enterprises, who may not be able to adopt it at the speed they wish. However, all businesses should now be looking to assess which parts of the IT organization can be moved to cloud.
Cloud provides DevOps teams with quick, on demand access to compute resources, giving them a level of agility than on-premise simply cannot match.
Plan For Results
Acknowledge that there will be DevOps sceptics within your organization. The best way to prove the doubters wrong is to line up a small, but non-trivial project that lends itself well to a DevOps approach, and encourage your team to get stuck in, treating any pitfalls as a learning experience.
Instead of tackling DevOps as a conceptual exercise, it’s critical to get people from across the IT stack working on one thing. The benefits and results will rapidly become apparent. This will also be useful for winning over sceptics in senior management who may be fearful about the impact on the rest of the organization.
The benefit of DevOps is that – with the help of automation – you can simultaneously increase quality, innovation, and make your products more consistent. As an executive, these things are hard to argue against.
The Role Of Automation in DevOps
“The technique, method or system of operating or controlling a process by highly automatic means, as by electronic devices, reducing human intervention to a minimum.”
Ten years ago, deployment might have meant copying code to the one server that was connected to the Internet. Back then, lots of people were able to get away with using manual processes (though it was probably still fraught with issues.)
Today, there’s a rat’s nest of wires, servers, VMs, proxies, load balancers and firewalls for you to take care of!
In that time, we’ve seen how Dev and Ops teams have started to work together. But developers aren’t going to become sysadmins overnight, and sysadmins aren’t about to hand over the keys to the kingdom!
Automation is the key to holding the equation together. Automation provides trust and reliability, and binds the two teams together during the production phase.
Over the last five years we’ve seen large chunks of the deployment process becoming automated – including development, testing and all of the sub-processes within. Crucially, all of these tools need to be able to talk to each other through software integrations or APIs.
The role of tools
Whether you’re dealing with 2 or 2000 developers, tools are essential to ensure that the work that you’re doing joins together at the seams.
A centralized build system will merge all the development code into a shared codebase and then integrate with various test and deployment systems to validate the code.
Vendors in the build space include:
Today, testing is integrated into the development process both locally and at the central build server. This helps ensure an issue-free code base.
Tools in this space may include:
Continuous Integration should happen frequently enough that no errors can arise in the compilation or testing of the code without developers noticing and correcting them immediately.
The typical practice is to trigger a build every time code is committed to a revision control system, rather than periodic scheduled builds.
To achieve this, CI relies on a code repository, build automation, build self-testing, commits auto-build, and having a replica of the production environment to perform tests. Vendors and tools in the CI space include: