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.
Even in 2016, I had been running production services in Docker successfully. Its interesting to me that they see the problem "Docker isn't designed to store data" without also seeing the solution "the docker copy-on-write filesystem isn't designed to be written to production- but volume mounts are". I hadn't seen docker crashing hosts (still haven't) - but I'm guessing that was caused by using the storage drivers.
The complaints about their development practices are valid (and haven't really improved), but even then the technology worked well so long as you understood its limitations.
A little. The thesis behind 'trickle down' sorta makes sense if you think about it. Less taxes = more money to invest = more investment = more economic activity. I did kind of expect to see SOME impact, though have felt for a while that the financial markets have become so disconnected from actual investment behavior that the impact would be marginal...and looks like this study concludes its even less then that.
That's exactly the problem: arguing that taxing the rich less will lead to trickle down / more economic activity / jobs etc sounds like it should work.
As the linked study (and many others like it) shows, it doesn't actually work in practice.
That might be obvious to you but history has shown it to be inaccurate. Of course rich people, who have lots of influence will be in favor of things that lower their own personal taxes. But in the us it has been show this does not lift others up. The thing that helps lift the overall economy is more money to less wealthy people, especially poorer, because they spend any extra income they receive on necessities.
This is one of many dangers of "common sense" style policy and legislation. It's very easy to make misleading or outright false statements and dress it up as "common sense" and sell it to millions of people over and over again decade after decade despite all evidence building up refuting it.
Sure, giving anyone a tax break will enable them to spend more and generate economic activity. However, generally reducing taxes also requires reducing government spending, which means less investment in things like infrastructure (which tends to create lots of middle class jobs). Basically the two end up cancelling each other out, so the result is just worse income inequality like the study showed.
Wealthy people invest in things that wealthy people want to invest it.
(Democratic-ish) governments, for all their many issues, tend to invest in things that can be justified to much broader populations (yes, I know, lots of exceptions to prove the rule)
Increasing private investment and decreasing public investment isn't a "cancel each other out" situation.
"A little. The thesis behind 'trickle down' sorta makes sense if you think about it."
Only if you only think about it. This is the danger of theoretical predictions without empirical backup: the path of the Laffer curve is dependent on more than just the tax rate, and is likely also historically dependent.
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)