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.

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).

1. You are a big company who needs Mac CI and your IT department has a strict "Cloud Only" restriction.

2. You are a developer for a cross-platform App who doesn't own a mac, but needs access to a real mac every few weeks or months for debugging/releasing.

But the 24hr thing kills it for me. I will never get 24 hours use out of it. Maybe a few hours. Why am I paying for the other 21 hours?

Maybe someone can wrap this SaaS in a other Saas and sell timeshares in a virtual Mac.

Unsure if you've seen the comments elsewhere in the thread but in case you haven't and this is a genuine question - because Apple's EULA forces Amazon to do this.

Is the answer simply "Because they can and they like money?"

That's exactly it. If you could rent Macs by the minute, you wouldn't need to own Mac hardware anymore to build Mac apps, and the cloud provider wouldn't need to own as much.

It seems this is Apple's sole motivation when it comes to anything developer related, which seems odd considering their goal is to commodotize software to sell their hardware - you'd think they wouldn't keep making it harder to make software for their platforms

That's precisely what the EULA prevents, otherwise Amazon would happily sell you smaller slice of time.

Yes but I'm more likely to vierualize on my more powerful and better value PC. The EULA is rather hard to enforce and I don't have any moral qualms in this particular case.

People always do this on HN. "I can only think of two things, so those are the only two things that can possibly exist."

How about a render farm? If your company only produces three or four videos a year, why build a render farm that sits idle for half the year?

You mean have opinions and open discussion? "I can only think of two things" doesn't mean "there are only two things exactly and everyone else is wrong". Welcome to the Internet, I see you are new here.

No, dismiss the possibility that there may be things that they don't know about or understand.

"I can only think of two things" doesn't mean "there are only two things exactly and everyone else is wrong".

But that's precisely what he said: "exactly two usecases for this service" He didn't write "I can only think of..." You're making stuff up.

Welcome to the Internet

I shall say the same to you, since I've been online since before the internet, back when you had to manually route e-mail, and it took a week to get a message from New York to Paris, if you were lucky.

I see you are new here.

Welcome to HN. I see you're new here. Be sure to read the rules about unhelpful snarky responses.

> You can also buy the equivalent Mac Mini for $1,899.

Not only that, but MacStadium lets you run multiple VMs on a single Mac at no extra cost. Amazon's offering is seriously underwhelming.

The more I use or learn about MacStadium, the less impressed I am with it (3 layers of virtualisation is overkill in my opinion!), but it beats the hell out of what Amazon has just announced.

The big problem with CI/CD on Mac is that Xcode does not allow you to run builds in parallel, so you need one Mac per build unless you use virtualisation.

To be honest I'm surprised that no one has added namespace/jail support to macOS yet. The XNU kernel is open source so this should be possible. In fact, can someone explain to me why there doesn't seem to be any sort of XNU hacking community?

To the hobbiest market, yes. But large companies, at which this seem to be aimed, work with names they know, not names they don't.

The company I work for would pay more to use Amazon than MacStadium for equivalent products. That's just how corporate bureaucracy works. It shouldn't, but it almost always does.

Yes it does. The Xcode GUI only allows one build at a time, but you can run multiple `xcodebuild` command line builds using the same or different versions of Xcode in parallel, even under the same macOS user.

For running tests, there used to be problems if you were trying to invoke the iOS Simulator for different versions of Xcode in parallel, but those issues were fixed 4 or 5 years ago.

I've setup and used a set of bare-metal Mac mini CI runner, each configured to run two jobs in parallel, and the Xcode pieces of that are rock solid and didn't need _any_ workarounds to enable parallel jobs.

This isn't true. "xcode-select" forces you to set a system-wide Xcode version. If you have a job that uses one version and a concurrent job selects another version, it will potentially break the first job.

Probably because (from what I've heard), even using xnu is extremely painful, let alone hacking on it.

And it's not like you can re-compile your changes to xnu back into a working MacOS machine

Wow, that's just awful, but it would it explain it. Thanks!

Nowadays, however, Hackintosh tends to rely entirely on patching the kernel in memory, even on esoteric platforms like AMD. Custom kernels are really inconvenient for a few reasons—they get set back to stock after every update (which potentially means your computer won't boot, if you forget to put the custom kernel back before your machine restarts), and Apple releases XNU's source on a ~6 month delay.

I would love to see more kernel experimentation, but I think there's just not a lot of reason to do it? If you're on a Mac, you don't need to add support for new hardware.

That said, it would be great to get a kernel which e.g. disables TCC, or maybe which removes Big Sur's signed snapshot stuff. Both of those feel like achievable tasks, and they would have a real use!

Paying these premiums is all in the furtherance of a good cause called “Bezos getting another hundy billion to his name”.

I'd have loved to have seen mac pros, and virtual instances (subdivided, even if you had to maintain a dedicated host to run them on), but this is still a major quality of life improvement for heterogeneous environments.

The only reason this would make sense is if you needed to actually host something with >99.9% uptime or high bandwidth needs on a Mac.

Paying by the second is also ideal for these use cases. You run a build occasionally, but it mostly sits idle.

Pay by the second would perhaps be preferable but unless I am reading this wrong you have to pay by the hour and it's relatively expensive.