By DevOps in a larger, mature organisation is different from its small and brave counterparts
For a start, it is far harder to embrace change. So when a movement like DevOps comes along, with its commitment to agile, it can be hard to re-organise and re-engineer processes that have been used to classic IT.
As each organisation has a different history and corporate DNA, the reaction to such a significant change will vary and so will its take-up. Frustratingly for those weaned on ITIL, there is no universal checklist to show progress or give the proof of completion.
An assessment of maturity might be the closest measure of progress, albeit a flawed one as not every aspect of the DevOps or agile cannons will be needed. Pragmatism is necessary to prevent overdoing it.
So, there is no compass. No standard route. And one size does not fit all.
However, one can anticipate changes that are likely to happen in an enterprise if successful: four areas where DevOps can provide the most significant benefits.
1. Development Pipeline
Developers have been the dominant proponents of Agile and its associated techniques.
By automating and radically increasing the number of tests, then embracing infrastructure as code, one can form a pipeline of continuous integration and delivery. The objective is to make the act of code deployment very simple, short in duration and completely automatic (save for oversight).
Combined with zero downtime techniques, implementation can take place in working hours giving a more flexible involvement with the business. Every code update that passes its tests and is accepted for inclusion ends up in production code, although possibly with a switch to disable features that aren’t quite ready.
Continuous integration and deployment of very small changes are seen by proponents as the most efficient way to develop (or alternatively, have the least friction). This is only possible by shifting traditional quality control features into development and by taking a more defensive programming line.
There are drawbacks. For example, how to make your system design visible to security, architects and managers, when it is held in a code repository. Some issues are seen as evolution that still needs to take place. Others are seen as a new style of development that needs to be embraced. For example, projects are encouraged to work out their own solutions to operational problems rather than rely on company standard tools that may take longer to arrive.
Having the technical possibility of being able to deploy multiple times a day with full auditing is the goal, with the most successful result involving sponsors in reviewing the releases and accept transitory outcomes.
2. System Engineering
If there is a mantra to DevOps and agile, it is this: “automate everything”.
Any DevOps organisation should have the technical capability to address system management, automation of manual operations and integration into infrastructure suppliers.
Many proponents do this with a separate team, as it involves a specific range of technical knowledge and skills. Very broadly, this team will be responsible for an application’s non-functional deliveries, reliability and scalability; the focus is on programming the experience so that issues are resolved with code or tools and not with written procedures to fix applications.
Some organisations will continue to call this group operations and even split teams into matrix-style responsibilities or ‘pods’. However, the philosophy of this group is providing support using programmed solutions, so it is better recognised as such. Google have a similar group and role you may have heard of: Site Reliability Engineering.
3. Operations Integration
Existing large organisations will have an operations group, who will see the most significant change in the journey to DevOps.
Much of the work they do will become integrated into the application or system engineering functions, especially as the manual operations become programmed to form a more robust automated product.
This is part of the culture and reflected in DevOps terms. For example, ‘shift left’ is a reference to the practice of moving product quality responsibility to the left of a pipeline diagram, closer to the developers.
A language change is worth mentioning here. Projects and services from ITIL become ‘products’ in DevOps terminology, to show a more long-term strategic commitment. Instead of implementation and maintenance as separate phases with different teams, development embraces support. Having a product instead of a project with a final version implies continual evolution to keep up with changing circumstances.
However, there are other functions traditionally done by operations that will need to be maintained by groups outside of development and systems engineering. Consistency over projects, management information, maintenance of external obligations and governance of operational risk all need to be carried out. The remaining part of operations may continue as a coordinating function in a Quality function or even as ‘man-tech’: management technology.
4. Infrastructure Suppliers
DevOps and its automation require infrastructure APIs to control their environment and by doing so can encourage a wide range of behaviours.
Some projects are stable and need little change to their requests day by day; others would rebuild their environment over and over again. Using APIs also open the door to many different infrastructure providers, offering a wider range of services at differing prices.
Cost, however, is a double-edged sword: it may be cheaper and faster to set up, but data transfer fees can be prohibitive. Cloud management to monitor and maintain value is essential.
Market prices and services will change, driving sourcing decisions. Almost certainly you will have internal and external based clouds, plus the need to connect them and handle jurisdictional issues such as the European GDPR and ePrivacy directive. Perhaps the most significant reason for external providers is the opportunity to access a greater range of technology, such as GPU enabled devices for Artificial Intelligence and Deep Learning applications.
There are many innovations still possible with systems infrastructure, beyond the use of cost-sensitive virtual machines and containers. The range of possibilities will actually encourage more suppliers to the market, addressing specialist capabilities. For example, the use of very fast I/O but tightly bound to a grid of compute would be ideal for several problems and prove more cost effective than loose coupling over network.
Supplier management becomes contractual, technical and tactical. The future holds the prospect of managing multiple providers and needing to convert between them whilst attempting to minimise disruption. For risk sensitive industries, using multiple suppliers would minimise disruption in the event of a technical or commercial failure. It would also allow cloud consumers to trade-off cost, service and support with security, legal and political considerations emerging as additional obligations.
Skill Required
But perhaps the most important character for an established business is how they handle skill changes. To some, DevOps and the practice of agility is a shock, contradicting their professional training. It leaves their career adrift. I’ve seen people aghast at abandoning years of ‘best practice’.
There is less paper to fill-in and meetings to have, which is great for agility but it will leave a hole for more junior members of an IT team. Overall, the skill level is greater by quite a wide margin and enlightened organisations will want to help retrain their staff, aptitude allowing. Support people are developers now and will simply need to know the tools of their trade. They are responsible for the full stack, fixes and tests.
Retraining in addition to talent acquisition may also have an impact on costs, but overall it will be worth it. The cost savings from automation can be used to trim budgets or quite possibly enable the construction of a better product.
Invest in people and tooling, as you will need them. We have the next stage digital modernisation to deal with; did anyone say Microservices?
About the Author
Architect, PM and Strategist. Follow me on Twitter @nigelstuckey
System Garden
Agile Infrastructure for Enterprise DevOps
Design from diagrams, document and deploy to your cloud.
systemgarden.com, Twitter @systemgarden
[Note, Updated 24th April 2018]