AWS spins up more cloudy Mac Minis, now with M2 Pro silicon Amazon Web Services has flipped the switch on a virtual Mac offering in its Elastic Computing Cloud (EC2), now renting Mac Minis powered by Apple's M2 Pro system-on-chip. The EC2 M2 Pro Mac instance type serves up a 2022 Mac Mini with a dozen CPU cores, 19 GPU cores, and 32 GiB of memory. Such a machine, bought direct from …
Yeah, but only if you use it everyday. Some people just want to compile an App a few times a year and be done...from that perspective, $30ish seems pretty cheap.
There is quite a large cohort of developers out there forced to compile a variant of an App (using say, Ionic or Cordova) for the App Store that don't want to buy a Mac because it wouldn't be used for anything else.
The problem here is Apple and their insistence that apps for iOS etc should only be compiled on a Mac. Which is in my list of "Top 10 Dumb things I've heard as a Developer" list.
If it was possible to avoid vendor lock in and compile iOS apps on anything other than MacOS without hacky workarounds, pirated VMs etc, this service wouldn't even be a thing.
Nobody ever "just wants to compile a few times a year". Absolute minimum to release an iOS app that actually does something is of the order of several weeks of rebuilds and "test flights". It takes several hours to get a Mac configured to build once, what with all the keys that need installing - most of which can't be done automatically as it deliberately requires a human in the loop.
And of course, to remote desktop into that cloud Mac you effectively need a Mac of your own anyway. The Windows/Linux VNC is so incredibly slow as to be almost unusable, and you can't do everything over SSH.
As to why Apple insist you need a Mac to compile for iOS - it's the only reason for Macs to still exist.
If and when Apple permits building iOS apps under any other operating system, they're signalling the end of the Mac as we know it.
I know where you are coming from, and I agree with a lot of what you say...but it depends on the type of app you're building and the kind of budget it requires. I feel like I have to point out the obligatory "most businesses are not huge budget Silicon Valley corporations" argument. That world is such a small bubble in the grand scheme of things. They don't set the industry standards, because they are not a large part of the industry in terms of what happens day to day in your average business...if anything, the practices of these massive businesses is weirdly, extremely boutique..
Most businesses are your local fish and chip shop, indian takeaways, independent shops, retailers, accountants, estate agents...you know...small businesses, where there entire business isn't an app. They don't have years of time and millions of dollars of budget to get an app developed, they aren't going to be visiting funding events to raise another round of capital investment etc...they just want to make it easier for Dave and his missus to get information in a convenient manner from an icon on their phone.
Down at ground level, here on Earth, most apps are built using cross platform technology like HTML and JS, because most businesses, like restaurants, independent retailers etc etc just want to get a front end published for their store front that is more convenient than visiting a website, most apps are not the next Facebook / Twitter / Amazon etc, they need to be developed relatively quickly and to a budget...and thus using HTML/JS you can go through the bulk of testing and development without ever being compiled for a specific platform each time. Low level hardware access, device specific API calls etc etc just don't happen here and building a "native" app is unnecessary and if you are properly following standards, it shouldn't be necessary to waste their time testing the same code across tons of devices all the time. It should only be necessary a few times at most. The other aspect to consider is that HTML and JS are standardised languages. If I build an app using those with Ionic and test it on Android and it works just fine, I can be at least 99% certain that i'll also run on iOS just fine not only because of the standardised languages, but also because I can test the app in Safari on any iOS device, because Safari uses exactly the same Javascript engine as the iOS webview...so I can break out my cheap ass, entry level iPad and test the app on that.
As for your other points...
"It takes several hours to get a Mac configured to build once, what with all the keys that need installing - most of which can't be done automatically as it deliberately requires a human in the loop"
Agreed, but you only have to do it once, if you know how to snapshot everything.
"And of course, to remote desktop into that cloud Mac you effectively need a Mac of your own anyway. The Windows/Linux VNC is so incredibly slow as to be almost unusable, and you can't do everything over SSH".
Kind of, but for the sort of app dev that I do, I can pretty much do everything I need from the CLI...because typically all I need to do install XCode (which can be installed from the command line), then Cordova, Ionic...whatever toolset I require...all of which (that I've used so far) can be installed from the command line...and once everything is there...I just need to run a command to build the app after I've dropped the project on the box. I generally only need to use a remote desktop if something has gone horribly wrong or I need to install a MacOS update or something...VNC is fine for that. I never actively work on the remote mac...Mac Remote Desktop, even if you use the native tools is, was and always will be shit.
"As to why Apple insist you need a Mac to compile for iOS - it's the only reason for Macs to still exist."
Agreed.
"If and when Apple permits building iOS apps under any other operating system, they're signalling the end of the Mac as we know it."
Not so sure, at some point in the future, they may have to do this to keep the Mac relevant and to open up the ecosystem to new audiences...if they did this, a Mac would become *more* appealling to me because I would feel a lot less confined.
Opening up .NET and allowing Windows executables to be compiled on Linux didn't hurt Microsoft. Allowing Apple apps to be compiled on Linux (or even BSD, which makes sense) won't hurt Apple either.
I think Apple has "proprietaried" itself into a corner...I don't think it could open things up even if it wanted to at this stage...it's ecosystem has become so proprietary that even Apple itself can't escape it.
Yeah but it’s not like they aren’t clear about it. It’s pretty widely known that EBS is shit for IOPS unless you scale the capacity. 3 IOPS per GB no? With 1500 IOPS burstable on top unless you choose GP3 storage. A GB used to be something like 0.002c an hour…costs peanuts to scale but the performance scales relatively well…you can often get a lore more of a lift out of EBS
Lots of performance issues with EBS come down to not understanding how EBS works and the “bike shed” effect you get with AWS. I.e. people scaling back the bits they understand without concentrating on scaling up the bits they need….and the “dev effect”…slow? Ah must need more RAM and CPU!
Understanding EBS performance and cost for your workloads is 2+ hour read just to get started. Then you figure out that snapshots have an immutable EBS type that's not suitable for some uses. OK, so now you have an EBS AMI that's just for booting and it's too small for gp2 so you make it gp3 then buy more IOPS when it's mounted. Now you can add on gp2, gp3, or io2 storage on demand...if the instance supports it. Small gp2 is too slow, big gp3 is slow or expensive, and mind the block size and instance type for io2... Just put that all in a internal documentation on how to fire up a new instance. So it theoretically should be fast now but new instances are all iowait for half the day. Haha, your AMI's snapshot is arriving by dialup modem after the little burst allocation ran out because you didn't buy "Fast Snapshot Restore" for each sub region.
And as always, don't leave anything accidentally running. Turn off "Fast Snapshot Restore" from previous AMIs. Write down the snapshot ID before deleting old AMIs so you can delete the leaked snapshot manually. Oh, delete the CloudWatch logs too because log lines expire, not log streams. Actually, better have somebody manually garbage collect all the stuff that leaks. Just a few more internal documentation pages. Surely everyone reads it.
The alternative to reading the docs in their entirety is proper testing and benchmarking, why take Amazon's word for it?
For example, a client of mine was spending untold amounts of money on a setup that involved a bunch of EC2 instances, an RDS setup, load balancers etc etc...their practice was to "plan ahead" of the weekend (the traffic is predictable as the platform is a game that relies on scheduled events)...they based all their decisions off how one particular RDS tier performed...m5.2xlarge and they assumed the scaling was proportional...e.g. a 12x is 6 times faster than a 2x...this worked fine, in terms of site stability, most of the time but it was expensive and every few weeks the site would just error 500 at random despite the load on the site barely touching the RDS resources...
The infrastructure was designed by the same people that developed the site...so usual developer rules applied...just throw more RAM/CPU at it...I was brought in, as an infrastructure guy, to take a look at the setup and optimise it.
First thing I did was benchmark each of the AWS tiers for RDS using their own site, I essentially built a script that would emulate people using the site, making changes etc etc...and produced some numbers and graphs.
What I found out is that the scaling isn't as linear as you might think...for most cases, where this business is concerned, 8x is optimal, going beyond that produces diminishing returns.
I also looked at the EC2 instances and did some similar tests on various configurations, including messing around with the storage.
What I discovered is that a relatively cheap tweak to the EC2 instances had a massive impact on performance overall and scaling the RDS up to 12x was no longer necessary...for the most part the site runs fine at 4x, 8x on a busy weekend.
The knock on effect is that I managed to save these guys around $50k-$100k a year on their setup. Not by reading the docs, but by doing some actual testing. It took me less than 6 hours to test everything.
Reading the docs is not always the most objective approach to optimising AWS...the docs for AWS are like a menu, they tell you whats on offer, but they don't tell you what tastes good...that's up to you.
Finally, no matter what cloud platform you use, don't let your devs build the infrastructure...get a proper infrastructure architect / engineer. Just because someone knows how to design a bathroom, doesn't mean they know anything about plumbing, customer expectations etc etc.
Your developers might be amazing and build some seriously good solutions, but you need to tie it all together with some proper engineering with an architecture guy. Your developers are the cooks in the kitchen, you running your business are front of house dealing with customers, providing services etc etc...your architecture guy is your "Gordon Ramsay", the chef in the middle making sure that what happens in the kitchen makes the front of house look good.
Devs come in all shapes and sizes, like cooks...some are good at making sauces, some are good at preparing fish etc etc...but architecture guys *understand* what the devs do, they see the bigger picture, and know how to turn all the random shit going on in the kitchen into a cohesive experience so instead of serving plates of random shit, you start getting well crafted dishes. The devs still do what devs do, but before anything appears on the line to be served, it goes through the architect to ensure quality to ensure that what you take to your customers isn't shit.
Get a good infrastructure guy and you can probably half the number of devs you need and one solid infrastructure guy will cost you far less than half your devs...they're pricey, sure, but you don't need loads of them...you just need one...and they will save you $$$ in running costs...your architecture guy in the medium to long term should essentially cost you nothing because the money he saves should more than pay for him.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
