In the last post, we completed our description of Agile methods, and how they enable Open Networking solutions. In this post we move on to the second practice: DevOps.
The term “DevOps” evolved through multiple definitions and perspectives but in essence is an outgrowth of Google’s Site Reliability Engineering (SRE).
Google’s Site Reliability Engineering
SRE began in around 2003 when Google started hiring software engineers to run production environments. In the words of its inventor, Ben Treynor, SRE is:
”fundamentally doing work that has historically been done by an operations team, but using engineers with software expertise, and banking on the fact that these engineers are inherently both predisposed to, and have the ability to, substitute automation for human labor.
Ben Treynorhttps://landing.google.com/sre/interview/ben-treynor/
For SRE as much as DevOps, automation is an aspect, but it’s not the objective.
”DevOps isn’t about automation, just as astronomy isn’t about telescopes.
Christopher Littlea technology executive and one of the earliest chroniclers of DevOps
DevOps
SRE and DevOps share some foundational principles. DevOps as a term began to emerge in around 2008 or 2009, although the exact genesis is historically vague.
”DevOps is a combination of software development (Dev) and information technology operations (Ops). DevOps is a set of software development practices that aim to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.
Wikipediahttps://en.wikipedia.org/wiki/DevOps
In order to improve reliability and security and provide faster development and deployment cycles, DevOps targets process areas such as:
- Product delivery
- Monitoring and Measurement
- Continuous testing
- Quality testing
- Feature development
- Maintenance releases
More recent definitions of DevOps have become more broader still, with DevOps taking on an end-to-end scope, i.e. the delivery, development, and management of applications throughout the systems development life cycle, and thus it must employ a wide range of tools.
DevOps has adopted ideas from Agile, Lean, Organisation Theory, ITSM and ITIL amongst others, so there are many conceptual and practical overlaps between DevOps and Agile at a technical, tool and process level.
Tools and Toolsets
A DevOps toolset (or toolchain) is a set of tools that support one or more of the following activities: Plan, Create, Verify, Package, Release, Configure, and Monitor.
Three foundation practices for DevOps are:
- Continuous Integration (CI): requires developers to integrate code into a shared repository frequently and verified by an automated build
- Continuous Delivery (CDE): ensures that a team’s code is always in a deployable state, even if the code is not actually deployed to production
- Continuous Deployment (CD): any software release that has passed upstream validation (typically CI/CDE as above) is automatically released into the production environment
These three processes underpin the end-to-end scope of DevOps. They are usually referred to as “CI/CD”. Understanding local context will determine whether the “D” is “Delivery” or “Deployment”.
DevOps Evolution
DevOps continues to evolve, as tools and practices evolve. DevOps practices are including AI and Machine Learning into their toolsets to provide more intelligent decision-making based on the data that is being collected.
For example, a common alarm set in production systems storage is to set alarms at rising levels of criticality as free space declines, e.g. 50%, 75%, 90% etc. At the point of the most critical alarm being raised (say 95% full), actions are triggered to conserve remaining space and/or free up space and/or to order more disk space. But all of these actions take time.
A DevOps approach would be to monitor usage and constantly update forecast 95% time based on the time taken for the responses, e.g. order more disk and have it installed. A DevOps approach would trigger the most critical alarm as soon as the forecast time to remediate was equal to or less than the time to reach the 95% full storage.
Conclusion
Whilst not discounting the importance of influencing and improving the overall organisational and practice context within which any given project is embedded, the Open Networking Integration view of DevOps is primarily on the end-to-end automation of lifecycle operations. Where possible within the context of any given project, Open Networking will adopt as many ideas as makes practical sense but is ready to integrate with broader DevOps practices where they may be found.
Aptira’s service delivery approach is based on the adage that “if you give someone a fish, you feed them for a meal, but if you teach someone to fish, then you feed them for a lifetime”.
Aptira’s stated preference is to teach our customers to fish.
Of necessity this can expose us to areas that are not technically part of our brief, e.g. organisational structures, human resources policies (hiring and training), business and technical processes, and even more general management areas in some cases.
However, Aptira believes in addressing the “whole patient” rather than just addressing a narrow technical specialty. We prefer to provide holistic and complementary inputs to those already existing in the customer’s organisation.
How does Aptira balance the need to deliver on specific technical requirements and at the same time be aware of and ready to help customers on a broader basis?
Through the practice of Systems Integration, which we’ll cover in the next post.
Stay tuned.
