3 ms·

I think this is really a problem you see in every technology that tries to make things easier. JS. MongoDB. The list goes on. When a technology democratizes ac

by 013a 8y ago

I think this is really a problem you see in every technology that tries to make things easier. JS. MongoDB. The list goes on. When a technology democratizes access to something that was previously only accessible to those with more specialized skillsets, it will attract people who don't know enough to know how to use it right. But, well, they're still using it. Thus, left-pad. Its uncovering something that was always there; incompetence is rampant in software engineering. Ask the average engineer to properly set up an Ubuntu box with CICD for deployment and they'll likely fail, even with all the help of the internet. Ask them to get a docker image onto a server and they can make it work. Wider access to technology is... well, I don't know if its a "good thing" or not. We as an industry pretty strongly believe in "fail fast"; we write tests to make sure our code works, we structure our startups to recognize and pivot around failure, and if that failure comes we stop and say "somethings fucked, stop what we're doing". So I do get scared when a technology enters the stage which allows hard failure to be delayed as long as possible. Maybe we need more technology to be harder, have opinions, and be willing to say "you're doing this wrong, just stop and go get an adult." Because the alternative... Equifax? Yahoo? Ashley Madison?

lykr0n 8y ago
My personal design philosophy (from a System Admin, SRE, DevOps, Ops- whatever) is no black boxes. I'm not talking about knowing the inns and outs of every little component in my infrastructure/system, but instead of saying "This is Graylog" being able to say "This is Graylog- a Java app that uses MongoDB to index and Elasticsearch as a backend. We have to monitor JVM usage." The former is saying we depend on a system we have no idea how it works, and the latter is saying we depend on 2 java applications and a NoSQL database. It horrifies me that people run stuff in production not knowing how it's configured. But, this happens and is why there is just a booming market for DBaaS and other like productions. Docker is an amazing tool, but does make somethings a bit too easy.
0xfeba 8y ago
> Its uncovering something that was always there; incompetence is rampant in software engineering. That's what I took away from the article. Production was setup and they don't know what kernel version it has, or what JVM version it's using, or which C library, etc. Or, now we want feature X, so we need to upgrade dependancy Y. I already did it on my local machine, but Bob from DevOps doesn't like upgrading things on QA/integration/prod without a change control... Granted, apps have thousands of dependencies now, so keeping track of it manually is impossible. Docker came along and promised that only whatever's in this one config file is what's installed. Easy! So it eliminated lots of the server-specific configuration management but created other problems.
- lykr0n 8y ago
  I think it really comes down to developer tooling. Devs, in the absence of tooling will make their own and default to the latest stuff. If the company doesn't provide a fully mirrored developer environment, then everyone is asking for trouble. Where I work, we have a specific team dedicated to managing this tooling. We support Python Django, Java, and Go. You can clone the base repositories which include vagrant scripts to setup everything. You develop in that and it gets sucked up into the pipeline. You want something newer? If it works locally in our environment, the SLA says it will work in production. Doesn't work locally, then tough shit. In personal projects I do with others, I try and do the same thing. Python? 3.6 is our version target. Java is OpenJDK 1.8.0 latest. Rust & Go are compiled with the latest versions. It might not be incompetence in software engineering as a whole, but more of an issue in defining version and software targets.

by 013a 8y ago

lykr0n 8y ago

My personal design philosophy (from a System Admin, SRE, DevOps, Ops- whatever) is no black boxes. I'm not talking about knowing the inns and outs of every little component in my infrastructure/system, but instead of saying "This is Graylog" being able to say "This is Graylog- a Java app that uses MongoDB to index and Elasticsearch as a backend. We have to monitor JVM usage." The former is saying we depend on a system we have no idea how it works, and the latter is saying we depend on 2 java applications and a NoSQL database. It horrifies me that people run stuff in production not knowing how it's configured. But, this happens and is why there is just a booming market for DBaaS and other like productions. Docker is an amazing tool, but does make somethings a bit too easy.

0xfeba 8y ago

> Its uncovering something that was always there; incompetence is rampant in software engineering. That's what I took away from the article. Production was setup and they don't know what kernel version it has, or what JVM version it's using, or which C library, etc. Or, now we want feature X, so we need to upgrade dependancy Y. I already did it on my local machine, but Bob from DevOps doesn't like upgrading things on QA/integration/prod without a change control... Granted, apps have thousands of dependencies now, so keeping track of it manually is impossible. Docker came along and promised that only whatever's in this one config file is what's installed. Easy! So it eliminated lots of the server-specific configuration management but created other problems.

lykr0n 8y ago
I think it really comes down to developer tooling. Devs, in the absence of tooling will make their own and default to the latest stuff. If the company doesn't provide a fully mirrored developer environment, then everyone is asking for trouble. Where I work, we have a specific team dedicated to managing this tooling. We support Python Django, Java, and Go. You can clone the base repositories which include vagrant scripts to setup everything. You develop in that and it gets sucked up into the pipeline. You want something newer? If it works locally in our environment, the SLA says it will work in production. Doesn't work locally, then tough shit. In personal projects I do with others, I try and do the same thing. Python? 3.6 is our version target. Java is OpenJDK 1.8.0 latest. Rust & Go are compiled with the latest versions. It might not be incompetence in software engineering as a whole, but more of an issue in defining version and software targets.