Re: I wish I could believe in the promise of Dev Ops.
So, I'm going to write a little about my experience as a non-developer. I've worked in the DevOps business in 2010 building Ant scripts and using Hudson to CI and deploy applications.
I usually separate DevOps in two things: Developer side and Infrastructure side.
--- On the developer side ---
This type of DevOps thing is perfect because there's a real lack on knowledge of infrastructure at the core of the typical software projects. Teams need both Application Architects and Infrastructure Architects in ALL software projects from beginning to the end.
- Deployed new code on a 3-tier application:
-- Developer: If it works on my notebook and doesn't work in production, that's not my problem;
-- Me: Checking the logs and there was a web service declaration in web.config with URLs 127.0.0.1 or localhost (btw, it happened like 3 times a week and stopped when the App Architect told them if they do that mistake again, they had to buy a cake the next week);
- Receiving files via web services and sometimes the file didn't show up in the App (3-tier application with 2 servers per tier with LB):
-- Developer: I receive a file and I write to disk, if it doesn't work in production, that's not my problem;
-- Me: Checking the AppServers, the file was in AppServer01 and not on AppServer02. When user logs and goes to AppServer02, the file doesn't exist there. Solution, another server exporting NFS to both Servers (not perfect but worked);
Developers really don't care about infrastructure. They really don't know it, they are afraid of it, they just take it for granted and "that's not their problem". I can understand that because they have to work 12 hours/day translating business to code and the PMs whips them if they get behind schedule. That's why Docker/Vagrant/CI/CD hype is huge for them. They just type one command and done! The reality is that it doesn't solve the problems in software development.
--- On the infrastructure side ---
People, please! Real SysAdmins use scripting to facilitate repetitive work and Configuration Management software always existed in enterprise environments! Ever heard about PXE, TFTP, kickstart or running remote commands with SSH on multiple servers? The philosophy of automating tasks was already in the infrastructure side! Now there's puppet, docker and others. OK, cool! Changed the tools, maintained the philosophy! Just use your head and help the developers!
Tips for infrastructure guys when dealing the developers:
- Charge the developers infrastructure usage;
- If the production environment has firewalls, load balancers and multiple servers per tier, just implement the same structure in DEV/QA environments (helps spot configuration errors);
- Try to allocate minimal resources as possible (CPU/MEM/DISK) for DEV/QA environments (forces them to optimize code);