What is DevOps?
It's hard to grasp the intricacies of an organization's information technology (IT) department. Most people only have contact with IT as "the computer guy" who fixes laptops and resets passwords.
But who builds the websites you visit every day at work? Who made that clunky timesheet app? And more importantly, are these the same "computer guys"?
The question is now more complicated than ever, due to the rise of a new buzzword you might have seen pop up online: DevOps.
DevOps has been a work organization and project management practice that has become mainstream in the tech sector over the past few years. Today, I will show you:
- What is DevOps, as a portmanteau of "software development" and "IT operations";
- What problems DevOps solves;
- How to think in "product" versus "projects".
Before DevOps, there was IT on one side, and software dev on the other
First, we must establish how applications are built. Take the camera application on your mobile phone. The camera app offers a variety of software features such as the ability to apply filters, crop, share with friends, etc. These functionalities can be seen as an autonomous program, a piece of software that was built, i.e. developed.
Software development applies automation principles to problems using resources provided by a computer: computing (calculations), memory and storage.
On the other hand, your camera app runs on a computer: your device. This computer works with many resources (your lenses, microphone, screens, etc.) thanks to your operating system (Android, iOS). Ensuring the operating system and underlying hardware offer services to applications is typically the role of operations.
Let's put this into an enterprise setting. Imagine now an HR system where you input your time, get your tax information, and request time off. The software development folks care about representing these work-related events into a set of functionalities: an application.
This application must support your whole workplace. It's not as simple as providing everybody with an iPhone. The application must be distributed across many shared powerful computers: servers. The IT operations people ensure these servers work well day in, and day out. They keep the lights on, even in snow storms and earthquakes. Got to fill these timesheets, lest all hell breaks loose.
So, if everybody has a role to fill, why did we need to smash them together in a DevOps setting? Can't they just make things run smoothly?
No. Here's why.
Development vs Operations
Development and operations struggle to cooperate in enterprise settings because they have opposite incentives. Developers typically work on projects where they deliver clear business value in a constrained time interval. Ops work on services that they must keep running over a certain level every day, night, weekend and holiday using the least resources.
I've always seen the development side as people who score goals, and operations as the defenders who prevent the other teams from scoring.
The opposite incentives create tension. In concrete examples, developers will feel exasperated that it takes ops so long to perform an operating system update, or to deliver a new server. Operations people will feel overwhelmed by poorly documented system requirements and angered by weak security by default.
The table below sums it up. Development encourages fast delivery of value and innovation. Once a project is done, developers move on to the next thing. Therefore, their lack of interest in the whole lifecycle of their application becomes their weakness. On their side, operations people tend to become reluctant to change due to their affection for standardization (easier to keep things running smoothly in a uniform setting!)
| Dev | Ops |
|---|---|
| Project-oriented | Service-oriented |
| Finite Mindset | Infinite Mindset |
| Solves business problems | Keeps things running |
| Creativity | Standard procedures |
| Weakness: reluctance to manage lifecycle | Weakness: reluctance to change |
The tensions are so great that the only solution was to bring both functions together as one: DevOps.
Solving problems with DevOps
DevOps as you might have guessed is the incorporation of development and operational tasks within the same team. DevOps creates a new way to work in a unit where:
- Developers can manage their servers and computers, thus allowing them more autonomy and flexibility;
- Operations have more input in how an application is built, deployed, and secured;
By putting all experts under the same roof (metaphorically at least), we ensure both parties communicate. By emphasizing autonomy, applications morph into services. Facebook, for example, is not like your HR system! It has a user profile, a news feed, marketplace, messenger, etc. Every one of these services lives with a DevOps team which improves it daily. By breaking down an application into these smaller units, organizations can suddenly scale to millions of new versions being deployed.
At scale, the mentality change from a switch to DevOps is profound: a business turns itself into a product business rather than a project business.
Products vs projects
A project is finite. It ends. The good side is we usually hold happy hour cocktails after it is delivered. The bad side is that people move on. With software being ultra buggy most of the time, it leaves the poor IT people to figure them out.
Products are infinite. It provides a service (a news feed for example) which needs to scale with the rest of the business. Product managers are responsible to gather customer feedback. Developers keep adding features (news feeds with videos! with AI! etc.) Operations people keep a standardized small environment (this runs on my servers! nobody else is going to mess with these!).
Products generally fit better with cloud computing. An autonomous DevOps team gains from the flexibility of cloud service providers: easier to boot a server when you don't have to ask anybody for a hard drive and wires!
Unicorns and rainbows!
Pretty much, except that the atomized approach can become troublesome at the organizational level. Teams begin to work in silos. Cross-department efforts fail. Resources such as security are spread thin. It's almost inevitable to add a layer of "cross-functional management", which in some cases constitutes disguised bureaucracy.
Maybe our next step is ManaDevOps?