Apple has been very supportive of cloud-based Macs, there’s a pretty big data center* that has been providing them for years, was the trash can now mostly Mac mini iirc.
*edit: macStadium as the post above reminds me
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Developers Now Able to Natively Run macOS Within AWS With Amazon EC2 Mac Instances
- Thread starter MacRumors
- Start date
- Sort by reaction score
*edit: macStadium as the post above reminds me
Amazon as a whole is an evil corporation that needs to be broken up. You are better off in the long run buying a used Mac mini and setting it up as a server.
They are basically servers that you rent. They are virtualised, so they appear to you be to a completely fresh OS install (usually Linux) and you build your online business on them. Because you can be running 5 servers one minute and 10,000 the next with virtually no effort, they are appealing to certain businesses. Services like Dropbox, iCloud etc, run on these things, plus lots of enterprise number crunching the public will never see, from NASA and the CIA, to CGI rendering and medical research. There are a huge amount of tools available to support businesses building these applications but they are not designed for the average user. As you say, it's somewhat like getting a raw web server, but it's more fundamental and powerful than that, and there's a whole marketplace of framework and technical services like video encoding, AI speech recognition, etc.
If you are technically competent you can make use of AWS even as a single user who doesn't code, but you're going to need a valid use to justify renting per hour over buying your own hardware. That justification is usually that you need to ramp up processing capacity from time to time, or you want to host a service of some kind.
And if you need a cluster of 1000 servers for a period of 6 hours?
There is no citation needed. The new M1 machines can build, and run, iOS applications natively. There will be no reason to have a translation layer, like they do right now with the simulator. That is what they are referring to.
People have been making unfounded claims about "Apple is going to make Macs run iOS" since about the time it was renamed from iPhone OS.
There's zero evidence to support this claim, and mountains of evidence, including on the record statements from Apple executives, against this claim.
I think it's utility is pretty limited by the 24 hour minimum. That means if you have daily app builds running you are somewhere around $500/mo since every weekday will be $26...at that point you could just buy a mini and send it in to MacStadium, and in one month you'll be ahead while owning the hardware.
This is might be good for companies that run a specific service on Macs that can host multiple users on one Mac EC2 instance, but even still, the Macstadium route will likely end up being way cheaper and more performant. The whole point of EC2 is to be able to spin up servers when you need them, and turn them off when you don't - with a 24 hour rental window you lose that completely.
OK, let's dig into this a bit. Outside of the rest of that not necessarily being as complicated as you make it out to be (more on that below), when it comes to AWS and ECS/etc there's nothing stopping them from transparently running MacOS containers on Mac hosts. ECS is so abstracted that it shouldnt matter to the end user what hardware it's actually running on.
Re: containers and XNU: On the backend of that there's no reason why the docker engine can't use the native virtualization tools in Big Sur to run MacOS containers if Amazon or Docker (the company) or another entity wants to invest in doing it, it would work functionally exactly the same way parallels et al can virtualize MacOS on MacOS in Big Sur and it's perfectly cool with the current Mac licensing to virtualize MacOS on Apple hardware.
The main reason it really isn't likely yet is that the current way you can get cloud capabilities, and what AWS is now doing, pretty much already fills the niche for MacOS use on that end of things well enough that no one has invested in anything more. Most of the use of MacOS in a way docker would be useful for is as build systems, most of the rest of what MacOS is used for is GUI based and not great for docker. With AWS and the push towards serverless architectures and services there I do wonder if that will change at least in the build system category.
What *Apple* would have to do to make MacOS docker containers more useful outside of things like ECS, which is what I was mentioning "if they allowed it", really is to (legally, you can, of course, do this with hackintosh type builds) allow MacOS to be virtualized on non-Apple hardware. I don't see it happening but that was what meant.
Other than that all the pieces are there as of Big Sur for AWS to create ECS MacOS docker containers running transparently on their racked minis if they want to.
I was curious and took a quick look at the relative pricing. If you want the same Mac on MacStadium with a firewall it's about $250 per month.
On AWS, if you wanted to run a Mac during working hours it would be around $220 per month... IF Apple hadn't imposed the 24hr minimum BS. Because of that, it's more like $600 per month.
If you already have a large AWS footprint that $500/mo may be lost in the noise, and if it lets your current devops team and tooling handle it it costs less than having an admin handle that physical machine. If you already do something like manage your entire deployment with Terraform as we do here at my job or some other infra-as-code option then that $500 is easily covered by the quick PR to add the machine and get your devs working rather than dealing with physical hardware (especially if you don't run any other physical hardware). It also provides redundancy and integrates into your AWS deployment without having to use something like the SSM hybrid agent. If we were building Mac apps at work I wouldn't even blink at the $500/mo vs a physical mini, it would be much much easier to deal with, that's worth the cost, and that's what they're counting on for selling this
You mean apart from no support in macOS to host containers, or run software within containers? AKA point 1 in the post you quoted.
I honestly don't know if you don't know what containers are or if you are trolling.
Virtualisation is literally about running a virtualised, entire computer. While it may know, it's running on virtualised hardware (i.e. if it's PVM), it's doing everything a regular OS on hardware does, from the kernel through to the software you install and run.
Containerisation is running programs in a different execution context, under the control of the kernel. On Linux this is built around cgroups. I don't know what the name of the API in windows for it is, but it's the same concept. The kernel runs some programs in isolation from other programs.
.. So not containers at all, in any way, shape or form.
The main reason it really isn't likely yet, is that it isn't possible yet, because macOS has no containerisation support. It's nothing to do with market demand or investment cost.
Once again, you're conflating containers and virtualisation. Apple could send every person on the planet a gold-stamped letter saying "You are allowed to run as many virtualised copied of macOS as you want, on anything you can make them run on, including but not limited to a Whopper with cheese", and that would have zero impact on macOS being able to host containers.
No, they really ****ing aren't, and please stop making claims that you have zero idea about.
It means instead of buying your own Mac mini and hooking it up yourself and using it until Apple forces you to buy a new one, you can pay AWS several times more than its worth to know how to hook it up, upgrade it, etc. It means when something is wonky you can wait for AWS support in India or some other Asian country to get back to you.
All so you don't have to know how to hook it up and update it.
The same Mac mini - 6 core, 32GB is $139 from Macstadium. If you want to pay for a dedicated firewall appliance too, that's on you, but adding random unrelated appliances to make them seem more expensive than the competition is kinda weird dude.
Also I'll note, that the Mac stadium price includes unmetered 1Gbps network. The AWS offering is 10Gbps, and you'll pay through the ass for that, because Amazon have amongst the worst data-transfer costs of any hosting arrangement I've ever seen.
AWS is firewalled by default, MacStadium has all ports open by default. Adding the firewall to make them equivalently viable wasn't random. Sure, the comparison doesn't scale to a fleet of 1,000 and MacStadium would retake the lead easily, but there's no need to go on the attack. It was Apple's 24hr minimum I was aggrieved with.
Hmm. Am I missing something? Yes, choice is good, but can't you still run MacOS under VMWare? What's stopping people of creating a VMWare MacOS machine image and putting it up on whichever hosting provider they want?
Do not give Amazon any more money. You can do the same thing with MacStadium; a company that has been working with Macs for many years, and has great support. Bezos has enough; don’t buy into the hype. I see developers pulling away from AWS every day as competitors have matched or beaten them on price... and more importantly, DESTROY them when it comes to support.
Think of EC2 as the hardware and base OS of a virtual computer.
If you need a web server then you can take this base OS (usually a flavour of Linux) and install whatever is needed. For example, an EC2 used as a web server needs Nginx or Apache installed, plus a web framework such as PHP or .NET Core. That can be done through SSH.
Add to this other AWS services to fully enable the web server, such as Route53 for DNS and S3 for hosting static content including images and video. Each service is billed separately on your monthly statement so you pay only for what is actually used.
If you're a small shop that'll work great. In a bigger organization where things need to be more reliable that won't work as well. Once you have a few developers working the downtime of that single server will cost more than the cost of a Mac mini.
Nobody can build, nobody can test, nobody can release because that mini in your house got turned off by your child...and you're out at lunch, or got hit by a car, etc.
Solutions that work for small shops don't really work once you get to a certain level.
And the whole "X is evil" thing is tiring. That's like saying a hammer is evil.
If reliability of a single "thing" is your goal, AWS is not your solution. AWS is an ever growing, ever more complex, inter-dependent Rube Goldberg machine. Every time AWS ***** the bed, it does it in more spectacular and fantastic ways, and their staff are incentivised not to make public when things are going wrong.
Uh, no. us-east-1 should be avoided at all costs. However, the rest of AWS is super-reliable. I'd challenge any organization to have as much uptime as AWS (excluding us-east-1). To be frank, most IT shops just aren't good enough to keep their systems running as well as AWS.
Most AWS failures that companies have are because their staff screwed something up. That's the nature of technology, not AWS. AWS makes it easy, but that doesn't mean you can be a complete ignoramus and be successful; you still need to know what you're doing - at every level.
If a developer leaves their MongoDB instance open to the world that's not an AWS problem, that's an organization problem; why are you letting a developer touch a production system, much less deal with networking, which 99% of devs are completely incompetent at?
Background: used to build high-availability applications across real datacenters across the US from bare iron upwards.
> Most AWS failures that companies have are because their staff screwed something up.
If a single company using AWS screws something up, we don't get "half the internet is down" posts on HN and tech news sites, where it turns out the root cause was one failing system, which ballooned into 35 failing systems, regardless of whether the customers use the original system that failed.
Stupid people exist all over the place, sure. But my point is that AWS is such an overly complex environment, with so many hidden inter-dependencies, you can do everything right and still get ****ed.
The only way to be truly resilient to outages, is to be multi-DC, multi-vendor. And if you're multi-vendor, you'd be crazy to use vendor-specific services, because even when they're intended to do the same thing, they're never going to behave the same across vendors.
So then you're just using basic units of compute and storage... and at that point, AWS makes zero sense, cost-wise.
If a single company using AWS screws something up, we don't get "half the internet is down" posts on HN and tech news sites, where it turns out the root cause was one failing system, which ballooned into 35 failing systems, regardless of whether the customers use the original system that failed.
Stupid people exist all over the place, sure. But my point is that AWS is such an overly complex environment, with so many hidden inter-dependencies, you can do everything right and still get ****ed.
The only way to be truly resilient to outages, is to be multi-DC, multi-vendor. And if you're multi-vendor, you'd be crazy to use vendor-specific services, because even when they're intended to do the same thing, they're never going to behave the same across vendors.
So then you're just using basic units of compute and storage... and at that point, AWS makes zero sense, cost-wise.
How is this up to Apple?
That aside, I'd be surprised if Apple doesn't tout this to developers at some point before or at WWDC 2021.