DevOps is a verb. It is something you do, not something you have.
Read on for our Developers’ perspectives on DevOps and the thought process that goes into finding answers to DevOps or not to DevOps.
DevOps is default now?
The DevOps hype has engulfed software development so much so that it is considered as default. But fact is many software development teams have successful releases without DevOps. And there are instances where DevOps implementations fail or not as effective.
DevOps is not default – a DevOps readiness check is essential before jumping into the DevOps cycles. A DevOps initiative should focus on the business requirements and establish a solid justification for it. Instead of focusing on release rates, investigating into the business value that DevOps might bring is necessary.
A big driver for implementing Agile and DevOps is the pain of not having fully functional code in production. In the absence of DevOps, stakeholders spend money but not see immediate value. Agile and DevOps are specific to address this pain.
DevOps is complimentary to Agile processes for development such as continuous integration and ongoing releases of code into production. It introduces testing within the pipeline and incorporates time for documentation.
DevOps speeds up product releases with CI/CD, encouraging faster feedback. Change requests and new feature/functionalities can be incorporated faster, reducing the time-to-market and value-delivery rates.
Automation of many development procedures (testing, configuration, and deployment) is possible with DevOps tool chains. This frees up time from manual repetitive activities, that can be utilized for innovation and more value-add activities.
The DevOps philosophy highlights the importance of collaboration among teams. This promotes transparency and creates collective intelligence.
Why not DevOps?
DevOps involves a combination of process and tools. The processes are designed to eliminate bottlenecks, disconnects and ambiguity between Dev and Ops and tools are the enablers. The effectiveness of a DevOps team depends on the team culture. DevOps teams often face resistance to change and a dread of uphill learning curves associated with new tools. A shift in control among the development, database and build teams generates pushbacks and friction, that jeopardizes the team control structure and morale.
Not all business cases need a high feature release frequency. Their teams aren’t committing multiple releases per day – such as businesses in finance or healthcare verticals. The need for CI/CD and the related automation does not arise. Practicing DevOps in such environments might result in waste of funds and effort allocated for DevOps toolchains.
From the results of our “DevOps and Modernization” survey, we found that legacy architecture is one of the main barriers to DevOps practices. Retro-fitting existing development cycles later into DevOps implementation has a dangerous potential to backfire. Some DevOps tools can be tweaked to fit the legacy environments, but not 100% efficient. It would be best to use a “modernize first” approach by creating loosely coupled architecture that provides developers the freedom and flexibility to independently implement parts of the system so that they do not break.
DevOps adoption requires investment in tools/platforms for version control and automation. It requires great tools to come to fruition. Version control tools are required to enable agility and speed while retaining accountability and documentation. Automation tools are required for quality control and software release processes.
Popular open-source tools like Kubernetes, Docker, Jenkins, Ansible, Chef, Prometheus, Istio, GitHub Actions etc. enable container builds and orchestration to microservices networking, configuration management, CI/CD automation and full-stack monitoring. However, use of open source brings in security vulnerabilities leading to software breaches.
If the decision to use DevOps is only because everyone else is doing it, then success is unlikely. Implementing DevOps requires effort, stable management, time and team support with reasonable goals and objectives.
– Shweta Katre, with valuable inputs from our DevOps experts: Joseph Satchavarodom, David Sakoda and Andy Son.