DevOps – chances are that if you’re working in IT sector or and are related to anything related to computers, you may have heard this word. It is the buzzword now a days. This word seems to feature in almost every second conversation on new tools and techniques and also on the various platforms like LinkedIn. Job boards are now filled with posts and opening related to this.
But what is DevOps really? What does it stand for? What are the ideas behind it? What are the pros and cons of having DevOps as a part of your application development lifecycle? Why do we need DevOps? There are a lot of questions, myths, misunderstanding and confusion regarding what how and why to have DevOps. Let’s try to dwell into this concept.
DevOps – What is it really?
First to all, we need to understand DevOps is not a specific tool. No. Not at all. There are a lot of definitions around DevOps but most of them stem out from a common ground – a better communication between the Development team, which creates the application and Operations team, which is in charge of taking care of an application once it is created and deployed. The word DevOps itself is a combination of Development + Operations.
If you want a definition, sort of then the Agile Admin website describes DevOps as
DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
So the major change is
DevOps is also characterized by operations staff making use many of the same techniques as developers for their systems work.
Whatis defines DevOps as
The term DevOps is used in several ways. In its most broad meaning, DevOps is an operational philosophy that promotes better communication between these teams -- and others. In its most narrow interpretation, DevOps describes the adoption of automation and programmable software development and infrastructure deployment and maintenance. The term may also label a culture that strategically looks at the entire software delivery chain, overseeing shared services and promoting the use of new development tools and best practices.
What does it stand for? What are the ideas behind it?
Ok! Does the definition mentioned above sounds confusing? Let this excerpt from the Agile Admin page explain this in detail
DevOps means a lot of different things to different people because the discussion around it covers a lot of ground. People talk about DevOps being “developer and operations collaboration,” or it’s “treating your code as infrastructure,” or it’s “using automation,” or “using kanban,” or “a toolchain approach,” or “culture,” or a variety of seemingly loosely related items. The best way to define it in depth is to use a parallel method to the definition of a similarly complex term, agile development. Agile development, according to Wikipedia and the agile manifesto, consists of four different “levels” of concern. I’ve added a fifth, the tooling level – talk about agile and devops can get way too obsessed with tools, but pretending they don’t exist is also unhelpful.
- Agile Values – Top level philosophy, usually agreed to be embodied in the Agile Manifesto. These are the core values that inform agile.
- Agile Principles – Generally agreed upon strategic approaches that support these values. The Agile Manifesto cites a dozen of these more specific principles. You don’t have to buy into all of them to be Agile, but if you don’t subscribe to many of them, you’re probably doing something else.
- Agile Methods – More specific process implementations of the principles. XP, Scrum, your own homebrew process – this is where the philosophy gives way to operational playbooks of “how we intend to do this in real life.” None of them are mandatory, just possible implementations.
- Agile Practices – highly specific tactical techniques that tend to be used in conjunction with agile implementations. None are required to be agile but many agile implementations have seen value from adopting them. Standups, planning poker, backlogs, CI, all the specific artifacts a developer uses to perform their work.
- Agile Tools – Specific technical implementations of these practices used by teams to facilitate doing their work according to these methods. JIRA Agile (aka Greenhopper), planningpoker.com, et al.
Ideally the higher levels inform the lower levels – people or organizations that pick up specific tools and practices without understanding the fundamentals may or may not see benefits but this “cargo cult” approach is generally considered to have suboptimal results. I believe the different parts of DevOps that people are talking about map directly to these same levels.
- DevOps Values – I believe the fundamental DevOps values are effectively captured in the Agile Manifesto – with perhaps one slight emendation to focus on the overall service or software fully delivered to the customer instead of simply “working software.” Some previous definitions of DevOps, like Alex Honor’s “People over Process over Tools,” echo basic Agile Manifesto statements and urge dev+ops collaboration.
- DevOps Principles – There is not a single agreed upon list, but there are several widely accepted attempts – here’s John Willis coining “CAMS” and here’s James Turnbull giving his own definition at this level. “Infrastructure as code” is a commonly cited DevOps principle. I’ve made a cut at “DevOps’ing” the existing Agile manifesto and principles here. I personally believe that DevOps at the conceptual level is mainly just the widening of Agile’s principles to include systems and operations instead of stopping its concerns at code checkin.
- DevOps Methods – Some of the methods here are the same; you can use Scrum with operations, Kanban with operations, etc. (although usually with more focus on integrating ops with dev, QA, and product in the product teams). There are some more distinct methods, like Visible Ops-style change control and using the Incident Command System for incident reponse. The set of these methodologies are growing; a more thoughtful approach to monitoring is an area where common methodologies haven’t been well defined, for example.
- DevOps Practices –Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration management, metrics and monitoring schemes, a toolchain approach to tooling… Even using virtualization and cloud computing is a common practice used to accelerate change in the modern infrastructure world.
- DevOps Tools – Tools you’d use in the commission of these principles. In the DevOps world there’s been an explosion of tools in release (jenkins, travis, teamcity), configuration management (puppet, chef, ansible, cfengine), orchestration (zookeeper, noah, mesos), monitoring, virtualization and containerization (AWS, OpenStack, vagrant, docker) and many more. While, as with Agile, it’s incorrect to say a tool is “a DevOps tool” in the sense that it will magically bring you DevOps, there are certainly specific tools being developed with the express goal of facilitating the above principles, methods, and practices, and a holistic understanding of DevOps should incorporate this layer.
In the end, DevOps is a little tricky to define, just like its older brother Agile. But it’s worth doing. When left at the pure philosophy level, both can seem like empty mom-and-apple-pie statements, subject to the criticism “You’re just telling me ‘do my job better,’ duh…” But conversely, just the practices without the higher level guidance turn into a cargo cult. “I do what this Scrum book says so I’m doing Agile” is as erroneous as “I’m using Chef so I’m DevOps right?” To be a successful Agile or DevOps practitioner is to understand all the layers that go into it, and what a given DevOps implementation might contain or not contain. In the end, what DevOps hopes to bring to Agile is the understanding and practice that software isn’t done until it’s successfully delivered to a user and meets their expectations around availability, performance, and pace of change.
Specifically, I’ve come to believe there are three primary practice areas that are usually discussed in context of DevOps.
- Infrastructure Automation – create your systems, OS configs, and app deployments as code.
- Continuous Delivery – build, test, deploy your apps in a fast and automated manner.
- Site Reliability Engineering – operate your systems; monitoring and orchestration, sure, but also designing for operability in the first place.
Now , there are a lot of myths and misconceptions about DevOps. DevOps does not mean
- Getting rid of Operations Team – No Ops
Many folks understand DevOps as developers taking on the responsibilities of Operations team and hence making them go out of jobs. No. Absolutely not. It’s not that. The only thing that is changing is that a lot of operational work is now getting automated. Yeah that’s right. A lot of the post-development work is now automated with the help of tools and the Operations and Dev team work hand in hand in DevOps to achieve that automation. This means that there is a collaboration where Ops folks learn and do some automation deployment and the developers learn more about the Operational procedures and write code accordingly.
- It’s all about tools
It’s not about just using the tools. Yeah tools can be and actually are a great weapon in DevOps but if you don’t know why they are being used in the first place, then the whole point is just a moo point ( get it ?).
Sure, a tool can be useful in Agile (or DevOps), but if you don’t know how to use it then it’s like giving an assault weapon to an untrained person.
DevOps facilities use of tools and practices like continuous integration, continuous delivery or continuous deployment, emphasis on task automation. Chances are you’ll get to hear a lot about real-time monitoring, incident response systems, collaboration platforms, microservices, containers, cloud computing when working in a DevOps environment.
- DevOps is more than just a culture
Many people say that DevOps is just a culture. It is much more than that. It is just like Agile, is not just a methodology. It is a way of thinking, doing things and apply those principles in product development. A DevOps approach can coexist with Agile software development; IT service management frameworks, such as IT Infrastructure Library; project management directives, such as lean and six sigma; and other strategies to execute IT projects to meet business needs. While it is typically associated with Agile development, the two methodologies do not need to be used in concert.
- It’s not only about Dev and Ops
DevOps doesn’t mean that the security people, network admins are left out. No.
The point is that all the participants in creating a product or system should collaborate from the beginning – business folks of various stripes, developers of various stripes, and operations folks of various stripes, and all this includes security, network, and whoever else.
DevOps is just a major step for one discipline to join in on the overall culture of agile collaboration that should involve all disciplines in an organization. So whoever is participating in the delivery of the software or service is part of DevOps.
Pros and Cons of DevOps
Quoting Whatis
DevOps benefits include the following:
- increased communications between development and operations leading to fewer silos;
- coverage for the whole software delivery pipeline (through builds, validations, and deployment);
- a focus on automation within the delivery pipeline;
- streamlined development processes by making development teams aware of possible issues that may appear in operation stages; and
- broad roles in DevOps environments, allowing many IT generalists to find positions in DevOps teams.
However, there are a few downsides as well –
- Organizational difficulties, such as transitioning to the DevOps practice, require large cultural changes including team re-organization, which takes time to get used to.
- DevOps can be expensive to adopt and operate if an organization has only a few releases in a year.
- DevOps will need adequate automation tools.
What Tools Facilitate DevOps
- Version Control Source Code Repositories – like GIT, SVN, where developers from multiple places, platforms can come and work over a period of time. Developers can check, reset, update and revert to a previous version of code if needed.
- Artifact Repositories – which allow for object-based outputs to be version-controlled. Managing an artifact repository is a good practice for the same reasons as managing version-controlled source code repositories. Common tools to manage artifact repositories include JFrog or Nexus Repository.
- Continuous Integration – tools like Jenkins, Travis-CI, goCD, Circle-CI enables DevOps teams to continuously validate, and deliver the end product to the user through automation and continuous movement of code throughout application lifetime. Continuous integration enables developers to create, test and validate code into a shared repository daily, if not multiple times a day. Continuous delivery pairs with CI, enabling more production-level tests and configuration setups. Once approved, code from CI/CD pipelines is deployed into a live production environment by operations teams. Continuous deployment invokes automated testing, configuration and provisioning, with release management and monitoring with automated rollback capabilities.
- Containers – deployable packages of software that rely on virtual isolation to run applications on a shared OS. Containers provide abstraction that enables code to move from development to test and staging then production without concern for the changes in underlying infrastructure. Common containerization tools include Docker, Microsoft Hyper-V and Windows Server containers. Container orchestrators, such as Kubernetes, can help automate, deploy, scale and maintain containers.
- Configuration Management tools – like Ansible, Puppet, Chef aid in provisioning servers and configuring software, middleware and infrastructure.
- Monitoring tools like – Nagios can be utilized to observe performance and security of code releases on systems, networks and infrastructure. Analytics tools such as Splunk can be used for operational intelligence.
Just like with Agile there is no defined roadmap or path to DevOps. It depends on how it suits your organization. Different successful teams in various orgs have stemmed up from different mindset and toolset and so there is no single way or defined way of having a mature DevOps platform.
Reading and References –
QATechnicals 