This one has been simmering for a while, so lets see where this rolls.
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.
Devops is hot topic today, I keep on hearing around me - "In order to grow we need to change to a DevOps mindset" or, "We have to start doing DevOps.." Firstly, about those statements, I find them quite amusing because just by saying these things will not cause any change in the way things are done, and from these kind of comments - it is quite apparent that the source does not really comprehend.
I have all the respect for Developers, some of my best friends are developers, and I even dabble every now and again in writing code myself. So if there are any developers reading this, please do not take offence this is going to be exaggerated - it is based on my observations - but it is to prove a point.
Developers write code. That is what they do - and do it very well. Give them a problem and say can you write code that will make ObjectA do X,Y,Z - and provide functionality A,B and C - with the appropriate API's that can be exposed through REST - they will say, "No Problem, just give use the requirements of what you want it to do, and we will conjure up the code that will make it happen." Sometimes I am in complete awe of actually can be accomplished.
Most developers do just that. They are not aware of the infrastructure underneath, They have some idea about DNS, DHCP, authentication, Security, firewalls, these are all basic terms that they should know about and will probably have some knowledge of - but if you were to ask them how one of these things actually work - how they can/should be deployed, they really will not have a clue. Replication, load balancing, backup, migration, patching, these are all "dirty words" that a developer usually will not want to be hear on a cold and dark night.
I have all the respect for the the Ops guys (and girls). By this I mean the Storage guys, networking, virtualization, OS, deployment, support etc.. etc.. I have been one of these for many years. These are the people who spend countless hours trying to fix the unknown - because if they don't you will not have any email in the morning - and you won't be able to see the latest Dilbert. And when you accidently deleted that file that was so important and cannot be retrieved from another location and will cause your boss (and you) to lose your job if you do, they will be the ones to wake up at 02:00 to get it back for you. They are the people that will work 24 hours straight to get your website back up and running - because it was hacked. Sometimes all of the above is one person, sometimes different people and sometimes different teams.
Ops people know how to configure your firewalls, set up a load balancing solution, proxies, clouds, switches and make magic happen when you need to have a secure connection between the support center running from your SUV in Australia - and the NOC in the Antarctica, through a 3g Modem (I am exaggerating of course). Some of them can write some scripts and have been doing so to make their lives easier and manage to control a huge amount of resources with only their iPad. But they are not developers. Ask them to create something - it is not in their comfort zone. Ask them to create a portal that will facilitate workflows that will allow you to provision resources on demand in 16 different locations, based on load and the time of day, is not something that they can do. They would rather sit in the room room and and freeze - and not have to code for a living. But if you tell them that you need a database (with redundancy), and connection between two locations, and an Apache server farm with HAProxy for load balancing - that is something they would gladly create for you - even in their sleep.
Ask a developer to go through a change management process and he will shudder. Ask an Ops guy to deliver something in the next week as part of a sprint and he will duck for cover. Two different languages, two different cultures, meat and milk, oil and water, potato and potatoe.
Because of this - there emerges a dysfunctional process in the organization. Developers write their code - not aware of the operational aspects of what they are doing. A small example might be (and this is a real story).
Developer X devised a solution to do A, B and C, and the projected amount of data that was to accumulated per year was approximately 1TB. When approached by Admin J to ask why so much disk space is needed - because this will require an additional 3 servers with larger disks raising the price of the solution by a factor of three. Developer X then said - why so much? I can get a 1TB disk from the store next door for a 1/10th of the price and just shove it into a desktop and save the data there.
Sometimes developers do not understand the operational aspect. The data needs to be replicated - probably more than once - and backed up and so on and so forth - and if anyone would dare to put a desktop with a cheap SATA drive that purchased next door - they would taken outside and publicly pelted with rotten tomatoes.
Developers get their code out - and usually wash their hands of the operational problems that arise thereafter due to bad code, or bad architecture.
"Dev - We wrote the code - now the operations guys will support it."
"Ops - Why is it that we are the ones that get the SMS alerts at two in the morning when there is a problem with the component, the Dev's should be the ones to fix it"
And so back and forth.
Each of the two species will need to adapt, make changes and evolve - if they are to work together in a efficient manner - in the "Quest for DevOps". Personally I feel that the learning curve needed by the Operations people is much higher than that of the Developer's - but we all have something that we can learn from each other - and that will enable us to deliver, better products with a shorter time to market.
I could be way off - and then again maybe not - please feel free to leave your thoughts and comments below.