1. Starting observation
It’s a word we hear everywhere, as soon as we work in IT (or not far from it). It’s a term that’s on the rise and generates a lot of fantasies. We’ve even created a job from it:
“The devops”
Except that no. Conceptually, the devops job doesn’t exist. Devops is not a job, but a work philosophy. It’s something that comes on top of a job, that comes in addition. It’s a new way of looking at this job, which is either developer, or administrator or system technician (or tester/integrator possibly)
Devops should be compared to agile. We don’t say about someone: “look, we just hired an agile”:
an “agile”, that doesn’t exist.
Devops is a change of vision on jobs that have existed for a long time and have struggled to reinvent themselves until they reached the point of having diametrically opposed objectives.
Ops (system teams) have as their vision the stability and performance of their infrastructures. A beautiful platform is one that doesn’t crash and efficiently and quickly delivers the service for which it was defined. Any evolution can disrupt this fragile balance and this hard-to-find harmony. The vision is long-term. The ops is caught between developers and end users of the platform. If it crashes, they’re the ones who get yelled at.
The developer, on the other hand, has the mission to evolve the platform. They must follow marketing needs to create new things that will grow the company. They are often given little time to create these new features, which often translates into things delivered and poorly finished. These poorly finished things jeopardize the stability of the platform so dearly pacified by ops, making them even more suspicious of integrating new things. Dev thus become a source of instability for ops just as ops are a brake on putting dev work into production.
A wall thus stands between these two jobs. It must be torn down. The devops philosophy starts from there.
2. Definition
The 4 pillars of devops: **CAMS**
C for CULTURE
Devops is above all a culture that feeds on the best of development and operations cultures. We take the best of both worlds and create a new one that will take into account the specificities of each of those from which it comes.
Devops tends to create a corporate culture around what makes it rich.
A for AUTOMATION
Everything that can be automated must be. Human actions that generate errors, on which we don’t capitalize (on top of that!) should be avoided. What’s the point of writing a process that will be executed by humans? Might as well directly write scripts and use tools that will do the work without us. We will have all the leisure to iteratively evolve these scripts/tools by improving them each time.
We will also save time for teams by removing tedious work for which team members have little interest/added value, leaving them to intervene on the perimeters where they are most effective.
M for MEASURE
Running applications in production without knowing if they really run and are effective amounts to doing magic without mastering anything. We are at the mercy of almost everything that can happen (sometimes, we’re not even aware that it’s malfunctioning) and condemned to react in disaster to everything that is not planned.
By placing the right probes and retrieving the right metrics, we can anticipate upcoming problems and know the points to improve for good application performance.
S for SHARE
One of the important axes of devops lies in the fact that nothing is done alone (that’s why it’s neither a job, nor a team role). Indeed, the stated goal of the approach is to pool the skills of each other to achieve the common goal, which is to provide the best possible product.
There is no “preserve” of a team or a person. Sharing skills between teams tends to bring people to develop a common language, collective intelligence, and therefore, a common culture.
Why keep methods that don’t work?
3. Devops: the search for efficiency
Through the elements mentioned, we realize that the devops philosophy is mainly a search for collective intelligence. In the same vein as agile methods, the goal is to make application creation and maintenance cleaner and more efficient by taking into account the entire lifecycle of projects from the start before writing a single line of code or configuration.
We often wonder why applications developed by large public structures often have disappointing results when put into production. The main problem is to be found in inter-team communications that are failing, or even totally absent. How do we produce so poorly with so many good developers, project managers and infrastructure teams? How do we do so little with pharaonic budgets? How do startups of a few dozen employees at most become unicorns that ridicule large companies?
Communication
Teams are too large, too scattered, and therefore, not involved enough. Some discover too late the modifications/specifications of others and must adapt with shaky solutions or even cancellations of important features.
To introduce a bit of “devops” into all this, it is absolutely necessary to reduce perimeters and directly integrate multidisciplinary teams. And as everyone knows, a startup will always have more ease than a large structure to achieve this goal.
4. Devops tools
Saying “good methods” also implies associating the right tools with them. The ecosystem is rich, concepts numerous and competition fierce. So we must first choose what we want to do before choosing with which tool. All this requires some experience, and therefore junior devops profiles will often not have the necessary perspective to do more than a wishlist of technologies they would like to play with. (read my article The hell of DevOps profile recruitment)
Infrastructure as code seems a good starting point to understand to better grasp devops concepts, and more or less managed or virtualized infrastructure of different clouds.
Clouds, or “someone else’s computer” are also a search for efficiency, as it avoids having low-level system skills, focusing on as a service infra where we pay for skills we don’t have. From a certain volume, acquiring these skills will however avoid seeing cloud bills explode (AWS is notably quite opaque on its bills and fees). Cloud bills of 5 or even 6 figures can arrive quite quickly.
CI/CD consists of
- Continuous Integration (CI)
CI is the integration of code up to the compiled/final application. It’s the management of branches and tests on these branches to validate that the code is clean and the application functional. A test chain will be applied to the code to make the application. The target of CI is The deliverable
- Continuous Deployment (CD)
CD is the automated deployment of these applications on environments, whether test or production. We transform an application into a service via scripts or infra configuration. The system infra can even be created on the fly with application needs. The target of CD is The application running in a defined environment
5. Conclusion
Devops is not a job. Devops is not a role. No one wears the devops hat just as no one does agility alone. It’s a team philosophy and a search for efficiency. There are many tools, but they are useless without the concepts that carry them. Using tools without worrying about the needs that created them is like putting a 5-year-old behind the wheel of a car: they’ll know how to press the pedals, turn the steering wheel, but it’s likely to end in an expensive crash…
On the contrary, find the right map, see the right GPS and you’ll go very far in a minimum of time!