DevOpsis a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives.
DevOps is NOT ENOUGH! DevSecOps is what must be implemented with the cybersecurity stack built-in into the DevOps pipeline.
Benefits of DevOps
- Implementing DevOps allows organizations to get more done. DevOps promotes teamwork by eliminating silos and encouraging collaboration. Teams that adopt the DevOps model are able to increase lead time, create new features at a faster pace, all while driving innovation and increasing employee engagement and communication. In turn, they are making applications more secure and stable.
- Leveraging DevOps and implementing continuous integration and continuous delivery (CI/CD) allows organizations to see a tremendous improvement in deployment frequency, lead time, detection of cybersecurity vulnerabilities and flaws, mean time to repair and mean time to recovery.
Learn more : https://www.forbes.com/sites/forbestechcouncil/2018/07/19/the-two-biggest-disruptions-to-cybersecurity-since-the-invention-of-the-firewall/
- Allows for rapid experimentation and uncertainty while focusing on mission end goals.
- Enables rapid prototyping and A/B testing or canary releases.
- Makes new services and innovations available.
- Increases frequency of deployments
- Increases collaboration between various departments
- Greatly Reduces time spent maintaining applications and fixing them
- Increases the number of end users who are using organizations’ services
- Improves performance and quality of applications
- Reduces time-to-market
- Reduces time needed for testing, development and operations
- Avoids shadow IT by enabling all directorates/divisions/services to reuse the DevSecOps pipeline instead of reinventing the wheel and building their own pipeline without supervision
- Avoids technical debt by continuously fixing bugs and security issues thanks to automated tests and real-time scans.
- Mean-time to recovery (MTTR): shows how long it would take applications in the production stage to recover from failure
- Mean-time to production: shows how long it takes when new code is committed into code repository
- Average lead-time: shows how long it would take for a new requirement to be delivered and deployed
- Deployment speed: shows how fast you can deploy a new version of the application between staging, test and production
- Deployment frequency: shows how often you can deploy a new release into production environment and testing / QA
- Production failure rate: shows how often software fails during production
- Ability to detect and prevent security flaws and injections
- Ability to perform fuzzing and static/dynamic source code analysis
- Ability to monitor container security including container base images and libraries
Solution: Organizations should focus on building a collaborative culture with shared goals. This also includes finding employees who are DevOps champions in the organization.
- Test automation
Solution: Many organizations neglect test automation while focusing on CI/CD deployments. Continuous testing is key for DevOps success, and security must be considered from the outset.
- Legacy systems
Solution: Include modeling for legacy infrastructure and applications in your DevOps plans. Installing new hardware or software to coexist with older systems is always difficult.
- App complexity
Solution: Consider application architecture changes based on on-premises, cloud, and containers early on in the process.
- No DevOps plan
Solution: Create a clear plan that includes milestones, project owners, and well-defined deliverables.
- Managing environments
Solution: Your organization can standardize and automate complex DevOps environments with cloud sandboxes and other tools.
Solution: Teams need training on DevOps. Organizations should standardize processes and establish common operational procedures.
Solution: Remember that open source does not mean free, and factor in integration and operational complexity in your costs.
Solution: Avoid fragmented toolset adoption, which can add to your costs.
- Leadership support
Solution: Educate leadership about the benefits of DevOps to gain resource and budget support.
- Platform independence: Build it once, run it anywhere
- Resource efficiency and density
- Effective isolation and resource sharing
- Speed: Start, create, replicate or destroy containers in seconds
- Immense and smooth scaling
- Operational simplicity
- Improved developer productivity and development pipeline (thanks to DevOps)
Learn more about containers: https://medium.freecodecamp.org/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b
Continuous Integration (CI) and Continuous Delivery (CD) are key parts of the DevOps pipeline.
- Continuous integration (CI) is the practice of consolidating all new source code into a shared version control server such as GitHub, several times a day.
- Continuous delivery (CD) is used to deliver (release) software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software with complete automation. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.
- Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.
Agile vs DevSecOps
DevSecOps is the next evolution of agile and builds on the agile principles by adding the following:
- Leverages Containers and Microservices concepts
- Leverages Cloud deployment for scalability and prototyping
- Continuous Integration/Continuous Delivery to rapidly prototype, test and deploy
- Leverage A/B testing and canary deployment for rapid feedback loops
- Embed security in the pipeline instead of an afterthought
Automated testing is a key part of DevSecOps. It is enabled by multiple tools that measure both test code coverage and test results. They are fully automated and do not require human action.
It also enables new concepts like pair programming and peer code review.
Agile brings several new models for creating the right tests:
- Test-driven development (TDD) is a software development process that relies on very short development cycles: requirements are turned into very specific test cases first, then the software is built to pass the tests.
- Acceptance test–driven development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as specification by example, behavior-driven development (BDD), example-driven development (EDD), and support-driven development also called story test–driven development (SDD). All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own domain language.
Extreme DevOps Risk Management Example — Chaos Monkey (Netflix)
Chaos Monkey is a tool invented in 2011 by Netflix to test the resilience of its IT infrastructure. It works by intentionally disabling computers in Netflix‘s production network to test how remaining systems respond to the outage. Chaos Monkey is now part of a larger suite of tools called the Simian Army designed to simulate and test responses to various system failures and edge cases.
As part of the DevOps movement, special attention is paid to the safe operation of computer systems, thus providing a sufficient level of confidence despite frequent releases. By contributing to the DevOps Tool Chain, Chaos Monkey meets the need for continuous testing.
They are part of the pattern “Design for failure”, “designed to support failure”: a computer application must be able to support the failure of any underlying software or hardware component.