Just like any new technology, specially approach, DevOps had been widely misunderstood and you can look around and find such samples of misunderstandings. This happens when someone tries to follow the text more than the intent of the matter. We need to remember that if we go against the intent of something, no matter how detailed or how well we do things, it would defy its own purpose. Also, there are many opinions about DevOps in the market and the reason is same, one starts focusing so deep into other things, that they miss the intent. This has been the trend for webservices, SOA, Rest API, Agile, Scrum, microservice, etc. The same is applied on DevOps.
Yes, it is important for the developers to have basic knowledge on the infrastructure and network components to understand the debug the problems better as well as to write an implementation which works in the given deployment model. Additionally, it is important for a developer to know those things because in long run, the combined skills would be more valued than just being a developer. But the problem occurs when one starts thinking that all the team members would become infra and network expert suddenly or eventually. Not that it is impossible, it is not, but it is certainly difficult to do so. The best way to work with this is to have a dedicated DevOps team to help the development to ramp up eventually and help them do their work faster.
Team - Traditional Ops vs. DevOps
As it is DevOps and it is to be new team, someone needs to convert themselves to DevOps, either the Ops people or the Dev people. Problem with developers is that they think that the development work is GOD like work and thinking about deployment and infra work is minion's work. So, they don't want to convert to DevOps, unless they get to know it’s one of the highest paying job. The same reason pulls the Ops people to move to DevOps. The additional risk they have is that if they don't move, someone else will take this part from them. So, Ops people are more motivated to turn into DevOps.
Question is - who is more suitable? That can be answered by knowing what is needed in the role. Do you remember Breaking silos thing? So, by seeing that the rule to select/reject a guy for DevOps team is:
- The person who can understand the application and infrastructure both, is the right guy for the job.
- Who knows only one of the two is not the right guy for the job.
Often pure Ops guys just rename themselves to DevOps, which would not work in favor of the intent of DevOps. I am a developer who converted into a DevOps guy. Coding skills help as there is a lot of coding/scripting involved in DevOps.
Not sure if this is bad or just situational that DevOps is only considered as Automation. Am I assuming? Let's see. Pull out a DevOps related job. See the JD. Find out the tech stack in required category. Google for those tech stacks. Result?? All of them are automation tool/scripting. So, no I am not assuming. DevOps is seen as Automation; a lot of Automation and only Automation. The second part is the bad part.
It should not be considered as ONLY automation. The intent is to increase speed, reduce overhead and improve quality. Certainly, automation is involved but is the automation too geeky and not user friendly and if the whole team can't use it and you need special people to run the automation, it's waste!! Unless everyone in your team can, securely, use the automation, DevOps is not right !!
As if the DevOps buzzword was something small for the software community, we came up with even bigger terms like DataOps, DevSecOps, GitOps, etc. Looks like we love to add "Ops" and find it very high-profile word.
In my observation the word "Ops" means some kind of automation for/about/using whatever the prefix is there for the "Ops" in a given word. These words pop up every now and then and being used as a fancy word of show off.