What Is Devops

What is Devops? Back in the dawn of the computer age, there was no distinction between Dev and Ops.
If you developed, you operated. You mounted the tapes, you flipped the switches on the front panel, you rebooted when things crashed, and possibly even replaced the burned out vacuum tubes. And you got to wear a geeky white lab coat. Dev and ops started to separate in the 60s, when programmer/analysts dumped boxes of punch cards into readers, and computer operators behind a glass wall scurried around mounting tapes in response to IBM JCL. The operators also pulled printouts from line printers and shoved them in labeled cubbyholes, where you got your output filed under your last name. The arrival of minicomputers in the 1970s and PCs in the 80s broke do wn the wall between mainframe operators and users, leading to the system and network administrators of the 1980s and 90s. That was the birth of modern IT operations culture. Minicomputer users tended to be computing professionals with just enough knowledge to be dangerous. PC users required networks; they required support; they required shared resources, such as file servers and mail servers. I remember being told that no one else is having the problem youre having and not getting beyond it until at a company meeting we found that everyone was having the exact same problem, in slightly different ways. No wonder we want ops to disappear. No wonder we wanted a wall between the developers and the sysadmins, particularly since, in theory, the advent of the personal computer and desktop workstation meant that we could all be responsible for our own machines. But somebody has to keep the infrastructure running, including the increasingly important websites. As companies and computing facilities grew larger, the fire-fighting mentality of many system administrators didnt scale. When the whole company runs on one 386 box (like OReilly in 1990), mumbling obscure command-line incantations is an appropriate way to fix problems. But that doesnt work when youre talking hundreds or thousands of nodes at Rackspace or Amazon. From an operations standpoint, the big story of the web isnt the evolution toward full-fledged applications that run in the browser; its the growth from single servers to tens of servers to hundreds, to thousands, to (in the case of Google or Facebook) millions. When youre running at that scale, fixing problems on the command line just isnt an option. You cant afford letting machines get out of sync through ad-hoc fixes and patches. Being told We need 125 servers online ASAP, and theres no time to automate it (as Sascha Bates encountered) is a recipe for disaster. The response of the operations community to the problem of scale isnt surprising. One of the themes of OReillys Velocity Conference is Infrastructure as Code. If youre going to do operations reliably, you need to make it reproducible and programmatic. Hence virtual machines to shield software from configuration issues. Hence Puppet and Chef to automate configuration, so you know every machine has an identical software configuration and is running the right services. Hence Vagrant to ensure that all your virtual machines are constructed identically from the start. Hence Automated Monitoring Tools to ensure that your clusters are running properly. It doesnt matter whether the nodes are in your own data
center, in a hosting facility, or in a public cloud. If youre not writing software to manage them, youre not surviving. Furthermore, as we move further and further away from traditional hardware servers and networks, and into a world thats virtualized on every level, old-style system administration ceases to work. Physical machines in a physical machine room wont disappear, but theyre no longer the only thing a system administrator has to worry about. Wheres the root disk drive on a virtual instance running at some colocation facility? Wheres a network port on a virtual switch? Sure, system administrators of the 90s managed these resources with software; no sysadmin worth his salt came without a portfolio of Perl scripts. The difference is that now the resources themselves may be physical, or they may just be software; a network port, a disk drive, or a CPU has nothing to do with a physical entity you can point at or unplug. The only effective way to manage this layered reality is through software. So infrastructure had to become code. All those Perl scripts show that it was already becoming code as early as the late 80s; indeed, Perl was designed as a programming language for automating system administration. It didnt take long for leading-edge sysadmins to realize that handcrafted configurations and non-reproducible incantations were a bad way to run their shops. Its possible that this trend means the end of traditional system administrators, whose jobs are reduced to racking up systems for Amazon or Rackspace. But thats only likely to be the fate of those sysadmins who refuse to grow and adapt as the computing industry evolves. (And I suspect that sysadmins who refuse to adapt swell the ranks of the BOFH fraternity, and most of us would be happy to see them leave.) Good sysadmins have always realized that automation was a significant component of their job and will adapt as automation becomes even more important. The new sysadmin wont power down a machine, replace a failing disk drive, reboot, and restore from backup; hell write software to detect a misbehaving EC2 instance automatically, destroy the bad instance, spin up a new one, and configure it, all without interrupting service. With automation at this level, the new ops guy wont care if hes responsible for a dozen systems or 10,000. And the modern BOFH is, more often than not, an old-school sysadmin who has chosen not to adapt. James Urquhart nails it when he describes how modern applications, running in the cloud, still need to be resilient and fault tolerant, still need monitoring, still need to adapt to huge swings in load, etc. But he notes that those features, formerly provided by the IT/operations infrastructures, now need to be part of the application, particularly in platform as a service environments. Operations doesnt go away, it becomes part of the development. And rather than envision some sort of uber developer, who understands big data, web performance optimization, application middleware, and fault tolerance in a massively distributed environment, we need operations specialists on the development teams. The infrastructure doesnt go away it moves into the code; and the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as DevOps.

What Is Devops

Uploaded by

Copyright:

Available Formats

What Is Devops

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

What Is Devops

Uploaded by

Copyright:

Available Formats

What is Devops? Back in the dawn of the computer age, there was no distinction between Dev and Ops.

You might also like