I don't know... My experience is the other extreme - tech teams that make everything super complicated to support everything that can possibly happen. As a consequence, the it environment requires six months of experience to even understand. It's really not very fun to work in those environments. Lots of unnecessary complexity.
On the other side of the coin, all these things would make sysadmins absolutely loathe you.
- You have 20-30 specialized applications which aren't package based stored in an application share mounted at /app with the convention /app/name/version or something but then this tool hardcodes itself to /opt/name.
- Using nonstandard ports doesn't make you more secure against someone who's specifically targeting you, but it absolutely stops automated attacks and logspam. What do you mean you can't change the port?!?
- Because there's no such thing as a secure internal network. All sites go through the hardened proxy.
- Invest? Nobody is going to pay for certs for internal services and who wants to set up a reverse proxy If you can't use an internal CA that's just poor form.
- That's a new one for me. I assume because they have a single shared database for all of their apps.
There is actually a reasonable arguement for the stored procedure one. It means you can have different permissions for tables as you do for stored procedures so your application doesn't have permission to directly query your passwords. The benefit there is if an attacker gains access to your application and/or the DB authentication credentials they cannot then export users passwords or other sensitive information.
Seems more efficient to me to use column-based permissions in this case, and create stored procedures for the queries you need to interact with the "sensitive" columns.
That of course does increase (dba) administration overhead, but it seems on it's face simpler and far more "programmer efficient" than storing every single query as a stored procedure.
It's a difficult thing to generalise but if you have a pretty large or complex application and DBA (or several) then it does sometimes pay to have your DBAs write the SQL because it's a different enough paradigm from normal backend development that not all backend developers are skilled at writing perfomant SQL. However few applications are that complex, not all businesses can afford a dedicated DBA team, and there are clearly a lot of very talented developers who can turn their hand to multiple different stacks. So it's a difficult thing to generalise.
“won’t invest in trusted SSL certificates for internal services.” <== this, I shrug my head every time. I’d do something about it If I didn’t have a billion other things to worry about like working services from teams.
I have the same experience and I'm on both sides in my day job. On the one end preventing developers from having to make the same (learning) mistakes that have already been made by ops so they can focus on developing and delivering, stuff like HA, security, backups, networking, statefulness, etc. Just deploying you apps on containers doesn't solve these problems.
But on the other end I'm constantly fighting the complexity of existing environment and preventing to much new complexity being added. It seems that every time a new tool/product is introduced which makes things simpeler, it just end up being a Hydra and total complexity is only increased.
I still have to find the holy grail if there is one, some middle ground? Or maybe it's just human nature to always make complexity where there is none since "It can't be that simple, can it?".
