50 million code deployments in 2014. That’s 1.5 deployments per second by Amazon’s state-of-the-art DevOps program. While your company may not be quite at this level – few are – you don’t need to be at an Amazon level to make a difference in how your organization delivers software product. However, just taking steps toward this lofty goal, moving the needle just a bit can make substantial differences in meeting increasing business demands for faster, better and more frequent software deployments. Therein lies the need for Modern DevOps.
This article introduces the modern DevOps concept starting with a look back at the relatively plain vanilla days of the mainframe and contrast it to the real world we live in today. We then describe key components and responsibilities of a “typical” DevOps organization, and then close with several benefits your organization can expect from implementing such practices.
Introduction – Just What is DevOps?
On one side of your technology staff you have software development. On the other, operations. Using an analogy taken from the airline industry, think of developers as the team responsible for building the airliner.
Just as designers, engineers, supply chain personnel and mechanics assemble the plane at Boeing or Airbus, software developers build your company’s technology product. Once built, the product must be moved to production and used. Continuing the aircraft analogy, once construction is complete, the plane then has to fly. Afterall, airlines make no money from planes that don’t fly. Likewise, no revenue comes from software failing to make it to production for customers to actually use. It is the operations staff of the airline who keep the plane fueled and flying day-in and day-out. In this case think, mechanics, pilots, flight attendants,
food service and cleaning staff and even air traffic controllers. Similarly, the operations staff at your organization consist of hardware and networking experts, system administrators and increasingly, software engineers charged with maintaining and operating your technology product, making sure that it is available 7 days a week 24 hours a day. This part of the technology department often keeps a lower profile than the development staff, which typically has, or should have, frequent contact with your business users.
Think of DevOps as the intersection of development and operations. Their job is to speed up the Systems Development Life Cycle (SDLC) process as much as possible, thus allowing software developers to focus on what they do best – software development.
The DevOps staff addresses building, testing and promoting technology product to the various platforms, which might include development, test and of course the various stages of production such as staging, limited “canary” deployment and full production.
Back in the day, the day being up through the 1980s, businesses maintained for the most part one computer. Although there were a few clones, the mainframe came from mostly one vendor (IBM), was located in one location only, had one set of users and one client.
The users were internal business units such as Finance, Accounting, HR and Payroll. There were no external users and of course no mobile users, the latter of which would come along in about 25 years. There was a single client. It was green and could produce any type of output you wanted as long as it was green letters on a black background! Yes, a far cry from the Retina displays of today’s Macs.
The mainframe only days both homogeneous and tightly controlled. There was a impenetrable brick wall, so to speak, between the software development staff and the production environment. In fact moving software into production often involved a manual process of filling out forms and giving them to a somewhat surly individual in production control who was the gatekeeper responsible for moving code into the production environment.
Forget the real-time error feedback developers enjoy today, as deploying code to production was often an overnight process. Hey, at least we got to enjoy our evening, even if it was spent in an ignorant bliss of what our coding errors might inflict on us the next day!
From a Members Only Club to the Consumerization of IT
From the 1980s forward we’ve gone from a single Mainframe computer – talk about a “members only” club – to mini computers of the early to mid-eighties. Realize, mind you, that up to this point, IT Operations was a card carrying member of this exclusive club. That exclusivity started to change with the introduction of Windows NT servers in the early 90s. For the first time, businesses had viable options outside of traditional IT. It wasn’t until the mid-90s that “pizza box” style servers used in today’s modern data centers were introduced. Of course, beginning in the late 90s through today we witnessed an explosion of laptops, netbooks and other portables, and today the mobile revolution driven consumerization of IT introduces new phones, tablets and wearables practically by the hour.
Over time as devices increase in both number and type, the ability for business to control production environments, particularly our endpoints, has gone from 100% to practically no control at all, even in an age where mobile device management is commonplace.
Moreover, pressures of speed and scale demanded by businesses today has made that brick wall between production and software development into a modern day Berlin wall; antiquated and mostly knocked down altogether. Unlike yesteryear’s homogeneous world, today’s software operates in a globally distributed environment of on-premise data centers, off-premise cloud and hybrid cloud solutions, including hyperscaled clients in both number and type. As an example, the Netflix video streaming API of today supports over 800 devices, including nearly every smartphone, PC, tablet, set top box and video player on the market today and growing daily in numbers far removed from our single green client of 30 years ago.
As the pace of technological change increases and the mobile revolution marches on, does anyone think this cycle will lessen anytime soon? I doubt it. Business opportunities resulting from technological change will continue and just as we look at our world today as light years ahead of the 90s, we will find ourselves dealing demands that are now impossible to imagine. To that end, techniques for speeding up the software delivery process are required for businesses to compete effectively.
Scale + Speed = the need for DevOps
More machines equal more problems. In today’s technological environment where our operational staff support hundreds or even thousands of physical and virtual machines, the opportunity for problems at the hardware layer are both obvious and substantial.
Constant pressure on technology staff to deliver better, faster and more robust software at breakneck speed often leads to mistakes and shortcuts, which of course result, sooner or later, in broken software. Combining these two factors, scale and speed, tend to break, well, EVERYTHING. Now more than ever business competitive edge depends on our ability to support both ever increasing scale and unrelenting pressure to deliver better software at a faster pace (Edberg, 2014).
Enter Modern DevOps
Today’s modern DevOps environment consists of an amalgam of mostly known and time tested technologies and methodologies. These include Service Oriented Architecture, ITSM processes such as ITIL and MOF, Agile project management methodologies, and above all well understood knowledge of where DevOps fits in the Systems Development Life Cycle (SDLC) process.
As Illustrated in the diagram below developers on the left build products consumed by customers on the right. Between them lies the SDLC consisting of two processes, the Delivery Pipeline and Feedback loop .
The Delivery Pipeline consists of building, or compiling the software, testing the software in as much of an automated fashion as possible, and releasing it into production for use by our customers. Once the product is deployed to production it is monitored continuously for feedback. That feedback serves as raw material for the planning process used by the developers to continuously improve software product. Remember, developers add little to no value participating in the SDLC process beyond doing what they are paid by the business to do – write code. It is this circular SDLC process where DevOps, by alleviating much of the SDLC process from developers, can add tremendous value to the organization. The faster this cycle can be turned, the faster your business can respond to customer demands by delivering software to our customers.
Modern DevOps Responsibilities
Among the many skills necessary in DevOps, I place facilitating communication between development, operations and the business at the top of the list. Additional DevOps is responsibilities include capacity management, release management to include continuous integration and continuous deployment, performance monitoring, automated testing, load testing and auto-scaling, configuration management, self-service environments, and automated provisioning. Each of these practices and more are discussed throughout AskaCIO.com.
Brigham/Amazon, R. (2015, October 15). AWS re:Invent 2015 | (DVO202) DevOps at Amazon: A Look at Our Tools and Processes. Retrieved from https://www.youtube.com/watch?v=esEFaY0FDKc
Amazon, long considered to be a leader in the DevOps arena, shares much of their work through their annual re:Invent conferences. In this video, Rob Brigham describes techniques used by Amazon to speed up the software delivery pipeline
Edberg, J. (n.d.). DevNation 2014 – Jeremy Edberg – How Netflix Uses DevOps for Reliability and Developer Velocity [Video file]. Retrieved from https://www.youtube.com/watch?v=WvpmiGURFYQ
Used in UVA DevOps lecture