I can’t recall the exact time I learned about open source software, but I can certainly narrow down the place. I quickly realized how transformative it could be. In 1996, I was sitting in the tech support department of a large ISP that provided hosting and connectivity to the Fortune 1000. Most of our servers ran Solaris, floppy disks arrived via snail mail, and we applied security updates manually adhering to a regime of updates and invoices prescribed by Sun Microsystems. It was a huge change from my university career of dumb terminals and mainframes.
After a prolonged battle with drivers and configuration, a fellow tech support staffer installed Slackware Linux on a decommissioned computer he snagged from our MIS office. He spent days downloading and installing floppy after floppy of Slackware Linux. Upon his demo, I was instantly mesmerized—it looked like Unix, but he had gotten it for free on the Internet.
The development velocity was astounding, and there was an equally fast-growing community accessible via mailing lists and USENET. Up until this point, operating systems were expensive and tied to expensive hardware. For me, this was ground zero of how software and infrastructure were inevitably going to change.
Shortly thereafter, I was managing a team that developed software and maintained infrastructure. We weren’t by any stretch of the imagination implementing what we would call DevOps today, but we saw the value in providing services and making updates almost on a daily basis. We realized the sooner we got systems in front of our users, the more quickly they could benefit from our improvements. By necessity more than design, we had a single group where developers and operations interacted. Not only did we break the cycle of dependence on proprietary software, we started to break our habits of queuing up changes and pushing to production in infrequent and rigid maintenance windows. The developers explained their requirements to systems and network administrators. We iterated on our internal systems much more frequently and moved at much quicker pace than in the past. It was eye-opening.
Since then, aided by Moore’s Law and the open source movement, things have changed greatly. Sun’s server operating system runs on less than 1 percent of all websites, and the open source Linux operating systems from Red Hat, CentOS, and Ubuntu Linux are pervasive in the data center. Slackware still exists marginally, but within a set of tinkerers and loyalists. Intel's Pentium processors, once the fastest and most cutting-edge silicon, are now the lower-power alternative to Intel's latest and greatest multi-core chips–a big swing in a relatively short amount of time.
The Cambrian Era (or the era of IT abundance)
Over the past 20 years, open source has gone from a fringe movement to a mainstream success. Web giants Google, Amazon, eBay, and too many others to name are growing their businesses on open source software anchored by Linux. There is a huge abundance of free and open source software that ranges from developer tools to application servers. Today 8.8 million developers are collaborating on more than 20.7 million projects on Github that are mostly free and open source. Last year the Apache Software Foundation celebrated 15 years, during which they produced more than 100 million lines of open source code. Not only has the amount of inexpensive, high-quality software gone up, but the cost of hardware has gone down.
Early on, the open source mantra was one of imitation and commoditization. Today, it is "release early and release often, innovate and share." Linux gained success as a Unix clone, but new technologies like Apache Hadoop and Apache Spark are breaking ground in data science. Administrators can spin up low-cost cloud instances in no time and developers can stand on the shoulders of giants leveraging a wealth of free and open source code to build new and different apps.
As server applications became more plentiful, so did tooling. Starting with monitoring tools like Nagios and Cacti, configuration tool Cfengine's operations became easier, and tools started to become more accessible. Now we have a plethora of tools that make it easier to automate and leverage operations and development alike. Buildbot, Jenkins, and Maven are automating test and build. Puppet and Chef have become configuration stalwarts. Saltstack and Ansible are making automation across many systems easier. Additionally, the increasing levels of virtualization make moving and manipulating systems across different infrastructure easier. Docker has set the world on fire as its container system allows us to program portable infrastructure much in the way software developers program software. Even complex tools for complete lifecycle management, such as Foreman, are helping DevOps to manifest itself.
The Renaissance (the rebirth of enterprise IT)
We are entering the Renaissance of IT where we bridge the Middle Ages (the DotCom boom and rapid hardware improvement and software growth) and the modern history of Enterprise IT (proliferation of bring your own devices and cloud). Just as The Renaissance was a cultural movement, so too is our move into DevOps. So what happens when the building blocks (infrastructure and code) become so readily available? The need to update those practices to adapt to current diversity, speed, and scale.
Recently I met with a group of people interested in producing a DevOps Days event. We talked at length about the proposed program and types of talks we wanted to hear. The debate was over technical how-to talks versus talks on culture. As someone who has spent many years thinking about and talking with those immersed in DevOps culture, it might seem over-discussed. The reality is that no matter how cheap the infrastructure or how free the software, DevOps wouldn’t exist without a culture that facilitates it. That’s why I think the movement—just like the Renaissance—relies on enlightened thinkers, such as Patrick Debois, Andrew Clay Shafer, John Willis, and Gene Kim, to spread these ideas.
A driver and proof point of why this works is evidenced by success of the most demanding users developing their own software and following DevOps principles. Netflix's OSS program is an expansive and mind blowing example of how a company realizes that developing its own software gives it an incredible competitive advantage in its ability to hire and develop talent, as well as quickly deliver services. Facebook, Twitter, and numerous others are releasing their software as open source to tap developers and expertise outside of their organizations.
The evolution
Inevitably, when I attend a conference or give a presentation on DevOps, I get an inquiry from a recruiter looking to staff for a DevOps team. I then politely explain that I am not looking nor will I ever be looking for a new situation, especially one where there is a DevOps team—it seems to be contrary to the point. I would rather see an organization in which the culture supports the sharing of information across teams, and that the commitment is to practices that are consistent with not just DevOps, but specifically improved delivery of software and services. The systems and procedures for doing this require careful and continued scrutiny. Even though this movement is new, the adherence to a system that strives for better quality and improved service isn’t. A favorite role model among many DevOps is W. Edwards Deming, an American economist who offered many ideas to this end. Deming once famously gave some sage advice that we in IT would be well to heed, ”It is not necessary to change. Survival is not mandatory.”
DevOps
This article is part of the Easy DevOps column coordinated by Greg Dekoenigsberg. Share your stories and advice that helps to make DevOps practical—along with the tools, processes, culture, successes and glorious/inglorious failures from your experience by contacting us at devops-stories@redhat.com.
2 Comments