DevOps has been a trending topic for quite a while now and has managed to draw the attention of technology professionals and enterprises alike. As a beginner, it can be challenging wrapping your head around the concept of DevOps, and in this topic, we will flesh out the basic concepts of this internet buzzword.
To start off, DevOps is a portmanteau of two words: Development and Operations. It is a set of practices and tools that promote collaboration between development teams (Devs) and operations (Ops). The goal of DevOps is to streamline the software development lifecycle, minimize failure rates, scale up the frequency of deployments, and achieve high-quality software.
To get a better understanding of DevOps in today’s modern IT environment, let’s have a peek at how the deployment model was before the advent of DevOps.
Traditional IT Practices
Before DevOps, development teams and QA engineers used the classic waterfall model. The working landscape was largely siloed and testing and deployment of applications happened in complete isolation. This resulted in duty overlaps, gaps, delays in feedback, and other inefficiencies that required additional time to complete the project. Limited and delayed feedback meant that the quality of the software was not thoroughly audited until the last phase of development.
Additionally, manual deployment of code was occasioned by human errors and therefore demanded more time in debugging applications. Also, different teams had various timelines for completing their tasks and it was not uncommon for the timelines to fall out of sync leading to further delays in realizing the final product.
Enter DevOps
The concept of DevOps was conceived sometime between 2007 and 2010 by two developers: Andrew Shafer and Patrick Debois. Since its inception, It has fostered smooth collaboration between operation and development teams in every step of the software development lifecycle. This heralded new concepts such as Continuous Integration ( CI ) & Continuous Delivery ( CD ) and many others which contribute to rapid software delivery.
DevOps Model and Practices
DevOps isn’t just about collaboration and having the right mindset towards accomplishing a goal. It encompasses best practices that are aimed at helping deliver quality and market-ready software within the shortest possible time. Let’s have a look at some of these best practices that will help you boost efficiency and speedy delivery of code.
Continuous Integration (CI)
Continuous Integration is a software development practice where developers merge code changes into one central repository. Thereafter, automated tests and builds are executed on the code. The goal of Continuous Integration is to speed up debugging of applications, reduce the time taken to release new software updates, and improve the software quality.
Continuous Delivery (CD)
Continuous Delivery (CD)is yet another practice where changes in code are automatically built, and deployed for vigorous testing. Later, automated tests are executed against the deployed code in order to allow the developers to identify and fix the bugs. Usually, the code is progressively subjected to multiple testing environments where through a standard automated procedure, the code achieves the highest mark of quality.
Popular CI/CD tools include Jenkins, Travis CI, Circle CI, Azure DevOps, and AWS Code build.
Continuous Testing
The goal of continuous testing is to identify bugs and potential risks in the early stages of the software development lifecycle in order to minimize errors that would manifest in the end product. When code fails the vigorous tests, it is usually sent back to the developer for revision before being passed on to the Quality Assurance department for evaluations and functional testing. Widely used continuous testing tools include Travis and Selenium.
Continuous Monitoring & Loggin
As you would expect, applications and the underlying infrastructure require continuous monitoring to check on their performance identity any errors or defects, and ensure compliance to various industry standards. A wide variety of metrics are monitored including:
- Memory and CPU utilization
- Disk space usage
- Bandwidth utilization
- Customer interaction
By monitoring and analyzing data and logs generated by applications, developers can easily get insights into how features or configurations impact users. Additionally, configuring alerts will help in the identification of errors or undesired changes every step of the way. Ultimately, continuous monitoring ensures the high availability of applications and inspires confidence that things are working as expected.
Popular monitoring tools include Prometheus, Grafana, Nagios, Zabbix, and Netdata to mention a few.
Infrastructure As a Code
Abbreviated as IaC, Infrastructure as Code is described as the deployment and managing of resources such as virtual servers, & load balancers using machine-readable configuration files as opposed to interactive configuration tools. This is particularly essential in Cloud environments such as AWS where you can readily spin up compute instances by defining the details of the instance in a configuration file and leveraging tools such as Terraform to deploy the resources.
For example, Amazon AWS provides APIs that allow users to programmatically interact with the Cloud platform from command line. This facilitates speedy deployment of resources by eliminating manual processes and slack. Simply put, IaC gets more work done within a short time duration.
Microservices
Microservices architecture is where a single application is an integration or an amalgamation of various smaller loosely-coupled services. Each service runs independently and communicates with the rest of the applications using HTTP-based APIs. Microservices can be deployed as s group of services or a single service
Microservices architecture is a lot different from traditional monolithic architecture. In the traditional architecture, applications are single-tiered and all components, including the code and the UI, are bundled into a single program.
Microservices facilitate independent deployment and management of resources. They also ensure high availability by preventing a single point of failure. when a single application crashes, the rest will continue running.
Benefits of DevOps Model
Having looked at DevOps best practices, let’s now focus on the benefits of adopting the DevOps model.
Improved efficiency & productivity Between teams
Collaboration between development & operation teams translates to joint responsibility, which ultimately boosts productivity and fosters team engagement.
Reduced odds of Product Failure
Collaboration also enables teams to easily debug code at every stage before getting to the final phase. This yields high-quality and market-ready software.
Rapid Software Delivery
Application deployment is more streamlined and much faster thanks to the automation tools that DevOps provides ( such as Ansible, Chef, and Puppet ) & advanced continuous integration (CI).
More Product Transparency
Since the product knowledge is spread out across various departments, there’s a clear goal and vision about the product, translating to better decision making in every stage of development
Summary
The ingrained belief that development and operation teams must forever work separately is long outdated and flaws. The siloed philosophy may still be alive in some industries, but this has resulted in glaring inefficiencies along the way.
DevOps seeks to integrate development and operation teams and foster a cultural shift from the old way of working in silos to working in tandem to reduce errors in code, improve quality of software, speed up delivery times and boost overall productivity. Ultimately the end-user ends up with a high-quality product in a timely fashion.
Love a bit of Continuous Monitoring & Loggin, especially in the morning.
Horse feathers! DevOps is nothing more than “traditional IT practices” expressed in terms of new buzzwords; IOW techno-babble. This article, Part 21, reads like a sales brochure developed by the marketing department of the DevOps developers.
In the 35+ years, I have spent in IT, operations, and application development, the basics have not changed too much. What has changed is the jargon. It’s like education. Every so often, somebody or a group of people, come out with a New and Improved method of teaching. After all, is said and done, after we get through the jargon, teaching students is still the goal.
While there is some exchange of ideas and some cooperation, ultimately it is still the developers who develop applications and operations run or implements them. There is a natural progression of steps in the process of developing applications. The steps have to be followed in order and no steps can be bypassed or short-circuited.
“Continuous Integration”
While that sounds great in the propaganda, in practice not so much. Have you ever heard the saying that “Too many cooks spoil the meal”? Having people each working on developing a part of an application speeds up the development process but a lot of that time is wasted on meetings to coordinate that development. Ultimately only one individual must be responsible for the decisions.
“Continuous Testing”
“to identify bugs and potential risks in the early stages of the software development lifecycle in order to minimize errors that would manifest in the end product” is a semantically null marketing phrase. While various modules of an application can be tested as they are developed, the ENTIRE application must be tested before it is put into production and that testing cannot be done until ALL the coding is finished.
“By monitoring and analyzing data and logs generated by applications, developers can easily get insights into how features or configurations impact users.”
You can monitor and analyze ad nauseam in the shop but it is ultimately the users that tell you how they are impacted. And the user is ALWAYS right, even when they are wrong.
“Collaboration between development & operation teams translates to joint responsibility”
Which translates to time-wasting, counterproductive finger-pointing when something goes wrong.
Last but not least. No matter what testing software a developer uses, no matter how much testing is done, no matter how much idiot-proofing a developer does, it’s never enough. There are many times more users than there are developers and testers and users, whether inadvertently or by design, sometimes use applications in ways they were not designed to be used.