Continuing from last week’s WWDC post, a look at Apple’s new machine learning offerings, as well as some changes in Terraform and Azure’s new Container Service Engine project.
Apple’s Machine Learning
Let’s start with the obvious, Apple isn’t as well known for its machine learning capabilities as a company like Google. This doesn’t mean that they don’t use it, or aren’t good at it, but it’s not exactly their strength. Siri is their most well-known machine learning product, but they use it in other products such as Photos and some of the predictive features of the iPhone. Unlike Google or Amazon though, it isn’t a product they offer.
At least until 2 weeks ago at WWDC. Last week I went through some of the other announcements that are impressive in their own regard, but I decided to shine a slightly bigger light on these ML efforts. In part because it’s a very different approach from other parties, but also because it’s always a fascinating subject in its own right.
One of the things announced is the Vision Framework. This is an image1 recognition SDK not unlike AWS Rekognition or Google Vision API except that it runs locally on the user’s hardware so your app doesn’t need to contact a server and can easily be implemented with just a few calls. Will it be as powerful in all ways as the other two2? Maybe not, but running on the local device has a lot of advantages. Especially if you’re trying to run it on the 10 minutes of 4K video you just shot.
Two other frameworks they announced are Foundation, for natural language processing3, and Gameplaykit, for evaluating learned decision trees. Again, there are advantages to both of these running globally instead of in the cloud, but the most interesting part is likely to be the underlying framework Core ML.
Core ML is aimed at allowing you to provide your own trained models to run locally on someone’s phone or tablet. Of course, running it locally will limit any additional advancements you can make to it there but should increase the response time4. And of course, it’s designed to be easy to implement. At least, easy for machine learning models.
Obviously it’s not all perfect. Core ML requires the models in its own format and while Apple provides a number of conversions, I don’t know how many of the existing ones that captures. There are also limits to what you can do with it5 and in the end you’re still running the end result on a mobile device with its own memory and CPU limitations. Of course, those limitations are getting smaller as they are starting to reach desktop class power. And Apple isn’t shying away from building purpose specific processors either. It wouldn’t be much of a stretch to see them including hardware optimized to run these models in future devices.
So should everyone start using this? Of course not. Other than the above I’m sure there are plenty of other limitations I haven’t even considered. And it’s very obviously not a solution that works across platforms, limiting its use for many developers. But for developers who stay within the Apple ecosystem it’s another way to add features easily, and lock themselves deeper in.
I don’t think I’ve mentioned Terraform here before. That’s not because I don’t think it’s a good product, it’s just that I haven’t really used it much. In case you’re not familiar with it, Terraform can be seen as a cross-cloud6 orchestration tool. Sort of like CloudFormation is for AWS but for every provider in one solution.
Generally speaking most attempts to be everything for everyone don’t have an optimal result. There are often trade offs, whether by limiting the tool to the lowest common denominator or by limiting how cross-platform it actually is. In the case of Terraform, they’ve chosen the second solution7 and now they’ll be going even further in that by splitting off the provider plugins into their own repositories. If you’re already using Terraform this is a big change, but should hopefully make it easier to keep up to date with the latest features coming from the providers. For me, it also reminded me that I should check out Terraform again although after this transition is finalized.
The Azure Container Service Engine is a new open source tool aimed at easily building Docker clusters in Azure. It supports a number of orchestration tools, including a Docker Swarm, Kubernetes, and DC/OS. It works by creating the required ARM needed to set this up.
It’s clear here that the main goal is to make it more attractive to run these clusters on Azure, but it can also be used as a general research tool for your own purposes. Nothing would stop you from setting up a new account and use the free tier to quickly create a couple of clusters using the tool to see which one works best for you, or even just to find a way to quickly get started with one. It might not be easily transferable, if you decide not to use Azure, but I suspects the learnings you can take from it are valuable in their own right.
I like that these simpler ways of dealing with complex issues are starting to crop up. First Kubernetes Draft, and now this. These are the sort of things that show the tooling in the container space is maturing. It’s not fully there yet as too many things still require a lot of work, but every step is getting us closer to make it a boring but stable solution.
- Vision also supports video, as in the ability to recognize things in videos. [return]
- Or any other server driven solutions. [return]
- No, I don’t think that name makes any sense either. [return]
- And I don’t think there’s anything preventing you from sending some (anonymized) data back for training either. [return]
- As always with Apple. [return]
- Technically speaking it’s not limited to cloud providers, but that’s the only thing I’ve ever used it for. [return]
- A good choice in my opinion. [return]