Disappointing New Mobile Services Pricing
Several days ago Microsoft announced new pricing model (and new prices) for Mobile Services. When adding a Standard tier is something appreciated (as previously there was no low cost non-free option for example for more extensive testing), the Premium tier is now much more pricey in many cases. Why?
Old pricing was similar to the pricing of the Web Sites offering and you were able to run 2 Reserved instances and on them for example 5 Mobile Services paying for 2 VMs. With new pricing it is not possible. It looks that new pricing is a copy-paste of the competition like Parse. Yes, many of the Backend as a Service are priced by API calls, but in the past it looked that Windows Azure Mobile Services will be different.
Let’s look once more at the Mobile Services Premium pricing. I deliberately won’t be talking about Standard, because it is too small if you think that your apps will be anything popular (it is only 50k requests per day).
Premium costs $199 for one unit. In this you get 500k API calls per day and up to 500GB of transfer out (in is always free). But that is not all, you have to pay for the DB which is at last another $5 minimum, but likely $10-20 per month.
500k API calls is:
- about 6 requests per seconds if we assume constant load,
- about 10k users handled if you assume each will make 50 API calls
500GB means each API call should have ~30kB of data which is ~$60 if you would like to pay for it separately.
It looks that if app is not communication heavy (for example you just want to add leaderboard or some other small stuff) it looks you will likely handle all the traffic for even many thousand active users per day. If you app is chatty and for some reasons have to be, for example each user will make 500 API calls each day, you will be able to handle only 1 000 of users, so not much even for moderately popular app.
I’ve mentioned those 6 req/s, as Mobile Services are based on node.js which can easily handle >120 req/s on small instance if there is complicated logic in server scripts. Let’s assume we want to have some buffer for spikes and only make 60 req/s constant load.
Now let assume we use Web Sites to recreate the things we use in Mobile Service (of course it is much more work), but then we will be able to handle 5x time more users for half of the price. Small Web Site costs $75 per month + assume 50GB transfer (so average response of 3kB which is ok, as most of them will likely be 1 kB or less) so about $6 + the DB cost. Or maybe I’ll put it differently: for $199 on Web Sites you can have 2 Small Instances and 250GB transfer out and 5GB DB which allows for about 10x more traffic (about 5 million API calls a day) with good buffer for spikes.
It looks that after the change, if you are just starting or still prototyping Mobile Services are fine, as you can do your app quickly without worrying about the backed. But if your app starts to be popular and goes above 1000k API calls per day constantly you may start to think about rewriting the backed part to lower the costs.
What I explained above is not related only to Mobile Services from Windows Azure, but to all MBaaS systems in general. they will be always more pricey than do it yourself approach. MBaaS is very handy at the beginning, but if you are bigger it may eat all your profits from the app! When Mobile Services were announced I though that Microsoft will break the trend and make the MBaaS a good option even if you have bigger traffic. This week announcement makes it hard to justify Mobile Services usage costs when having big traffic.