The State of DevOps in 2016 (10-12-16)
This is a short paper I wrote as part of an assignment for a Cloud Computing class. In it, I discuss the state of DevOps technology in 2016 and whether or not all businesses can benefit from adopted DevOps workflows.
Should everyone implement DevOps?
Bob is a C-class executive at a struggling medium sized software solutions consultancy. His software team constantly breaks thinks with each new version, his product's deployment lead times are 6789x times slower than average, and all of his employees blog about how they loathe their jobs. Things are bad. One day, while contemplating about throwing himself out the window of his single-story rented office space, Bob starts reading a presentation that a friend and much more successful businessman emailed him. Bob's eyes dilate, his pulse races, thoughts of imminent success, positive revenue figures, Lamborghinis and not going bankrupt quickly rush through his head. What Bob has just read, the Puppet + DORA 2016 State of Devops Report, appears to detail the elixir to his company's shame-worthy performance: Development and Operations! It would seem as if the secret to increased deployment efficiency, reduced unexpected work, and better employee satisfaction were at his fingertips. As Bob goes into a state of manic frenzy, he receives another emailed document from his friend, this one titled Introduction to DevOps on AWS. Not only does Bob now have a general abstraction of what DevOps entails, complete with juicy statistics and buzzwords for impressing investors, but now he also has a guide to setting up a DevOps workflow for a particular IAAS! Now, with the power of DevOps, things seem like they will go well for Bob. But really, DevOps only might make things better for Bob, because there are a number of key factors that influence the impact of DevOps, such as: 1) the type of product/service Bob's business is producing, 2) the organizational culture of Bob's business, 3) the willingness of Bob and the rest of his team to implement regular technology transformation initiatives in their product's cycle,4) the education/training level of the entire IT team, from programmers to managers, and 5) whether or not Bob is a good manager. It is the techniques and business attitude required for implementing DevOps successfully that makes it as much of an art as a science, since the human factor is just as important as the technical aspect of what goes into it. Regardless of what Bob is doing within the sphere of his technology-oriented company, adding DevOps to his product's development life cycle will almost certainly add some benefit to his business that was lacking in the absence of DevOps, but exactly how much benefit DevOps brings depends upon the preceding considerations and other factors; DevOps is truly a team effort that has to be mandated from the top-down, and also requires a significant amount of specialized education and practical experience to implement effectively.
What exactly are the benefits that a DevOps strategy can provide to a business? It is difficult to specify the exact improvements that can be brought about since DevOps involves a wide range of techniques and specific technologies, but in general, DevOps: 1) enables companies to deploy frequently, recover from failures faster, and have lower failure rates, 2) increased employee loyalty, stemming from increased company efficiency caused by DevOps techniques, 3) less time spent on unexpected work arising from security issues and failures, 4) significant cost savings(1: Brown, 5). How this happens is a combination of management techniques, appropriate assignment of development responsibilities to programmers, and technology. Certain management techniques that are “lean” in nature (as in “lean startups”) are accepted as good DevOps procedures, such as limiting the amount of work in process, using “sprints” of development activity towards an obtainable, short-term goal, and using things like information radiators and scrum boards(2: Brown, 33). These are beneficial since they allow for frequent customer-developer feedback loops, which enables the developers of the product to see the real benefit that the product provides to the end user, which in turn leads to increased employee satisfaction. Programmers also accept the burden of implementing DevOps by “shifting left” the responsibility of quality control in terms of testing and feedback to their individual contributions to the overall product(3: Brown, 23). By focusing on quality control early in the development pipeline (starting at the developers' computers), less time has to be spent down the line once the product reaches maturity. All of this can be facilitated with the use of technologies that tie the above concepts together, in terms of both managerial tasks and technical development/deployment tasks. For example, Amazon provides an entire suite of DevOps oriented programs, such as CloudFormation and OpsWorks, that integrate directly into the workflow using its EC2, Elastic Beanstalk, S3 storage, and other services(4: Chapman, 3). This makes doing things like saving snapshots of the current deployment, creating automated tests, and recovering from failures much easier since DevOps is integrated into the IASS provided by Amazon. A final, and much more attractive benefit of DevOps, resulting from the implementation of techniques and strategies similar to the ones listed above, is the cost savings. By eliminating excess amounts of rework and reducing downtime, companies of a sufficiently large size can save potentially millions of dollars(5: Brown, 45). So, to sum up the benefits of DevOps: smaller, incremental development goals that lead to increased customer feedback, increased employee output and satisfaction, increased product quality, decreased time spent on rework, and savings.
Based on the description of the benefits that DevOps can bring to a business, it seems like the effort to implement the requirements will yield substantial development efficiency and cost savings. But those benefits of DevOps do require an additional layer of complexity to be added on top of/ integrate into whatever existing workflow a company is using. Even so, the significance of that additional layer is dependent on the size and scope of the business / product; not every project needs to have the same amount of DevOps implemented for it to be effective. An analogy that illustrates this idea when differing amounts of DevOps would be appropriate for different projects is the method a person might choose to cross a body of water depending on its size . If the body of water is small enough, such as a swimming pool, a person may simply wish to swim across it. If the body of water is of a medium size, like a lake, then a rowboat or motorboat might be more appropriate, since the person might not be able to comfortably swim the entire length of the lake. If the body of water is large, like an ocean, then a ship and crew may be required to cross it, in order to account for the massive distance and possible rough weather / other hazards. Compare this to IT projects of varying sizes, small to large: a “pond”-sized project may be creating a static web page of small length, a “lake”-sized project may be creating a website with a limited amount of user registration / management, and an “ocean”-sized project may be creating an online streaming service. The static webpage project does not need the same amount of DevOps as the streaming service project, because using the same level of DevOps for each would be akin to trying to cross a swimming pool with a ship or trying to cross an ocean by swimming; it will either be excessive to the point of wasted resources or lacking to the point of not being able to provide gains typical of DevOps. The static webpage project may be able to get away with no DevOps at all, although keeping the collaborators on the same version control repository would could be an example of minimal DevOps for projects of a minimal size. As it follows, the user-management program could implement the management and developer work strategies in addition to version control, while the streaming service project would need to take full advantage of IAAS DevOps services, such as AWS's CloudFormation(6: Chapman, 6). So when Bob implements DevOps for all of his future projects, he can vary the amount depending on the nature of each project.
Given the current state of DevOps, I think It has reached a level of maturity so that it can be implemented by anyone from the largest of companies to the smallest of individual projects, with a caveat attached: the more advanced a DevOps workflow becomes, the more specialized knowledge and employee-management cooperation that is required. Due to these increasing resource requirements as DevOps grows, it would be unrealistic for an individual to obtain the same level of DevOps as a full company like Netflix. But given the flexibility of the tools and techniques an individual/business can use for DevOps, and since it's not an all-or-nothing situation where all DevOps tools need to be used in order for it to be implemented correctly, people can pick and choose which aspects of DevOps they are able to implement and with which tools to implement it. Bob, and most other businesses uninitiated to the DevOps way of doing things, will definitely see some type of improvement if his company adopts DevOps practices, regardless of the size and scope of their projects.
1. Brown, Alanna, et al. State of DevOps Report 2016. Puppet, DevOps Research & Assessment, 2016.
2. Chapman, David. Introduction to DevOps on AWS. Amazon Web Services, December 2014.