Patrick Niyongabo

Patrick Niyongabo

hit-or-miss: my miscellaneous projects and random ideas

09 Dec 2021

DevOps Methodology

(Disclaimer: I wrote this research paper for the CS554 Software Engineering at Portland State University. I spent around 2-3 days working on this, and found some interesting info on the web that I wanted to share. If you find some typos, and paragraphs or sentences that don’t make sense, feel free to reach out by email. Writing and publishing on this website is my way of learning about new topics, and I would love to get some feedback from anyone who reads these posts.)

Software engineering has evolved and scaled up since the modern home computer was developed in the 70s. Commercial software industry developed as a direct response to that increased demand and to support enterprise activities such as admin tools, payroll, and communication platforms inside companies. As tech companies got bigger, complex and scalable software was needed to automate and improve the long process of writing and testing increasingly-complex software, and then deploying to an increasing number of production environments, from embedded sensors to super-computers, and that is how DevOps practices emerged. This paper is an overview of what DevOps is (section I), how the rise of DevOps relates to the rise of the microservices architecture (section II), the interesting relationship between DevOps and the Agile methodology (section III), the strengths and weaknesses of DevOps (section IV), the state of the current adoption of DevOps practices (section V), the future trends in DevOps (section VI), and lastly some concluding remarks (section VII).

I. What is DevOps?

A portmanteau of two words: development (dev) and operations (ops)1 - DevOps was conceived as a movement to unite the dev teams and ops teams, and respective processes, to align towards the same goals within larger organizations. In the “What is DevOps?” article2, Microsoft defines DevOps as “the union of people, process, and technology to continually provide value to customers”. Simply put, DevOps was born out of a desire to improve efficiency throughout the software development life cycle. According to Sommerville3, there are five steps in the waterfall software development life cycle (SDLC) model: (1) gathering the requirements, (2) designing the systems, (3) implementing and testing, (4) integrating and integrating-testing, and (5) operating and maintaining. The DevOps movement mostly focused on improving stages 3-5, and streamlining the inter-stages subprocesses.

In their 2016 IEEE article4, Ebert et al. describe DevOps as an “organizational shift”. According to Google trends, as illustrated in figure 1, this organizational shift started gaining momentum in the early 2010s, the same time when cloud computing and Agile paradigms also went mainstream. This comes as no surprise as the DevOps methodology relies on these cloud tools and several practices that are common in Agile. This relationship is further explored in sections II and III.

One of the main goals of DevOps is to streamline the process of developing and deploying enterprise software by reducing “the time between committing a system change and placing the change into normal production”5. That goal is achieved by adopting DevOps practices throughout all the stages of the software development life cycle. According to Liming et al6, that includes:

  • Verifying that the DevOps pipelines work at initialization.
  • Designing a system architecture that makes it possible to adopt DevOps practices, mostly in the form of micro-services and small incremental changes.
  • Making the system easily configurable pre and post-deployment.
  • Implementing a monitoring system, and rollback mechanisms.

II. Microservices Architecture and DevOps

Among these above-mentioned practices, the most important one is the adoption of DevOps across the tech industry has been the migration of organizations to a micro-services model, and the related organizational shift from waterfall models to agile development. These two shifts embraced the concept of developing, testing, and developing incremental changes that could be easily rolled back, and that wouldn’t take down the whole ecosystem if something went wrong. Microservices make it possible for different components and different layers of the tech stack, to interact through defined APIs, with varying responses that the calling (consumer) service can interpret and handle without relying on the serving (producer) service to always be up and running.

The adoption of micro-services has resulted in the rise in usage of REST (representational state transfer) APIs. REST APIs define protocols of integration between two components: a consumer and a producer7. The REST architecture makes it easy for different components within a system to interact with each other, and transfer data from where it is stored (database) or generated (computation engine) to the customer-facing layers (web-apps and internet browsers). As the system grows in size and complexity, the interactions multiply, and they require strict rules to be set in order to define what a consumer service is supposed to send when requesting some information, and what a producer service is supposed to send back as response. In addition to the basic structures of the data being transferred, REST APIs can also define security parameters (tokens, keys, cookies, etc), APIs versions, and other miscellaneous parameters that make those interactions more efficient.

In modern web systems, most REST APIs are implemented using standard HTTP methods8 (GET, POST, PUT, DELETE, PATCH, OPTIONS) that define operations on resources that are stored in particular locations called “uniform resource identifiers” (URIs). In addition to the HTTP methods, the HTTP protocol also defines “HTTP response status codes”9 that describe whether a certain request was successful or not. These response codes are split into five main categories. Those categories are listed below with examples of the most common codes:

  1. Informational responses (100–199): 100 Continue, 101 Switching Protocols, 102 Processing, 103 Early Hints

  2. Successful responses (200–299): 200 OK, 201 Created, 202 Accepted, 203 Non-Authoritative Information, 204 No Content, 206 Partial Content

  3. Redirection messages (300–399): 300 Multiple Choice, 301 Moved Permanently, 302 Found, 303 See Other, 304 Not Modified

  4. Client error responses (400–499): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 409 Conflict

  5. Server error responses (500–599): 500 Internal Server Error, 501 Not Implemented, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout, 505 HTTP Version Not Supported

    Each category can be received and handled by the calling service by either consuming the received data if the call was successful, making another call if the resource has moved or there was some ambiguity in the previous request, or fixing the request if the previous request failed because of the client error, and handling the error in a pre-defined manner of there is a server error.

III. Agile Methodology and DevOps

While the Agile methodology tends to focus on flexibility and Devops “emphasizes on continuous integration”10, the two methodologies share a lot of similarities. These similarities include the focus on getting the product to the customer as fast as possible, and getting some feedback before incrementing and adding more features. This is achieved by improving all the stages in the software development life cycle from planning to maintenance, and the increased use of automation and communication tools to streamline processes. Whether it is a project-management tool like JIRA or a teams communication platform like Slack, DevOps teams tend to develop integrations for those tools (alerting, deployment updates, pull requests statues, etc) that make it easier for the developing teams to follow the proper guidelines of the Agile process.

Ebert at al. classify DevOps tools into six categories11, category 2 and 3 are sometimes classified as CICD (continuous integration, and continuous deployment):

  1. Build tools
  2. Continuous-integration tools
  3. Deployment tools
  4. Logging tools
  5. Operations tools
  6. Monitoring tools

To take an example, let’s say a build fails some integration tests during the deployment pipeline. DevOps tools would automatically cancel the build, (and rollback to the previous successful build), and then the next step would be to notify developers by either sending an email, or a message to the slack channel of the team that own the microservice that was getting deployed; another common integration is to mark the associated JIRA ticket as ‘requiring attention’ so that it can be moved back to the development or testing stage, and if necessary, so that follow-up tickets can created.

Another aspect of DevOps that helps in the adoption of the Agile methodology is the collection of metrics and other data points that make it easy for developer teams and managements to evaluate previous development cycles and make data-backed decisions on how to improve existing processes or whether to adopt new ones. These metrics are collected using version control tools like git or aggregated using log collections tools like Splunk, and later visualized in customizable dashboards. These dashboards are crucial as they can easily be interpreted by non-software teams and management or non-technical members of the development teams. This makes it easy for organizations to communicate using data metrics as conversation starters, and making sure that everyone is aware of current trends (percentage of errors, code unit-test coverage metrics, alerts and deployment failure rates, etc) across all software components at any given time.

The transparency and visibility of Agile is inherently supported by the DevOps processes, and it is one of the main things that attract Agile teams and organizations to switch to the DevOps model. In the next section, the strengths and weaknesses of DevOps are discussed in more detail.

IV. Strengths and Weaknesses of DevOps

Throughout the last decade, DevOps has supercharged the growth of the software industry, and contributed to the increased efficiency of IT departments in all sectors. This is attributable to the strengths of DevOps as a process, and all other efficiency measures that have been introduced in the software development processes. Obvious examples are the Agile methodology and the microservices architecture, but there are other equally-impressive measures such as the adoption of instant communication tools and the standardization of web protocols.

During the recent adoption of DevOps, developers and other stakeholders have noticed that DevOps is suited for some use cases more than others, and its strengths and weaknesses as a novel technological methodology have been documented and explored over the years.

Notable advantages (strengths) of adopting DevOps practices according to Maria Aleksandrova, a blogger dzone.com, are listed below12:

  1. Reducing the “chance of product failure” by continuously testing and getting and acting on customer feedback
  2. Improving “flexibility and support” by making software more scalable and easy to maintain
  3. Cutting down the time it takes to bring products to market
  4. Increasing team efficiency as all team members have complete ownership of the code they write even after it is deployed in production
  5. Increasing understanding of the product and making processes more transparent

The above-listed advantages of adopting DevOps can only be realized if DevOps practices are adopted diligently and correctly. Failure to do so can lead to unintended consequences.

In addition to the advantages, Aleksandrova also lists three main challenges that make it difficult for organizations to practice DevOps13. Those challenges are listed below with various guidances on how to address them:

  1. “Transitional challenges”: Depending on the existing software stack and codebases currently deployed in production, some organizations may face several challenges when they try to switch to an automated CICD workflow. One way to tackle this challenge is to start small by building proof-of-concept projects and deploying them incrementally in different environments, then slowly start transitioning non-critical components; and once the organization is confident in the new DevOps pipelines and processes, teams can start transitioning critical services and products.
  2. “Lack of talent”: As DevOps is a new field, there aren’t many experienced developers out there who have the knowledge and skills required to develop, use, and maintain DevOps tools. This has made it difficult for small and non-IT companies to adopt DevOps as they are competing with big tech companies for talent. One potential solution is to have internal training, or sending them to workshops and annual conferences where they can interact with other developers. Additionally, technical content, software related documentation, is increasingly freely-available online, making it easier for anyone who wants to learn to have unlimited access. Self-paced learning and hands-on practice should be encouraged by organizations, small and large, who want to stay ahead of the curve when it comes to DevOps talent.
  3. “Toolset choice”: The abundance of tech stacks and DevOps tools from which developers, teams, and organizations can choose from can be overwhelming. With increasing personalization and customization, there is a high chance that the combinations of tools that an organization chooses first won’t work as planned. That is why experimenting is important. By trying out different tools, and getting feedback from developers and other stakeholders, organizations can pick and choose what works best without having to over-spent or waste valuable work-hours on tools that do not work.

Overall, the pros and cons of DevOps vary from one team to another, and from one organization to another. The tools that work for a five to ten people startup will differ from the ones that work for a large university IT department and a multi-regional hospital. The underlying methodology of DevOps remains the same though, and its advantages as discussed in this section are obvious, as are its adoption challenges. The next section continues to explore those challenges, focusing on the biggest two transitional challenges: legacy software and data migration.

V. Adoption of DevOps Practices

The shift towards adopting DevOps practices in day to day operations of development teams has been largely driven by developers through online forums and communities; and by vendors and consulting services14. These services who usually develop products that can be used as DevOps convince organizations to switch to their tools usually through initial trial programs, and later through paid subscriptions.

The main challenge faced by organizations and teams trying to switch to DevOps is migrating legacy code. The DevOps pipelines are well-suited to the microservices architectures and modern application development which tend to be versioned and where rolling back to the previous stable versions is a feasible option. For most legacy software, these kinds of metadata and configuration layers are missing and they are encapsulated in other legacy tools, making the process of migration not only cumbersome but also expensive as some of those are paid.

Another big challenge to migration is data migration. Most legacy systems interact with data that is stored in legacy database systems. Migrating these database systems or integrating them into the new DevOps pipelines can be costly, and there is a perceived increased risk of data loss or data breach that make some companies hold off the process indefinitely. These privacy and security concerns are similar to the ones expressed by companies that haven’t migrated their infrastructure to the cloud, believing that on-premises infrastructure is more secure. Several data breaches in recent years have proven this to be false, and it is likely that we will continue to see more organizations switch to cloud, and adopt DevOps practices, in coming years. These future trends and other likely future scenarios in the DevOps are discussed in the next section.

VI. Future Trends in DevOps

As more companies and organizations continue to adopt DevOps practices and the Agile methodology, DevOps will become mainstream, and it will start to be taught in computer science classes. However this is not guaranteed. As we have seen in the last few decades, the tech industry relies heavily on innovation and disruption to keep its momentum going, and I wouldn’t be surprised if there was another momentum shift in the next five or ten years. Assuming that DevOps adoption will continue on its current trajectory, listed below are the likely trends to look for in the coming decade according to Hussain at el15:

  • Increased specialization in knowledge areas such as “cloud & network infrastructure” and “Continuous Integration and Delivery and Deployment”
  • Increased development of DevOps technologies similar to existing build tools such as Docker and Jenkins, or configuration tools such as Puppet and Ansible
  • Increased popularity of scripting languages (and other languages that are used in DevOps pipelines) such as Python, Javascript, Perl, and Bash
  • Increased demand of human capabilities that work well with the DevOps methodology - similar to the Agile effect, organization will look for flexibility as key attribute when making hiring decisions
  • Creation of more DevOps specific job titles such as DevOps engineer, CICD engineer, build engineer, cloud testing engineer, et cetera

VII. Concluding Remarks

Innovation and disruption in the tech industry, and the increasing demand for software products and skills in recent years created an environment which made DevOps possible. The rise of quasi-similar culture shifts in the adoption of Agile across the industry, and the ongoing transition towards the microservices architecture, lent momentum to the growth of DevOps; and in turn, DevOps accelerated the adoption of those methodologies.

This positive feedback loop is part of a bigger digital transformation that has made the tech industry more robust and profitable16 as it has lowered the barrier to entry for teams whose main goal is to bring their products to the market as fast as possible and get immediate customer feedback before iterating and repeating the process until their products are stable and mature.

Traditionally this “build fast and break fast” mentality has been embraced by startups and purely tech companies but in light of its success, it is likely that other organizations will also start embracing this mentality which involves following the DevOps practices. It is still early to tell if DevOps will continue to grow, or if other methodologies will take over, but as of now, it looks like DevOps is here to stay.

Citations

  1. https://devops.com/the-origins-of-devops-whats-in-a-name/ ↩︎

  2. https://docs.microsoft.com/en-us/devops/what-is-devops ↩︎

  3. I. Sommerville, Software engineering, 10th ed. Boston: Pearson/Addison-Wesley, 2004, pp 47-48. ↩︎

  4. C. Ebert, G. Gallardo, J. Hernantes and N. Serrano, “DevOps,” in IEEE Software, vol. 33, no. 3, pp. 94-100, May-June 2016, doi: 10.1109/MS.2016.68. ↩︎

  5. L. Bass, I. Weber, and L. Zhu,_ DevOps: A Software Architect’s Perspective_, Addison-Wesley Profes- sional, 2015. ↩︎

  6. L. Zhu, L. Bass and G. Champlin-Scharff, “DevOps and Its Practices,” in IEEE Software, vol. 33, no. 3, pp. 32-34, May-June 2016, doi: 10.1109/MS.2016.81. ↩︎

  7. https://www.redhat.com/en/topics/api/what-is-a-rest-api ↩︎

  8. https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html ↩︎

  9. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status ↩︎

  10. Mohammad, Sikender Mohsienuddin, DevOps Automation and Agile Methodology (August 3, 2017). International Journal of Creative Research Thoughts (IJCRT), ISSN:2320-2882, Volume.5, Issue 3, pp.946-949, August-2017, Available at SSRN: https://ssrn.com/abstract=3655581 ↩︎

  11. C. Ebert, G. Gallardo, J. Hernantes and N. Serrano, “DevOps,” in IEEE Software, vol. 33, no. 3, pp. 94-100, May-June 2016, doi: 10.1109/MS.2016.68. ↩︎

  12. https://dzone.com/articles/benefits-and-challenges-of-taking-the-devops-route ↩︎

  13. https://dzone.com/articles/benefits-and-challenges-of-taking-the-devops-route ↩︎

  14. C. Ebert, G. Gallardo, J. Hernantes and N. Serrano, “DevOps,” in IEEE Software, vol. 33, no. 3, pp. 94-100, May-June 2016, doi: 10.1109/MS.2016.68. ↩︎

  15. W. Hussain, T. Clear and S. MacDonell, “Emerging Trends for Global DevOps: A New Zealand Perspective,” 2017 IEEE 12th International Conference on Global Software Engineering (ICGSE), 2017, pp. 21-30, doi: 10.1109/ICGSE.2017.16. ↩︎

  16. Wiedemann, Anna, et al. “Research for practice: the DevOps phenomenon.” Communications of the ACM 62.8 (2019): 44-49. ↩︎

Tags

agile cloud-computing devops microservices