DevOps : Dev for developers, Ops for Operations (i.e. systems administrators), two teams of technicians whose goals have been conflicting since the very beginning. While developers want to release innovative software with exclusive features implying the use of brand new technologies, sysadmins tend to favour the usage of well-known, rock-solid components on their servers.
The DevOps movement started to get momentum in 2009 and is now a key value of an increasing number of organizations. Let’s see what it’s made of and how to make good use of it.
Open spaces, siloed minds
A bit of PEEK, a touch of POKE (and some sticky tape)
Overly complicated, poorly documented code, obscure algorithms, hardware banging through the use of inline assembly, all these where considered kind of OK until the late 80s. Then, when programming became a full blown industry, these techniques proved to be unmanageable in a corporate environment with turnover, team collaboration and outsourcing.
Trolls, goblins…and sysadmins
How do you socialize with your colleagues when you spend a fair amount of your time restricting their accesses, their disk space, trying to gently enforce circonvoluted security policies on them ? The answer is : with difficulty. This is where the caveman system administrator cliché comes from.
Being a sysadmin sometimes feel like being a cop under a dictatorial regime : « don’t write your passwords on sticky notes », « don’t use USB thumbdrives at work », « don’t install software from the Internet »… Sure, most people are mature enough to understand the underlying necessities behind these rules, but overall, it’s not very nice.
My team, our silo : a recipe for civil war
Developers in particular can feel quite frustrated, especially around release time, when last minute tweaks have to be performed in an emergency. The sources of friction are plenty : outdated software stack on the production environment, user rights perceived as being overly limited, unhelping firewall, dusty DNS… The sysadmins versus devs war has been ongoing for decades, a longer lasting drama than the worst sitcom you could imagine.
One main reason for this problem : each team was entrenched, was like in a silo. Conflicting goals and different toolsets made it very difficult to collaborate properly. But the combined forces of Cloud computing, Agile methodology and the need for continuous integration put a lot of pressure on everyone, leading to a much needed breakthrough : DevOps.
Cloud computing, Agile methodology and the need for continuous integration put a lot of pressure on everyone, leading to a much needed breakthrough : DevOps.
« They » left
A shift in corporate culture
Once a company started switching to DevOps, things have to change. Things ? I mean people. The idea here is simple : all departments collaborates and know what others do. Other teams aren’t black boxes anymore, but pieces of a big puzzle.
The rock star developer era is over…
Developers, the code you develop on this…
…will run on this :
I bet you see the difference and you know what it implies : use virtual machines instead of a wild custom environment. Aforementioned VMs should be prepared in close collaboration (i.e. face-to-face meetings) with Ops and mirror the production environment. It’s good for the sysadmins and it’s good for you too. No more versions discrepancies between the development and real world platforms.
…and so is the era of the caveman sysadmin.
On the systems administration side, changes in culture are to take place, too. You have to automate as much as possible, automate everything you can : deployment, provisioning, testing, configuration management, monitoring… Also, start using the same source version control software as the developers. Use it to store templates, scripts, everything you can imagine.
The advent of DevOps marks the end of the rock star dev and caveman sysadmin era.
Is that all ? Devs and Ops be friends and voilà, DevOps ? Indeed, no. Clearly, DevOps is much more of a mindset than a toolset. The most difficult part of DevOps is to ban the use of « they » : you don’t work isolated in a silo anymore, you must make sure that the work you do will be usable and understandable by people outside your team. A magic word is there to help you : « us ».
DevOps is much more of a mindset than a toolset.
DevOps is mostly a process taking place in human beings : you can’t buy a DevOps Software Suite, the change has to occur in people, people with agendas and goodwill. A good way to switch to DevOps is to implement it step-by-step. Let’s talk about that !
You can’t buy a DevOps Software Suite, the change has to occur in the people.
You need some practice
DevOps is teamwork, DevOps is convergence, DevOps is unselfishness. It is « us » instead of « they ».
First step : set goals
You have to set goals in order to help make the DevOps wish come true. These goals can be :
- Establish a standard configuration across your machines, from development workstations to production servers, including building, testing and integration servers too,
- Do your best to get standardized provisioning and deployment procedures,
- Centralize monitoring and access control,
- Use virtual environments like VMs whenever it is possible : they can be duplicated, erased, broken and brought back to life in a snap. They also ensure everyone works with the same software stack,
- Use proven technologies that are known not to break when put under pressure.
Second step : DevOps is more than Dev + Ops
Something that is often overlooked is that DevOps doesn’t just concern the technical staff. Everybody in the company must be involved : Developers, Sales, QA, Systems administrators, Systems engineers, Operations staff, Release engineers, DBAs, Network engineers, Security professionals…
A successful switch to DevOps involves everybody : the wider the cultural shift, the better.
Third step : meetings
Once everybody knows the rules are changing, meetings between teams must be organized. People have to figure out how they will adapt, what procedures they will follow, what tools they will use. Which lead us directly to the fourth step…
Fourth step : tickets, tickets everywhere !
In a DevOps environment, every problem is a ticket. Be it Redmine, Jira, osTicket, whatever, I strongly advise you to rely on tickets instead of e-mails, phone calls or informal conversations to address issues.
Tickets have many advantages : they require people to adequately explain their problems, through the use of standardized input forms, they help materialize a good workflow, they also are a very good way to compute statistics.
In a DevOps environment, every problem is a ticket.
Fifth step : DevOps in view !
By now, you should have :
- Continuous integration (building, testing and integrating your source code and creating release packages),
- Automated deployment, provisioning and testing,
- Standard configuration across your platforms,
- Centralized monitoring and access control,
- Virtual environments in use on developers workstations.
Your development and release process should look like this :
My last words for this article
Raise the cost of internal phone calls
Productivity-wise, phone calls are a disaster : they often break the fragile train of thoughts of people working on complex issues (typically, programmers). Make sure everybody think twice before dialing numbers, promote the use of tickets or e-mails.
Inboxes are not databases
Don’t expect people to keep track of every information hitting their mailboxes. E-mails are fine to send signals or to communicate a small amount of informations, but they can’t beat a wiki, a webpage or a WORD document when it comes to mid and long term knowledge conservation.
Share your knowledge
Learn to write documentation and to talk in public (very useful during daily standups).