Apple Macs in a cloud environment are nothing new. MacStadium have been doing it for years now, and they have offerings as cheap as $59 per month. So why is it such big news when AWS announce that you can now run a Mac Mini in the AWS cloud? Let’s find out about Apple Macs in AWS – CI/CD or bust.
What it costs
The closest region to us which has the new Mac1.metal instances available is Ireland, at a cost of $1.207 per hour. The magic number to get to a monthly cost is 730 hours in an average month, meaning that running a Mac Mini in AWS’s cloud for 2 month will cost you $881. And that’s before you’ve factored in any storage!
Of course you can utilise reserved instances and a couple of other tricks to make life a little cheaper.
What you get
AWS have racked and stacked thousands of 12 core, Intel Core i7, 32GB memory Mac Minis in their datacentres. That’s fairly close to the maximum you can stuff inside the tiny aluminium desktop computer.
We mentioned earlier that there is no storage included in the hourly price quoted on the AWS pricing pages. The reason for that bring us on to the real story here; the integration of Apple developer hardware with the AWS cloud.
AWS Nitro
We need to take a step back from the headlines to really appreciate what’s going on here. We’re all familiar with the basics of what the cloud is now, aren’t we? Lots of servers in a shared datacentre, and because very few clients ever need a full physical server to themselves, we chop them up into virtual servers. That makes things much cheaper for the cloud provider, and they pass the savings on to us. Win win, right?
Well yes, but AWS take that one step further. The software used to chop up physical servers into virtual ones is known as a hypervisor. When a virtual server wants to talk on the physical network card, or execute some instruction on the processor, everything goes through the hypervisor. If you can make the hypervisor more efficient, you can fit more virtual servers on the same physical server, and make more money basically. To this end, AWS developed the Nitro hypervisor system.
We call it a hypervisor system because it isn’t just software – it’s hardware too. AWS have their own server hardware cards built and installed in every server in every AWS datacentre. They provide super fast networking, storage, robust encryption, and consistency across the whole AWS product. Nitro is the thing that means running a server on that side of the world will perform exactly the same as running it here. And the Mac Minis in AWS’s datacentre are no exception – they get all the power of Nitro!
Metal Instances
When we’re talking about the Mac Minis at AWS, we talk about the mac1.metal instance type. An Instance is what AWS call their Elastic Compute Cloud servers. And Metal is a designation used to signify that the instance is running on the bare metal. No hypervisor. So no software in between the power of the hardware and your experience of using it remotely. And yet, we still get all the other benefits of Nitro. Up to 25Gbps network bandwidth. Up to 16TiB solid state storage volumes with up to 256,000 IOPs. Snapshots whenever you want. Software defined networks and security groups applied to hundreds of instances at a time. Integration with other AWS services, like S3 for almost unlimited object storage and RDS for relational databases. All of this made possible, and reliable, using the Nitro system.
That all sounds great, but we haven’t got to the value of the system yet. Up no now, we just have a fast, integrated Mac, but it’s still jolly expensive. It is only when we dive into the new possibilities that integration can bring, that we uncover the value proposition of running an Apple Mac in the AWS Cloud.
Apple Software Development
Unless you’re in the Apple software development community, you can be forgiven for not being aware of how it works. In order to submit an app, or any update of that app, to the Apple App Store, you need to follow a process run on proper Apple hardware. And that might be fine in a small organisation where you have 1 Apple developer, or even a small team, but what about when you’re the size of Spotify or Netflix? To get the next release of your app to the millions of users waiting for it, you need somebody to be at their Mac, with the right credentials and keys to sign it, and send it up to the App Store. And in the world if Continual Integration / Continual Deployment (CI/CD) code pipelines, that’s just not acceptable.
Continual Integration and Continual Delivery – CI/CD
CI/CD is the modern antidote to monolithic, difficult to manage software packages of the past. Remember a while ago when you looked at your smartphone in the morning and it told you it’d magically updated over night? That’s CI/CD at work.
To make CI/CD a real success, you need your team to be able to commit into different code branches (think of it like a folder for this purpose), and for that code branch to be tested, approved, and deployed to a given environment automatically.
So your developers have a dev environment where they can do as they please. Their branch might have a check in there to make sure the app actually compiles without errors, and that some basic functionality works, otherwise it should fail the build, and roll back to the last working version.
The next environment is often Testing. This should be a stable environment where software testers can functionally test that a certain aspect of the app does what it should. If they sign off on that feature, it makes it to the next step.
Integration/Staging is next. This environment mixes together all the things which will be in the next release. Lots of automated tests are run here to make sure that the new features and bug fixes don’t collide with each other and cause problems. You might also have some human testers performing regression tests here, which means they test the whole app – or as much as is practical.
When all that has been done, and everyone is happy with what is in the Staging environment, there will be a few development managers who have the power to merge that code into Production. Production means the app that you and me can download from the app store onto our actual real devices. If there are bugs in it, boy do users let developers know quickly, so this is never taken lightly!
Pipelines
All of the above steps should be automated as much as possible. One stage cannot go ahead without the previous one being signed off. And automation ensures that things are done in a consistent way every single time. Take the humans out of a process, and your variables suddenly go away!
Mix this together with what we learned earlier about Apple apps having to be built and released using proper Mac hardware, and now you can see why running Apple Macs in AWS is a big deal.
As a big software company, you can define exactly how your Mac build environments look and behave. You know exactly how they will perform, and be sure they will perform ever single time. And what’s more, they can fit into the automated build process.
So now we don’t need to talk about how many hundreds of dollars the Mac1.metal instance costs to run 24×7 for a month, because we just don’t need to run it all the time. When code is saved, we kick off our CI/CD pipeline, which deploys an on-demand Mac for 10 minutes. In that 10 minutes, we build and release the app to our developers, or testers or to the general public, and then we destroy the instance and stop paying for it.
For example;
Let’s say you release 2 builds into each of your 4 environments every week. Let’s also say it takes 10 minutes to start a Mac1.metal instance, build your app and release it. So you’re going to pay for 320 minutes per month. Now let’s double that. And if you don’t know why we’re doubling our estimate – congratulations, you haven’t been jaded by the world of software development yet! So $1.207 *10.7 hours, comes to about $13. Let’s add some on to account for storage and bandwidth, and we can round that up to $20 let’s say.
So $240 per year, for a fully managed, secure, redundant, always accessible, company wide Apple Mac development resource. One which can be managed with the same security policies and Infrastructure as Code you use for the rest of your AWS environment. Come on, that’s cheap as chips.
The alternative
Of course you can use software to run build processes on your own Mac Minis in your own datacentre. Heck, you could run a few Mac Minis in the cupboard and they’d be fine. But somebody would need to keep them patched, and firewalled, and secure, and on and on the list of jobs goes. You’re probably going to want to retire the hardware after 5 years too.
What you’re paying for by running your developer Macs in AWS is the integration and the reliability of their cloud, powered by Nitro. And that’s why I think they’re the best bargain 2020 has seen by a long way!
