> (Editor’s Note: In order to preserve the anonymity of my sources, the company in question will be referred to as “Friendly Business”, or “FB.” And I will pick a random name for ops engineers, such as “Mark.”)
Agree, it's a great read. I also thought the mention of "Plebian Stable" Linux being "as old as dirt" was insightful (and a great play on words, because "pleb" means "of the people"). Packages on the stable version of Debian are so outdated that using it in production typically requires constant back-porting of more modern packages, introducing all sorts of operational risks that threaten its stability.
I think this is a more of a case of wrong tool for the job. For example if i have a fairly static mail server configuration then it could best served by stable - I get security updates back ported but I won't have significant changes in the underlying platform whipping the carpet from under my feet.
Choosing stable for say the website may not be such a good fit though - the website is permanently in a state of flux due to having money and developer time invested with a lot more vigor, introducing new technologies to the stack, I'd be better deploying testing or more likely unstable under that stack.
For all I love Debian, the naming scheme has cost me many hours explanation to senior ops management over my younger years!
All that said, there is also the valid ops concern about developers introducing unproven tech just because it's in fashion even though there is no business, operational, architectural or even development advantage to be demonstrated or even hypothesised from it.
Its not fun for anyone when you have A team of developers with their dummy's out the pram because you wont open any to any routes on the dmz firewall so they can use some new sexy message queue when any one of the well behaved, well proven, stable alternatives would offer the same advantages.
Its not fun for anyone when you have A team of developers with their dummy's out the pram because you wont open any to any routes on the dmz firewall so they can use some new sexy message queue when any one of the well behaved, well proven, stable alternatives would offer the same advantages.
This sounds exactly like the type of infighting caused by having the developers not responsible for their app in production and having the ops team not responsible for meeting the needs of the app. Right or wrong, if this happens enough the developers will eventually get their own budget and go to Heroku.
Just so we're all clear, opening any to any rules on the DMZ means no longer having a DMZ.
That could be a valid move - there are always trade offs to consider and possibly the trade offs stack up such that you should no longer have a separate network for public facing services.
However it's part of the ops team's role to mediate all interested parties requirements and not just allow random changes to make something work right this second because one party needs it for their requirements. Every other team might be a bit miffed if we opened that thus breaking our SOX and PCI requirements and so landing us with a heavy fine, or worse.
I think the point you're trying to make is there are cases where such an action could be warranted and so the goal should be to make that resolution process as fast and as painless as possible for all parties.
Depends on how you're designing your apps: I've cleanly separated my app code (which uses a number of current Python modules) from the more stable system package (Apache, Varnish, etc.) and it's been at least 2 stable releases since I've needed to worry about backports.
