I am trying to understand how Azure Mobile Services scaling work.
Below screenshot was taken from Mobile Services scale tab in Azure portal.I am using BASIC tier.
When setting SCALE-BY METRIC to NONE, we will pay at a "minimum" UNIT COUNT * $14.99.
For example, if i set UNIT COUNT to 6, then I'll pay 6 * $14.99 = $89.94 every month no matter how much API calls are being made, is my understanding correct?
When setting SCALE-BY METRIC to API CALLS, we can set minimum UNIT COUNT and maximum UNIT COUNT, this is suitable if at some days we have few api calls but in other days we have more api calls, is this correct?
Before moving from development to production, how do we anticipate which scaling option to use? Continuously monitor the API count and change the scaling option when we think we will go over the limit?
thanks!
I'm not affiliated with MS or Azure, so these answers are from my personal understanding.
Yes this is my understanding as well. You can also check this behaviour by extrapolating the predicted costs in your bill.
Yes.
I have a few apps running on Windows Azure Mobile Services in the Store. Usually I start out by trying to estimate the typical api calls per session. This can be done quite easily as long as you are in development. This should give you an idea about how many users an instance can support. Example: In one of my simpler apps one instance could serve about 800-1000 daily active users. Now, even with this information I usually set the scaling to the maximum for launch day, just to anticipate anything. In case it scales to the maximum it'll most likely be just for a day - and if it isn't well in that case congrats!
Related
first of all would like to say a big thank you to all who is reading my questions, I really appreciate your time and hope to be able contribute back, second, I did see part of my question already asked in another thread but it does not answer it plus my questions have a bit different angle, so here it goes:
Does not elasticity already include scalability? I see scalability and elasticity go as two separate features of the cloud in service promotions, is there a technical difference or is it just marketing play of terminology?
I have similar confusion about compute and networking, does not compute power already include networking, I saw it being briefly displayed as two separate advantages of cloud service
I will give it a try :) But it will largely be my understanding and less citing of provider documentation.
Elasticity vs. Scalability
I interprete elasticity as the capability to react to more or less daily variation in resource needs. Unlike reserved instances or your own server hardware "in the basement" the cloud provider offer both the resources and the managment tools to let you use varying amounts of compute, network , ... resources from hour to hour or day to day.
So elasticity (in my mind) solves the business need to react / adapt to changing demand that might follow a pattern like day / night or season / off-season but might be relatively stable from year to year or even week to week.
Scalability in my mind is more than everything the ability of these "hyper-scalers" to allow customers / you to grow your system continously and almost with no upper limit. So I would say the average (i.e.) weekly usage can go up every week for months after months and you wouldn't run out of upgrade options with the cloud providers to help you serve more and more requests.
Compute and Networking
The cloud uses "software defined networking" which abstracts all that hardware stuff like switches and routers from you as a user and offers connectivity options that would be hard to realize on your own / with traditional networking. So the networking capabilities of a major cloud provider are a feature set of their own, with lots of room for system improvements and capabilities. Therefor it is designed, serviced, billed... separately from other service classes like compute or storage.
A simple example or illustration of that might be a virtual machine (or multiple) that on their own as stand alone compute resources might have a network interface and a public ip attached to them. You can reach that machine, the machine can reach to internet (if you configure it that way) and you can install stuff on it. That's it - you have compute power.
But when you group virtual machines in i.e. application security groups and use these groups as objects in resources that allow, deny, redirect traffic internally or externally and maybe tunnel traffic to these compute resources to your on-premise resources (like in many cases Active Directory Domain Services) you start to use advanced networking capabilites. But obviously there's much more and networking can be one of the hardest parts of certification exams on cloud topics.
I have 100,000+ addresses that need to be geocoded, but most geocoding services seem to cost money after the first couple thousand entries. Is there any free service that can geocode what I need either in one go or in a relatively short amount of time i.e. a couple weeks at most while being free or relatively cheap?
Also, I may have access to arcgis and I'm wondering if arcgis's geocoding service have a limit if you have the premium version.
The answer is No, there are no free services that will handle 100,000+ entries.
Although it can be argued that one can write a script that will handle geocoding actions in sequence and parallel, i.e. Google's geocoding API with 100 instances running at 2500/day. It is unrealistic and violates their Terms of Service.
To my knowledge, ArcGIS also has a limit as well.
Your best bet is that if this is company or business related, have them foot the bill.
I'm designing an architecture for leveraging Azure Search for multiple tenants. Since each tenant will have a slightly different schema my solution will require 1 index per tenant. This is easy enough to set up and I'm really liking what Microsoft has put together. However now that I am starting to think about on-boarding new tenants, monthly costs and scaling up the service I am starting to hit a few walls and wondering what my "best" option is.
Has anyone encountered this situation that can shed some light onto best practices? Here are the options as I see them now:
Option 1:
Spin up a new BASIC plan for every 5 tenants at a cost of $38/m for every 5 tenants ($7.60 per tenant per month).
Pros: Cheap to start.
Cons: Tenants are crippled by the limited performance and storage capabilities, I'll have to manage X number of services and ClientQueryKeys once I get past 5 indexes/tenants.
Option 2:
Spin up a new STANDARD S1 plan for every 50 tenants at a cost of $250/m for every 50 tenants ($5 per tenant per month).
Pros: Better performance, less services to manage as tenant counts increase
Cons: Much higher costs to start, still need to manage tenant-to-service relation once system has greater than 50 tenants, I'll have to manage X number of services and ClientQueryKeys once I get past 50 indexes/tenants.
Option 3:
Spin up a single STANDARD S2 plan that can be used for ALL tenants (assuming no cap on index count)
Pros: Better performance, no need to manage multiple services/client keys as tenant counts increase
Cons: Much higher costs to start, very little documentation on costs and limitations.
In all scenarios (aside from option 3, I'm assuming?) I would have to manage client keys across multiple services. So obviously having only one service with an infinite index count is ideal. However I am a startup (yes I am using BizSpark already) and the costs for search a very daunting when I may only have 1-5 tenants to start.
I've read that there is no way to easily migrate data between plans (without doing it manually or writing a script) so my first choice is likely to be my last. I would also prefer to only have to manage one service with one plan for all my tenant. Therefore I am leaning to option 3.
If option 3 is the best option:
Can I start on BASIC and scale up to S1 then S2 as needed, or is this not possible?
If BASIC cannot scale to S1 is it at least possible to scale from STANDARD S1 to S2 once I go past 50 tenants or will I need to manually manage this or start at S2?
What are my startup costs and/or costs per index/tenant on Standard S2?
Is my index limit infinite on S2?
If not, what is the index cap?
Are there any other options or caveats that I should consider?
S2 services work much better in multi-tenant scenarios. Not only they can fit more indexes (up to 200), but they also have more overall capacity so assuming exponential distribution of index sizes and loads, you get a better typical experience for your customers.
You're right that the cost of entry is higher.
Regarding the cons of S2, soon we're going to publish proper documentation and other supporting materials for it. In the meanwhile, feel free to contact me directly (Pablo DOT Castro AT the usual Microsoft domain) for more details.
If you think you'll have lots of indexes in the future (many 100s), we're also working on options for better multi-tenant support. We're not ready to announce the details yet but I'm happy to discuss if you get in touch with us.
Answering your specific questions:
1.Can I start on BASIC and scale up to S1 then S2 as needed, or is this not possible?
We don't currently support this. You'd have to create a new search service and migrate the indexes.
2.If BASIC cannot scale to S1 is it at least possible to scale from STANDARD S1 to S2 once I go past 50 tenants or will I need to manually manage this or start at S2?
No, it's not. We want to do this, just have not gotten to it yet.
3.What are my startup costs and/or costs per index/tenant on Standard S2?
Please get in touch with us and we can discuss pricing.
4.Is my index limit infinite on S2?
5.If not, what is the index cap?
No, S2 services are limited to 200 indexes/service.
6.Are there any other options or caveats that I should consider?
You've done a good analysis, I think you're on the right track. One thing you may want to consider is fairness. All indexes in the same service share the capacity you've provisioned for the service. If there's risk of unfair loads you might want to consider per-tenant throttling.
From answers to other questions (such as this question), it sounds like different instance sizes offer different network throughput. My processing is I/O bound, and I'm trying to use web jobs to do it on a web site instance. Do web sites offer the same bandwidth as VMs with the same size/price point? Or if I need bandwidth higher than 100 Mb/sec, would I need to choose a solution other than web sites to do this processing?
Thanks,
David
Unfortunately, the bandwidth limits are not currently exposed.
At the end of the day, Azure App Service is using some Cloud Services machines and the bandwidth should be quite similar than in Web/Worker roles.
However, the requests go through different mechanisms (IIS ARR for example) but it might not add so much overhead.
That being said, the best way would be to try and scale out (using multiple instances) if you need more.
I hope this helps!
Adding to #dmatson answer a small detail - right now, expect SLA for high availability, which means that you can have different numbers sometimes. You will need to wait for the official release of SLA - or scale out by the size or amount. The very good FAQ i have found on that topic is here, many networking-related questions are covered.
https://blogs.msdn.microsoft.com/igorpag/2014/09/28/my-personal-azure-faq-on-azure-networking-slas-bandwidth-latency-performance-slb-dns-dmz-vnet-ipv6-and-much-more/
I've developed a simple system using ASP.NET MVC and WCF for customers to register software and get a license key. I was thinking about using Windows Azure instead of a traditional web hosting because it seems easy to use. I'd only need one SQL database and one small VM, but I'm confused about the billing.
Does the billing only charge as people actually use it, or would I pay the fee for each CPU every hour of everyday for the whole month because that was what was available to users? So for one single cpu VM at $0.12 an hour in a 30 day month I'd pay $86.4? Or would I pay less if no one used it? Then another $9.99 for an up to 1GB database, so for my needs I'd basically pay $96.39 a month?
That seems expensive for basic web hosting, but if it's easier for someone with little hosting experience to set up and maintain as well as making it easy to expand if I suddenly got a lot of traffic then it would certainly be worth it to me.
EDIT: I think I found the answer here: Getting started with Windows Azure
You're correct regarding the $0.12 / hour: you're billed based on resources consumed (meaning virtual machine instances), whether you're running at 0% cpu or 100% cpu.
While it might seem expensive compared to your average shared-hosting provider, consider that you're getting health monitoring, failover, SLA (if you have 2 or more instances) upgrade domains, etc.
I have two blog posts that go deeper into Compute Instance billing that you might find beneficial:
Part 1: The True Cost of Web and Worker Roles
Part 2: Staging and Compute-Hour Metering
I hope this helps...
The rule for billing is quite simple: if you look at the protal, there are the "gray" or "blue" boxes showing for a deployment.
If the box is gray, you are OK. If the box is blue, a bill is due.
This means that charges for every hour will be made whenever the box is blue, that is: once a deployment has been done, whether it's stopped or running.
Now you have a new feature in windows azure called WebSites. Deploying a website which have only a small amount of visits. It is simply 'free'. This is light weight website running in a shared environment.
http://www.windowsazure.com/en-us/pricing/calculator/ -> Check for websites.