The software industry often seems to exist in a world of dichotomies and contrasts: business against developers, developers against testers, designers against business, and so on – towards infinity and beyond. When a particular activity within the software lifecycle and workflow is identified and codified, the need to differentiate itself from the rest then arises. This is how, over time, the two distinct phases of ‘development’ and ‘operation’ first arose – initially contrasting, but eventually reconciled thanks to the intuition of the DevOps movement.
What are DevOps?
However, the spread of the word ‘DevOps‘ has led to a weakening of its real importance and usefulness. In fact, although the initial intent was to offer a culture and the tools that would allow two people – a ‘dev’ and an ‘ops’ – to cooperate to create a working product, it is not unusual to encounter companies that are looking for people to do DevOps as a singular construct, or where developers learning and using some tools is considered sufficient to have a DevOps workflow.
These situations are often linked to a lack of understanding of what the activities of ‘operations’ people actually are, and the low importance given to ‘software operability’ in comparison with ‘software functionalities’.
In the upcoming Codemotion conference, to be held online on October 20, 21, and 22, 2020, the topic of DevOps will be addressed widely in numerous talks (you can find the schedule here). Not for the first time, our speakers will retrace some salient features of the DevOps culture, and the importance of software operability.
It takes two to DevOps
As it’s not easy to define and use the word ‘DevOps‘ – is it an adjective or an adverb? Is there a DevOps person or a DevOps team? – it might be more effective to start talking about ‘operability’.
We can define (software) operability as a measure of how well a software system works in a production environment, for both end-users and operations teams. There are many advantages in having a software system with good operability, including of course the simplicity of management, diagnosis, and recovery this offers in the production environment.
However, the path to good operability could require some changes in how the whole team approaches product development. For example, a good starting point might be to avoid the historical distinction between functional and non-functional requirements. Even without the negative semantic connotation of the term ‘non-functional requirements‘, it is more accurate to speak in terms of ‘end-user features‘ and ‘operational features‘, giving equal importance to both. Just as it is important to be able to check and test user stories – “as a customer, I want to buy a product“, for example – it must be possible to verify and test the user story “as ops, I want to switch a feature” in the same way.
The same approach can be applied to any operational activity: deployment, monitoring, status checking, reconfiguration, dependency management, and capacity planning, to name just a few.
How and why: focus on operability
Paraphrasing what is often said about the quality of software, the same principle applies to operability: you cannot test or inspect operability, you must build it in.
There are several core operability concepts and features that are important to have in a software system:
- the hooks necessary for the operations team to query and interact with the system;
- the traceability – which is static, and therefore knows the dependencies of the system-dynamics – to know who or what is interacting with the system at any given moment;
- an effective logging system and strategy;
- implementation of an efficient configurability;
- analysis and investment in the reliability and resilience of the software system.
The ways in which the actual implementation and improvement of the operability of your software is carried out may depend on the effective capacity of the team involved. At Codemotion Milan 2018, Marco Abis discussed some suggestions that are summarised in the following slide. In any case, it is essential to treat software operability as a ‘first-class citizen’ of a product and to treat ‘ops’ as a high-skill field.
Software operability is becoming more and more important nowadays, thanks to several factors: hardware infrastructures are moving to PaaS clouds or containerised systems, reducing the rollout times of the infrastructures themselves; the business requires fast development times and faster changes; software architecture is moving away from monoliths and towards increasingly distributed and complex structures.
If you are interested in DevOps and software operability, do not miss out on the opportunity to attend our upcoming Codemotion Online Tech Conference! You can find information about topics, the schedule, and how to book your spot at this link.