Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
DevOps is about pinpointing and eliminating bottlenecks in order to deploy code often—shortening the time-to-market and increasing quality and effectiveness. One of the most common bottlenecks in the release process is the interaction between the developers and the integration services/operations group.
Development (Dev) is entrusted with producing innovative software quickly while Operations (Ops) knows that service failures are often attributed to changes. This means Ops feels that if fewer changes are executed, fewer failures will occur and the system will be more stable and responsive. The natural conflict and opposing priorities between the two groups can create a productive equilibrium, but often results in communication difficulties, animosity and a financial loss for the company.
And sometimes we just think that because of these challenges, DevOps is for small companies. However I had a chance to sit with Milind Khandekar Ph. D (Quoted Herin), a DevOps Lead at a Fortune 5 company. And he showed me that DevOps works well in large companies as well small, and with the same human factors.
One of the most important ingredients to a successful DevOps Team is a capable and self-motivated leader who brings Development and Operations together. A good manager/facilitator will increase agility and collaboration between the two groups, eliminate conflicts of interest, organize and schedule human resources, define responsibilities when action planning and prioritizing team actions and, most importantly, keep the client happy. This good manager will look for solutions instead of someone to blame, encourage bi-directional feedback and then use that feedback to make the process more effective.
But a DevOps manager has the very difficult task of introducing cultural change to unify different subcultures and operating methods.
“Most important aspect is to have a team mentality across dev and DevOps … We need to embed ourselves in conception, design and architecture of the development activities.” – Milind Khandekar
This means the Dev team must take more responsibility for their applications that are running in Production (“Congrats, it works on your box, but you need to help figure out why it fails after deployment”), and Ops must learn how to accept rapid change and build adaptable systems that moderate risk and identify errors early rather than imposing boundaries on change.
When something does go wrong, a DevOps manager should encourage the team to take shared responsibility rather than finger-pointing and diagnosing whether the failure was caused by bad code or by operational errors. The resulting exceptional service quality and better deployments will be this manager’s main goal.
For these changes to take place, a mindset shift is not enough. The Dev and Ops members of the team must acquire new knowledge now that development is involved in operations (particularly around bugs and when improving performance) and operations is involved in development (primarily in deploying and testing). Developers must learn about operating system internals, networking, automation, security, configuration management while Operations should have at least a basic comprehension of continuous integration, release management, testing and debugging source code. In this new culture, old-style system and database administrators will disappear and be replaced by more knowledgeable operations experts who work closely with Dev for continuous deployment with zero problems.
With a little bit of communication, these two groups can make a great team! Here’s how:
Self-documenting Software
Use of self-documenting software is an obvious time-saving option. This is helped by new online tools such as ChatOps that makes commands executable from within a company’s chatroom via a chatbot. When you correlate these systems with artifacts such as tickets in JIRA, Build status from GO and Jenkins, and commits (from GitHib) you have a quick way to get all information. And recording this data in a robust log analysis platform such as LogEntries gives you historical activity, change control, and system wide visibility.
Simple, Clear Documentation
Documentation should be so clear it can be handed to a novice, and they will understand what is being said. Everything should be accessible to all through web, off-line and mobile. Real-time collaborative editors such as Confluence, Wikis, Evernote and Google Docs also help with documenting tasks.
Project-based dashboards where Dev, Ops and QA are allowed to view each other’s progress and issues and help with further discussion, collaboration and decision-making. This is also where a LogEntries like tool is very useful.
As “DevOps originated from a need to do a lot of tooling and automation,” and while there is no “one choice fits all,” solution for selecting the right DevOps tools, a number of criteria including business requirements, budget, workflow and approval by both teams should be considered. The method of selection should be testing by both Dev and Ops using trial software obtained directly from the vendors.
One question that is often asked is “What organizational structure is required for DevOps to succeed?” The answer is, of course, “It depends.”
Does the company have a strong technical leadership that is able to make Dev and Ops work together towards a shared goal?
If it does, there is no reason the two cannot cooperate on an independent or part-independent product stack.
Does the company have a unique software product?
In this case, a ‘NoOps’ option, where Operations is fully embedded in Development, should be considered
For A or B the ratio of Development personnel to Ops should be 54: 46.
Does the company have several different products and services and a small IT team that has difficulties ensuring everything runs smoothly?
Infrastructure-as-a-Service is the right choice in this case as part of the IT operations become outsourced and relieves the burden from the company’s operations team. The lowest Ops-Dev ratio that has been successful is 2% Ops. In this example, the operation’s department was almost completely eliminated and the company focused directly on revenue producing activities. This is an advisable solution for firms with limited financial resources.
Quality Assurance
Quality Assurance (QA) is the glue holding software development and operations together. Their main role is to define the test plans, scenarios, scripts and procedures used to ensure the release of a quality product. QA is an integral part of the system helping balance quality and speed. When Dev and Ops are joined, the traditional QA role is adjusted as they are involved earlier in the life-cycle of the project.
“Their role is also to be part of this big team and contribute from the early stage. Just that their function is to assemble test plan and manage their automation.” – Milind Khandekar
It is important to add more automation tools to perform QA’s job because failures and performance issues must be found in DevOps in real-time. This frees some of their resources and allows faster testing and a continuously growing number of iterations to be deployed. At Amazon, for example, this is hundreds per hour.
Agile Development principles impose that at the end of every sprint, developers have a build. In DevOps, this concept extends to a production- like environment ready to be deployed when a sprint is terminated. Both groups will use a single sprint plan.
A lot of companies are replacing Scrum with Kanban methodology—originally developed from by Toyota for managing assembly lines in the 1940s. Kanban methodology provides a better choice for DevOps because it includes the entire flow finalized with delivery instead of just the development process. Besides increasing visibility of the organization’s workflow, Kanban methodology is more suited than Scrum to quickly changing software development.
As most large applications use several languages such as PHP, Java, .NET and Node.js, and operations becomes more complex with cloud environments and virtualization, container’s deployment, x-features-as-a-service, the interdependence of software development and IT operations becomes greater. Teams must learn to keep up, adapt and collaborate.
DevOps is work, and in involves people, organizational structures, and courage. But the benefits make it all worth it, and as we have seen large companies like Apple leverage it as a tool to maintain startup like productivity, with enterprise level oversight.
