I bring here a translation of a post I wrote on September 27, 2016, in Portuguese, on the blog of the company I worked for at the time... I'll rescue this post to share with you what I'm doing. Are my next post is about what happened since are... from 2016 to the present moment, 2022.
You've read here in this blog that DevOps is not the new ALM, about the DevOps professional, about tools… but, what is DevOps really?
TL;DR… no! You will have to read the text yourself...
At first
At my first job, back in the late 90s… No! We have to go further!
Back in the 80's and early 90's… No! Further!
“In the beginning… everything was darkness!…” OK, let's not exaggerate, but we'll have to go back to the beginning of computing… back there at the beginning there was no distinction, there were no developers and operations, if you did one thing you had to do the other. Even because there was almost no one who did anything related to computers. Who hasn't recently seen film as a part of Turing's story, building his machine, coding the basic software, the only one that ran. There were no networks, there was no infrastructure, park, CPD or even Datacenter. It was the operator/engineer/programmer and ONE machine.
Woodstock
In the 1960s, programmers, analysts and operators emerged. While the first two were focused on writing code, the last one had a very basic function: operating the machine. In other words, it was necessary to feed the machine with programs written by others, take care of it, keep it running, collect results… and then, IT began to divide.
Disco
In the 70s and 80s we had the popularization of minicomputers and later personal computers, PCs. Apple, also recently represented on movie screens, showed engineers building their computers, but no longer for exclusive use, but for the masses! Product lines were created, there were programming languages, the goal was that these machines were not only in offices where they began to proliferate, replacing typewriters, making reports, storing information that was previously only on paper.
Let's rock!
If in the past decades machines arrived at homes, and then at bedrooms, with each person having one exclusively for their use… Why not, interconnect them all? In the 90's, computer networks gained protocols, hardware and monitoring; transforming the islands of professionals into collaborators. It was possible to share. And those operators were empowered to manage that connectivity and the responsibility of keeping everything up, while the programmers and analysts stepped away from that responsibility and kept their attention on the code.
Some took care of the abstract and others of the physical.
dance
And then came the turn of the millennium, the fearsome bug did not show up in the announced apocalypse, but IT was seething with problems… problems that the industry was already solving. And then came the total quality programs, the famous process methodologies, RUP, UML; designed to improve communication between development and operations, the developer needed to tell ops what to do to install the software they were producing; it was necessary for operations to explain the infrastructure that could support a distributed system for dev…
But the separation had existed for a long time, communication no longer existed, only disagreements. It was necessary to bring the two together again… More than that, it was necessary for them to become ONE again.
chaos photography
After my first job, in the area of building automation, where I used AutoCAD, and I started programming in VBA… I moved to development.
If you've experienced the fever of implementing the RUP methodology, you may remember the whale diagram, I'll put it here out of nostalgia.
RUP diagram
RUP diagram, source https://en.wikipedia.org/wiki/File:RUP_Workflows2.gif
The RUP showed a concern for the environment at the beginning of a project, the Environment is built in small portions over the iterations. However, this process was not performed in “columns” but in “rows”! In other words, the environment was only thought of at the end of the project… so the developer did not know where it would work and, worse, many times operations did not know that a new project was coming!
This is repeated to this day. Include there the turnover, incomplete documentation, poorly executed methodologies, poorly made projects… and everything turned into chaos!
streaming
And then we come to the last few years… with the startup boom! Even though Apple, Microsoft, Google started years ago, and in the garage, as a good startup. The last few years we have seen an avalanche of startups being created, growing and being sold at stratospheric prices.
Today it is possible to have access to advanced equipment to assemble a highly efficient production line… Don't want to assemble the line? It is possible to outsource, rent, even borrow these machines. Do you want to start a service company? No need to rent a space, buy equipment, furniture… machine and network infrastructure… do it in the cloud! Got an insight and want to test the idea first? It is also possible, with reduced cost, from the notebook, on the sofa, in a cafe… using a machine at the other end, doing calculations… for free!
These companies cannot afford to have communication problems. They can't wait months for software, which never seems to be ready. More than that, you can have no doubts about how all this will work.
DevOps
Welcome to the era of collaboration, or, welcome back to the roots: developers & operations, working together, side by side. Or as ONE only. And that's all...
Yes, that's all.
A startup is born with a collaborative environment, because it needs it, or it will die.
On the other hand, large companies, divided into their silos, areas, departments, … need to discover a new culture, need to change, or evolve. Or will they continue in the quality, improvement and planning programs; disconnected, punitive; unable to advance.
Be wary of any DevOps vacancy. If it exists, it's because there's no collaboration, because people will each remain in their own silo, in their own square. And this is not DevOps
Also be wary of DevOps tools, as none of them will bring a new culture. It can help, but it won't change what's ingrained in the company, no matter how flexible and interesting it may be. And that's not DevOps either.
DevOps is collaboration, it's militancy, it's mainly culture, because you have to want to do it. And culture, we live it and we maintain it. It cannot be installed, purchased or hired.
Top comments (0)