MacStadium's prices are "rather less than 20%" of AWS's prices. To make sense, AWS would have to be comparable to MacStadium's pricing.
And don't forget the 24-hour minimum. If your duty cycle for a Mac Mini is only 20% per day every weekday, well, you can't rent a Mac Mini for less than a 24 hour period, so instead of paying for 20% of a month, you'll be paying for 20 work days, 60% of a month. On AWS, that would run you $546/month, 4x as much as you'd pay MacStadium for the entire month.
AWS's price is only comparable to MacStadium if you need five 24-hour periods per month (or less).
And, sure, AWS's prices will decline at some point, but I'm not expecting an 80% price drop this year.
So yes, AWS is still a shoo-in.
Don't even get me started on the data sovereignty and latency issues of a self-proclaimed "global" hosting provider that's only on two continents, neither of which we are operating in.
If you’re operating there, then your providers in all aspects will be more than limited.
Also, I'm more likely to transition to this because I'm familiar with AWS, I didn't know MacStadium existed before this thread.
If that's their target market (and not someone who wants a scalable Mac build farm available 24/7 and doesn't care about costs), then it makes sense - I pay a lot less than the price of a Mini to rent it 4 days a year, if Amazon can find 90 other people who want to do the same, all of us are better off.
Not at all. MacStadium is not inside the AWS network, so there’s nothing comparable about it.
I’m not sure why they went for a 24h minimum though. That defeats the entire point of cloud computing for me.
The problem is not the first time setup. The problem is essentially what “uptime” you can provide. Once you setup an infrastructure many people come to depend on it.
Lets say two teams lose half a day when that CI/CD mac mini goes down then paying for a cloud provider to manage many instances and “sharing them ondemand” makes a lot of monetary sense.
Of course, paying a cloud provider may or may not make sense for hobbyists. Personally, I pay for cloud storage - thats super hard to get right.
Besides, if your cloud spend is already a fuckton, $24 per day extra is not going to make you blink.
Otherwise I agree. 24 hour minimum removes immediate scaling as an option, and for anyone who already has their own infrastructure the cost is prohibitively high. My hope would be that with time, at the very least the 24 hour minimum would eventually be removed, and ideally the price will come down too.
Perhaps it's good for render farms. Instead of building a giant render farm that sits idle between productions, you spin up a render farm only when you need one.
If you're already in AWS, your deployment infrastructure and tooling is already configured and tuned for AWS. Deploying a Mac EC2 instance is just adding another target. Whereas deploying to another provider is an unknown amount of work to integrate with their API (if they even have one). The wall-time cost of people's time and effort vastly outweighs the marginal savings you'd get by going with a low-cost provider.
The money spent paying someone to set up a Mac server somewhere else, getting that somewhere else connected to your AWS networks, and ensuring that connection is secure, and generally integrating it into your existing cloud devops infrastructure (or, perhaps more expensively, not integrating it into your existing devops infrastructure), would, I'm guessing, be horrendously expensive compared to the premium Amazon charges on a relatively turnkey solution for use cases such as, "We need to run the occasional Darwin build."
Are you factoring in the 24 hour minimum AWS charges for a Mac Mini?
On my team, we just have a Mac Mini sitting under someone's desk to do stuff that requires a Mac. It gets used for about 1 hour every day for a daily build. For us, AWS's offering doesn't make financial sense.
Even if we were to switch to only doing a weekly build, it wouldn't be worth it, as that would still cost around $1,250/year.
OSX seems more prone to bitroot regressions than Windows or Linux, I suppose Apple have a "you're with us, or you're against us" attitude and this even applies to base OS backwards (in)compatibility.
What are you doing with macs that naturally works out at ~one continuous 24h period per work-week on average? Turn on CI once a week Thursday midnight, and no one goes into the weekend before all test failures are fixed?
This is the hard thing for me. I just like having so much control of having hardware at home, and I've got static IPs. But it costs to power and cool them, and they aren't elastic like cloud/IaaS. Having started the move to VPSs and finding them very good for the price, I'm now trying to wrap my head around "cattle, not pets", but still with a micropreneur mindset. I think it's still worth it, and my home office is getting quieter with every server I relocate to somebody else's hardware.
But the real place cloud/IaaS shines for me is when you aggressively scale, both up and down. If you're used to pets and physical machines then you probably over provision a lot. With the cloud you can ride the CPU/memory line a lot closer and scale quickly when needed.
...however is the AWS price including a lot of value the Mac mini colo price doesn't? I believe the AWS price is dramatically higher unless you can batch the 20% duty cycle into full days (AWS is following Apple's EULA and only billing in 24 consecutive hour chunks).
I'm not a "I can build in the garage cheaper", I'm a "we use to build servers that way, run them ourselves (and steal meeting rooms form ourselves and put extra cooling in), and then I went off to do other things for 20 years and now I work at a huge company where we build our own cloud stuff...but if I were at a less huge company how would this stuff actually work out?" kind of person (i.e. I know the _theory_ of renting other people's servers, but the finer points of actually evaluating it are not currently in my grasp).
The cost of housing and managing a unit of hardware is nonzero. Actuals vary wildly by location, purposes, and sector; but if everyone can get their heads out of the hobbyist-tinkerer mindset for a moment and consider that lifetime TCO is a real and meaningful consideration for businesses, then the component that isn't buying/leasing the server itself is typically several hundred dollars, per physical unit, per annum. Public clouds don't nullify all of it, but they swing the needle dramatically.
Since my duty cycle for a Mac Mini is rather less than 20%, the economics even of on-demand instances immediately make sense, and having it inside the VPC boundary without hybridising is gravy on the meat since I'm consuming several other AWS services besides.
These two factors (lifetime TCO and scale-down) are the economic foundation of the value proposition of utility computing. The "I can build that in my garage for cheaper" crew aren't wrong, but they're missing the point.
Putting on my sometime cloud infrastructure product manager's hat, long-term observers of service pricing may also observe the common enough pattern of starting a new product with a relatively high price, one that selects for early adopters and other price-insensitive (and, you hope, glitch/MVP-tolerant) customer segments, then gradually ratcheting prices down in order to estimate (amongst other things) the price elasticity of demand. It's naturally easier to get cheaper over time, than go the other way. In this AWS's position on compute is congruent to any other commodity merchant⁽¹⁾ with the luxury of being able to withstand potential losses on a single product line. For most EC2 instance types I'd expect they have a very good model of the price sensitivities, but mac1 is undoubtedly a unique platform with elevated uncertainty in the price parameters.
Which is my long-winded way of saying, it'll likely be cheaper in a few months.
-----------------------
⁽¹⁾ yes, yes, just like a fruit shop, very droll.