That's like- the whole point. If you as a manager set a goal, those three choices are all the choices the people under you have to meet the goal, and you often set it up so that the preferred choice (actually make things better) is impossible. Its saying that decision makers need to be aware of this and adjust your behavior.
Like you said, if they don't, the people dealing with it have no choice- so, it'd be impossible to offer advice for those people, since they have no way of actioning it (unless its convincing the decision maker of that point)
JVM can run apps _compiled_ for it. WASM has the _exact same_ limitation.
Someone put in the effort to get Postgres to compile for WASM. That's great :) Maybe someday every application will compile to WASM as the preferred choice over the linux interface.
Compiling apps for different targets is VERY MUCH not a simple, low effort task though. Something like a database that must have an incredible number of optimizations in the way it makes syscalls, will have to a full stream of work to keep each target running well.
It can be done. But if "one of these thigns is not like the other" with your three things- Docker is the odd duck out.
It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task.
There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"
no, you're right. Terraform/Pulumi are much more focused on provisioning resources, while Ansible has its sweet spot in configuring a machine once its running.
Was a generator technician before I got into programming. Even the 2 megawatt systems could start up and take full load in 10-20 seconds. It sounds basically like starting your car with your foot on the gas.
The "when" shouldn't really matter- Diesel engines aren't a new thing. Warming them up isn't really a thing either- they'll have electric warmers hooked up to the building power to keep them ready to go.
The weird thing is- it could be a scam that is not actually a scam. If they have somehow acquired the legal right to use the author's name to release books, they don't need to swindle the ghost writers- they would probably be able to actually sell a decent number of books. The victim of the scam would be the author and her publishing company.
The author of the article had a great point. Developers often DO treat me as an IT person. The number of times I've taught a developer what an SSH key is or how to install a python virtualenv on the dev box blows my mind.
On the other hand, everything else he says is wrong. Devops isn't "ops gets out of the way and lets developers do crap and nobody owns it when it breaks" its... dev and ops WORKING TOGETHER. If you don't know what their app is doing YOU ARE NOT DOING YOUR JOB. (On the same note, if they don't know anything about how the system is deployed or the like, they're also not doing their job).
The rest of the article is literally about complaints about that.
The point that you can't monitor an app you don't understand, and developers don't want to push out crappy code, is the whole reasoning behind devops. The people no longer being in their own silo, but instead working together as a more holistic team to own the thing from end to end. If you stay in your silo but add automation, you are 100% going to have pain.
There is another pattern they could try, thats the platform model. In that case ops can stay in their little silo and present a platform with apis that developers can build on. Its what you're talking about here, and that can ALSO work. But its a different model. The old style of ops they would do as they were told, while trying to restrict anyone from changing anything. As a platform team, now they're delivering a product. They should be talking to users, and judging throughput, and iterating quickly, and being customer focused... basically, acting exactly as the developers are supposed to be. I am a strong beliver that the platform team should have product owners and customer metrics the same as the developers- heck, if they like QA, they can come up with a QA process.
But yeah, I've seen a lot of low effort finger pointing in orgs that pretend to do devops from inside their functional silos. That point, the one in the title, is a great one.
It matters. The floor is how easy you are to replace. The ceiling is the marginal value that you provide to the company. Considering how incredibly high that marginal value is, there is a lot of upward pressure at the top of the scale.
That's... not true. I was in a unionized software development shop at L3 communications in Camden. It was... different. Having a published document showing how the "top performers" were going to get a 3.5% raise this year while the average people would only get 2.5% was odd. Counting my hours (including signing out for lunch and getting management approval for overtime) was very different. Getting paid overtime was nice!
The problem is that if I had stayed there for thirty years, I would have been pretty much guaranteed to make good money. By changing jobs a couple times, I made that same money in 2. So... people who are capable of getting better jobs and willing to risk change simply left, while people looking for stability or who had trouble getting jobs simply stayed. This didn't lead to the type of environment that I enjoyed working in. Your mileage may vary.
Like you said, if they don't, the people dealing with it have no choice- so, it'd be impossible to offer advice for those people, since they have no way of actioning it (unless its convincing the decision maker of that point)