DevOps – Philosophy vs. Practice
DevOps – Philosophy vs. Practice
It's tough to talk about DevOps as a concept, but focusing on the concrete aspects like tooling, testing, and monitoring can make the transition clearer.
Join the DZone community and get the full member experience.Join For Free
Monitor your CI/CD pipelines end-to-end with Hygieia, an open source dashboard from Capital One.
It’s hard to look at a blog post, hear a podcast, or see a conference talk these days without it having something to do with DevOps. So to say DevOps is the buzzword of the moment would be a severe understatement.
But what is DevOps? Is it just the new Agile or is it tooling to bring the Developer and Operations sides together?
There is always talk and discussion about the philosophy of DevOps. Such discussions often include big presentations on what it means, yet they often touch on only one aspect of DevOps such as on-call and incident management, fighting fires, or how devs meet ops – but rarely are all parts examined at once. Here we’ll try to put the philosophy and the tools together in one place.
First, let’s define DevOps as it stands today. According to the definition of DevOps, it is a concatenation of Development and Operations, a method that emphasizes collaboration between the entire spectrum of professionals involved in creation, development, and deployment of software. While straightforward, the definition hardly fits the modern term.
Today, we think of DevOps as a set of behaviors and tools that allow a team to function. The idea differs from the Agile mindset, which focuses on the ability to move a project along a flexible timeline which can be subject to change depending on feedback. As a result, agile is small, fast, and open to change, but it is mostly focused on the software development cycle. DevOps looks beyond development and encompasses all the steps from concept to delivery of a product.
The DevOps philosophy stretches beyond the work cycle. The focus is on how the members of a team function interact and can be most successful. This means taking into account overarching pieces of the puzzle: development, testing, integration, deployment, monitoring, and systems administration.
Pulling this all together requires a toolset, and the chain can be long. There is no single answer to “what’s the right toolset” – it’s more about what works for your organization.
The DevOps Toolkit
When it comes to development tools, there is a never-ending stream of possibilities. First, there are languages – this is often dependent on what your application is set to do. A simple web-based application? Ruby or Elixir will work well for you. Need something to be a bit more analytical? Perhaps Python or R would better suit your needs. Want the tried and true language of dependability? Java and Perl should do what you need.
Languages aside, the key here is making applications that are usable in order to make our users’ lives better and easier. In addition, we need to make our developers’ lives easier as well – which is where version control techniques come in. At the moment, the most prominent version control system is Git, but there are still plenty of Subversion users in the world.
While testing has been a hot topic amongst software engineers for quite a while, there are many parts to testing that tools such as RSpec and other code testing components don’t reach.
Tools here include Selenium, used for application and browser testing, WAPT, which is an amazing load testing and stress testing tool, and Qtest, a suite of tools used for quality control in your application. Additionally, there are services like RainforestQA that perform the testing on your organization’s behalf. Although this is only a partial list, ensuring the stability of an application before it hits the public is crucial.
Continuous Integration/Continuous Delivery
Continuous integration isn’t really a new concept, but it does add to the DevOps tool set in important ways. Companies such as Travis CI and CircleCI have been working for several years to develop seamless integration of new code into the current operating stack.
Add to this concept the idea of Continuous Delivery, and we start to approach the endgame of our DevOps setup. Like CI, there are great, stable CD tools available, such as Go CD (not to be confused with the programming language Go) and Chef. Once we have this, we need infrastructure.
If DevOps is a buzzword, it is in good company. Cloud Services, containerization, and serverless are other buzzwords at the forefront of what we used to call “hosting solutions”. Like programming languages, these answers are organizationally dependent. While serverless may be the wave of the future, some larger companies are just getting into the idea of cloud, whether public or private.
While the industry itself is moving forward, it’s important to note adoption of newer infrastructure technologies moves at a much slower pace. For example, organizations are just now beginning to feel safe moving to containers and serverless and although the cloud has become extremely popular, there are many enterprise level customers still using bare metal.
Once a decision is made on which new infrastructure technologies to adopt, there is a team of system administrators that come along to handle anything beyond the single application server level. This team will include ops experts, troubleshooters, and even DBAs to look at issues with databases, which operate differently than application code.
These operators, systems administrators and deployment and infrastructure experts often need their own tools to see what the underlying infrastructure systems are doing. This is where the ELK stack comes in. To take it a step further, tools such as Logz.io help to provide insights into what our applications are doing while they’re out there in the wider world.
The ability to see into our infrastructure and feed that back through the team to improve is quintessential to success in the market of application development. It’s the end of the cycle that is also the beginning.
The most interesting part of the toolset used to implement the DevOps philosophy is communication. The tools here are well known – everything from Slack to Hipchat to IRC are used to keep the moving parts working together. This is the key to a successful DevOps implementation.
With competing tools, it’s hard to say what the perfect setup will be. Is DevOps the best philosophy for your organization? Establishing this is the first of many steps to realizing the potential of best practices within your team and organization.
DevOps incorporates both worlds. It is not only a set of tools to streamline your organization, but also the philosophy applied to those tools, and the teams working with them. All of these elements must come together to improve your application and how it interacts with end users. By bringing together DevOps philosophy and tools, you can empower your team to make successful DevOps implementation a reality in your workplace.
Published at DZone with permission of PJ Hagerty , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.