DevOps embodies agile principles;
iterating toward a goal is a primary aspect of its design.
Iterative sets the context, in that it is less important where you start,
and more important to begin the journey.
The ultimate goal of many DevOps efforts is to enable continuous delivery (into staging), if not continuous deployment (into production), of every source code repository change. But “continuous” implies something in addition — that you are never “done”.
DevOps doesn’t succeed unless all stakeholders have a set of common objectives and trust. What is required is agreement on the mission and the metrics. This is facilitated through transparent and frequent communications among relevant team members.
Agile approaches have significantly improved the development process within many enterprises. However, without applying similar concepts to the downstream groups (such as operations), the bottleneck has merely been shifted to the right.
Automation links development, test, operations and security systems to deliver fast, continuous, safe and cost effective services.
The primary context is organizational. Gartner has observed full stack or feature teams instituted to assist a development organization with achieving a more rapid time to market via a
goal of continuous delivery.
A common area of friction within IT revolves around the release process.
Gartner has observed IT organizations focusing their energy on reducing the steps in the release process,
then continuing to improve its speed by applying automation.
This has been a somewhat rare starting point; traditionally, beginning an IT (operations) project in this area can be problematic without first having fully thought out all of the processes that interface to the tools. However, one client started their DevOps journey with a technological focus that sought to solve a recurring problem with testing not being performedadequately. In that case, automation of testing resulted in changing the behavior of the targeted development organization, which saw testing performed more often and earlier in the life cycle.
While changing organizational culture is often the critical outcome, we rarely see it emphasized first within a DevOps initiative, because changing the associated behavior of individual scan be among the most challenging tasks for any enterprise. Still, we have seen a case where the desire to become more engineering oriented was initiated with a change in skill requirements for both existing and prospective employees.
There is no official catalog of DevOps practices. As such, individual organizations must not only define what DevOps is to them, but also identify the activities that come into the DevOps focus.
This figure is Gartner’s initial attempt at providing some “bounded rationality” to the question: “What does DevOps consist of?”
…organization style attributed to Google, an SRE team = “… combines software development, networking and system engineering expertise to build and run large scale, massively distributed, fault tolerant software systems and infrastructure.”
…organization style modeled after Amazon.com’s “two pizza” teams, a Feature team = “….have an integrated team of developers, quality assurance (QA), production engineers, and program or product managers, typically numbering between six and 10 individuals in total”
A DevOps project can start from within any of the four basic areas or paths. It is less important to have a specific starting point than to just start and iterate toward the desired objective. In addition, it is not necessary to fully implement every practice within a category —organizations should stop at the point where they’ve determined that they’ve implemented the capabilities necessary for their business.
ChatOps is an approach generally credited to GitHub. It is the pattern of automating operations tasks with an automated chat robot, or “bot,” from within a chat room. Specifically, DevOps team members issue commands to perform code deployments, for example, via Internet Relay Chat (IRC) to a chat bot, which then executes them through scripts, etc. This enables the entire team to have real time collaboration, and ensures that everyone is aware of the current status of an operation in progress.
Apply a Layered Operations Strategy Reflecting the Reality That Not All IT Services Have the Same Support Requirements.
Different applications cause different rates of change versus stability.
Gartner’s ‘Pace-Layered Application Strategy’ outlines a way to categorize applications into:
- Systems of record (typically ERP-type applications)
- Systems of differentiation (typically business-specific applications, often COTS applications with customization)
- Systems of innovation (typically new web-based, agile-development-focused applications)
Stabilize IT Operations Investment in Systems of Record, and Begin to Shift IT Management Funding to Systems of Innovation and Systems of Differentiation That Will Drive Greatest Incremental Value for the Business
DevOps as a concept is well aligned with projects with high degrees of uncertainty,
so exhaustive planning is not going to be optimal.
What Infrastructure Automation Offers For Customers
- Reduce time wasted in the setup of infrastructure or setup failure.
- Decrease the risk of delivery on time.
- Provide high skilled resources required for Infrastructure management.
- Standardize the setup process and tasks to produce the same outcome regardless of the person executing it.
- Make it easy to assure that the environment is setup correctly.
- Decrease of Technical professionals cost associated with the management of the massive number of servers and virtual machines
What We Can Automate
We can automate the infrastructure management for any software that could be installed on any Linux or Windows platform. Automation process can be very complex depending on the original process, this is created once and run many times.
The Technologies We Use
- Chef, Ansible
- Redhat Ansible Tower
- Vagrant, Docker