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.
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'm interested in using Azure Functions for a piece of serverless code, but I would like to ensure that I am always within the free tier, so as to not incur any expenses (I'm okay with potential downtime, not really critical). How do I achieve this?
My function is limited to some domains I control, and possibly a resource used in GitHub readme (like a tracking pixel). How do I combat potential DDOS, and massive bill spikes?
I've seen other questions on how to manage fanout, scale etc, but none on setting hard limits. I'm still a student, so I'd rather stay exclusively in the free tier.
Note, by 'Free tier', I mean the 'Always Free' offering.
You cannont (as far as I know) set a hard limit.
What you can do is to reduce your functions ability to scale. So that it can just process a single request at a time, then depending on how long the request takes you will stay within the free tier.
https://nullable.online/2018/11/20/how-to-throttle-a-azure-function-hosted-on-a-consumption-plan/
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 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!
Starting out with Windows Azure, but how do I know which is better to handle web-traffic and a background processor. Would 2x extra small instances be better or a single small instance.
If I were to use a small instance, I would make the background processor in the web-role, what are the cons of doing it this way?
In future this would also apply where multiple small instances or fewer big instances.
Is there some sort of tool to help decide which way I'll be able to get the best bang for my buck etc.?
I know that for the Microsoft's SLA to be met 2x instances need to be running.
It is better to have 2 extra-small rather that 1 small instance as far service availability is concerned. That being said there are multiple gotchas:
You need to put your 2 VMs into 2 distinct upgrade domains (done in role definition file).
Your app needs to support multi-VM, aka not rely on non-shared session state.
Better availability does not mean better performance, in particular, local cache is basically halved.
Size of cache and overall difficulties at spreading an app over many small VMs typically explain why most dev stick to a single but larger VM until they reach a point that really calls for scaling out (which is likely to never happen for most apps anyway).
For SLA purposes, you need at least two instances, as Joannes alluded to when talking about service availability. Other things to consider:
It's easy to handle background tasks in a web role - you get the same OnStart() and Run() as a worker role.
When scaling, remember that, if you combine functionality into a single role, it all scales together as a single unit. So, if your background processing is being starved out due to excessive web traffic, you'll want to consider splitting them into separate roles
Extra Small instances have shared CPU. More importantly, they're going to have less network throughput. A Small instance has approx. 100Mbps. An Extra Small instance is a fraction of that (I'll need to look up the number). And... memory is 768MB vs. 1.75GB for a Small.
If you have an MSDN subscription, the included Windows Azure subscription comes with 1,500 CPU-hours monthly. But... that excludes Extra Small instances. You'll pay for those. Be sure to use Small when using your MSDN-supplied account. Edit: MSDN allowances are now friendly to extra-small instances.
I guess we can't really know without usage figures and more info and even then I think only time will tell but...
Why not sign up for one of the free trial accounts that gives you an extra small instance. See if your app copes well enough then when it goes live get a second one for load balancing, SLA etc.
If it doesn't cope then get a bigger one - but I'd still be inclined to go for a second one - unless you don't care if it becomes unavailable at random times. MS will apply security patches and will reboot your instances without asking so the second instance will prevent your site being unavailable as they'll update them separately.
It doesn't look particularly challenging to upgrade to bigger instances anyway should it become a sell-out.
If you've got an MSDN subscription (premium level, I think) then you get enough free hours to run 2 small instances.
From what little I've seen I don't think there's any real 'con' in adding the background processor. After all you're paying for a whole machine so you might as well make it work for it's money. That was kind of the impression they gave at the recent tech days thingy I saw.
Try it and see...