Idk about the drama, I just get stuff done and keep going.
144 karma · joined July 30, 2012
Idk about the drama, I just get stuff done and keep going.
Hopefully some of that can be reproduced in further studies.
Just anything I can do to subdivide the problem space and iterate more quickly.
Since there’s some spool up time on printing (heating up and leveling) sometimes I also bracket parameters 5% on either side of my value and print 3 tests to see if those fit better or worse
The graft team tried to get the state government to give tax graft to "datacenters" but didn't define what a DC was - which could mean the graft might go to bitcoin farms as well.
I noticed that the article does not really distinguish between any of these.
Please excuse my English, graft is not my first language.
https://gist.github.com/573/e5cf230a03c5d53f848b58c3ced0bc95
I can and do pay for news, I just dislike the bait and switch with modals/popovers that much. Now that I can no longer block domains in my Google search results, I can't remove those paywalled sites from relevancy and it's hard to keep track of everyone who only lets you read the first paragraph and a half before sticking their hand out asking for $10.
ETA: I have now read the article and have no revisions to my statements.
Extended support costs on old hardware and software are sometimes astronomical. Then you're paying all of that to get something that, compared to modern gear, performs like ass and just breaks all the time.
I've also had C-suites tell me I have two months to start a project and have all the gear live, but I find we are only allowed to order direct from the manufacturer, and our orders will take 90 days to get to our door. Oh boy. That scenario is difficult to put into terms of money. Sometimes having that one-hop instant supply chain into a cloud service is a huge business enabler, sometimes it's not.
1:1 lift and shift is always obscenely more expensive. In this case, if the author had been in charge of the migration, then yes, the services would have cost them dearly to operate in the cloud.
I'm sure if I was personally put in charge of moving some aspect of IT into an unfamiliar mode of operation, my inexperience there would make my approach insanely expensive as well.
That says nothing about the target, except that having undertrained and inexperienced staff in charge of its design and implementation is probably foolish from a financial perspective.
There are obviously thousands on thousands of scenarios where moving to commodity cloud is an absolute slam dunk in aspects that are important to the subject business.
Unfortunately we really get no insight into what the workload truly is in the article's comparison. There's no mention of solution aspects like app architecture, security, HA/DR, SLA, RTO/RPO, security or backups [1]. We only get what is plainly a tunnel-vision view of a comparison.
It's almost like the author doesn't make solutions for a living.
Maybe the author actually realizes their blind spot, and is secretly utilizing Cunningham's law to crowd-source a relatively free solution from the professionals and amateurs in the internet comments sections.
The good architects don't work for free. There's a reason why Troy Hunt's web services cost him vanishingly little to operate, and it's certainly not by running IaaS VMs 24x7x365.
[1] I mentioned security twice as part of an ongoing effort to make up for all the times CyberSec/Infosec teams have been forgotten in the planning process. =P
For them, managed DBMS was a life-changing event. As soon as they had RDS or even Azure SQL MI, they were begging the cloud team for more, so they could get their team back.
In some businesses, it's definitely not a big loss to lose agility by having a large portion of your team tangled up in infrastructure management, but for some businesses, that constraint is an impediment to their line of business. Some businesses are missing opportunities for want of infrastructure being able to move fast enough.
You can build Linux containers just fine with Packer/Ansible. But to your point I already stated why I use Ansible and Packer for container images: "if you're already using those to configure VM images and Ansible to perform config mgmt on VMs"
I currently build a number of images with Packer and Ansible across Linux and Windows. I choose not to rewrite all of that from scratch in a crummy Dockerfile when I can just have Packer and Ansible make the images alongside everything else they're already making.
A lot of the things that ran in Windows Nano Server worked even better in Linux containers, and a full Windows Server Core container is usually only necessary for .NET Framework, where you will need all of the luck in the world help you with that problem.
Packer and Ansible are also much harder to use for Windows Containers, so if you're already using those to configure VM images and Ansible to perform config mgmt on VMs, get ready for some headaches to make that work against Windows Containers.
At this point you could give me a FreeDOS machine and I'd be like "Well this initially looks super inconvenient, but I realize you won't be able to VOIP call me through the device, and it looks like I can get enough stuff installed to SSH to our dev environment. We're good."
We have an ALDI here at least.