Currently I work on the application for fetching and downloading data from Office 365 services for given organization. I use such public APIs as EWS, SharePoint and Microsoft Graph for getting access to data for given user in organization (like Outlook, Calendar, OneDrive), groups (Team Site content, Planner, Conversations) and SharePoint content. I need to execute a lot of requests at the same time but unfortunately I experience throttling during this. There are some info in the internet related to using service accounts in order to decrease throttling rate but it's not enough such info at the moment.
How can use service accounts to overcome throttling in Office 365?
Are you already using a service account, or do you actually have the credentials for each user whose data you are retrieving? Typically the way to avoid throttling is to get a service account with Impersonation rights to the individual calendars, etc. When querying the mailbox or calendar the service account impersonates the actual user so the connection and communicate charges are counted against the user and not the service account. This way, e.g. a single service account can launch many parallel requests for multiple users without the charges being accumulated against the actual service account and causing throttling.
I've spent an intense amount of time dealing with this problem. Here is what we did:
1) Moved our automated processing to off peak hours (e.g. 6pm - 6am)
2) All calls need to have retry ability. MS says to use the value in the retry-after header, but it always 2 minutes. I'll retry for 20 minutes. If it fails after that time period, I don't try again for another hour.
Using service accounts is absolutely a workaround, albeit a terrible one. At some point, MS will adjust the algorithms again and you will be just as screwed. The real answer is retrying over periods of time.
Related
About 10 days ago I created my first Azure Sql Database. I choose the Basic Plan (4.21 €/month). This database is used only for testing purpose. Today I received an email from Microsoft Azure.
Subject of the mail : Your services were disabled because you reached your spending limit
Body of the mail : Keep building in Azure by adjusting your spending limit. Your services were disabled on May 7, 2020 because you’ve reached the monthly Azure spending limit provided by your Visual Studio subscription benefit. To keep using Azure, either:
1. Wait for your monthly spending limit to reset at the start of next month, or
2. Adjust your monthly limit for a specific month or for the life of your subscription—you only pay for the extra amount you use each month.
Why did Azure changed the Pricing Plan of my database without notifying me ? Can some actions cause this ?
I know that I did an Export Data-tier Application from Microsoft SQL Server Management Studio from which I was connected to my Azure Database (I made a backup from there). I doubt this explains that.
UPDATE
As suggested by NillsF i checked the deployment history and I can confirm I choose the Basic Plan when I created the database (see below). So I still have no clue what's happening to my database.
You can check the activity log on your subscription to see who initiated the switch from Basic to Vcore. It seems strange that MSFT would have done this on your behalf.
You can also check the deployment history on your resource group to verify the tier you picked when you created the resource itself:
I need to host my MSSql DB, Web APi and another Web application on Azure. I'd like to sign up for a free account. I looked into the the FAQs section there but didn't quite understand what can I and can not use after my trial period expires. So, the question is: Am I gonna be able to use my services and DB after my trial period expires?. What is free after the expiration period? As I understand, pretty much nothing.
The fee depends on the tier you choose during the creation of those services. You can check the tier in the portal for each of those resources separately.
After the trial ends, you won't be able to access said resources (well, unless you pay from them, but that's no longer a trial in that case.).
Problem
We deploy a mixed SaaS, PaaS, IaaS solutions on Micorosft Azure. Recently our account was suspended due to a Microsoft credit limit.
1) The account billing and technical contact received no warning of the approaching credit limit. When the account was suspended alerts were raised instantly. In response I simply lifted the credit limit and the account was accessible again.
2) All VMs could then be started again within seconds and thrid party add-ons were operational automatically.
3) Cloud Services were displayed but all the web/worker role instances in each were stopped. On attempting to start it was clear the deployments had been deleted !
Questions
Does any one know or understand why the deployment packages are removed when an Azure account subscription has been disabled ?
VM, storages accounts, add-ons are persist so why delete the cloud service instances / deployment packages ?
Anyway to mitigate this issue ?
Result is 60 min downtime to upload and deploy packages from source control. Examining enterprise accounts and invoicing.
Thank you for any advice.
Scott
Currently, subscriptions which has monthly credits such as MSDN, MPN and Bizspark plus has a feature called spending limit. This feature is enabled by default to prevent any charges on your credit card. When this sending limit is triggered, the subscription is disabled for the remaining billing cycle and will be automatically re-enabled when the credit is reset which is on the start of the new billing cycle.
When the subscription is disabled, Cloud services (web and worker role) deployments are deleted as only the deployment file is uploaded on Azure and the source file would still be available by the developer. However, Virtual machines are created within Azure platform, hence VMs are stopped de-allocated when the subscription is disabled. The web services deployments are dealt with differently i.e they are deleted it’s a legacy of how the platform was built and is scaled.
The Azure portal shows the credit utilized and remaining balance for the subscription and notifying the credit status over email is still not available. However, when the subscription is disabled, a notification is sent to the account owner.
Possible mitigation involves:
moving to standard payment terms , away from pay-as-you-go account.
remove the credit limit
possibly a continuous deployment strategy via Team Foundation Server or the like could automate redeployment (no doubt there are other automation methods too).
Unfortunately if the Azure subscription is suspended service deployments are deleted and must be uploaded again. If you have multiple large deployment packages this could take many hours.
Hope that helps someone.
Additionally, if you have shared websites, they will get suspended. There is no way to resume them until the credit period is reset, so you need to delete and recreate them.
We have our own application that stores contacts in an SQL database. What all is involved in getting up and running in the cloud so that each user of the application can have his own, private list of contacts, which will be synced with both his computer and his phone?
I am trying to get a feeling for what Azure might cost in this regard, but I am finding more abstract talk than I am concrete scenarios.
Let's say there are 1,000 users, and each user has 1,000 contacts that he keeps in his contacts book. No user can see the contacts set up by any other user. Syncing should occur any time the user changes his contact information.
Thanks.
While the Windows Azure Cloud Platform is not intended to compete directly with consumer-oriented services such as Dropbox, it is certainly intended as a platform for building applications that do that. So your particular use case is a good one for Windows Azure: creating a service for keeping contacts in sync, scalable across many users, scalable in the amount of data it holds, and so forth.
Making your solution is multi-tenant friendly (per comment from #BrentDaCodeMonkey) is key to cost-efficiency. Your data needs are for 1K users x 1K contacts/user = 1M contacts. If each contact is approx 1KB then we are talking about approx 1GB of storage.
Checking out the pricing calculator, the at-rest storage cost is $9.99/month for a Windows Azure SQL Database instance for 1GB (then $13.99 if you go up to 2GB, etc. - refer to calculator for add'l projections and current pricing).
Then you have data transmission (Bandwidth) charges. Though since the pricing calculator says "The first 5 GB of outbound data transfers per billing month are also free" you probably won't have any costs with current users, assuming moderate smarts in the sync.
This does not include the costs of your application. What is your application, how does it run, etc? Assuming there is a client-side component, (typically) this component cannot be trusted to have the database connection. This would therefore require a server-side component running that could serve as a gatekeeper for the database. (You also, usually, don't expose the database to all IP addresses - another motivation for channeling data through a server-side component.) This component will also cost money to operate. The costs are also in the pricing calculator - but if you chose to use a Windows Azure Web Site that could be free. An excellent approach might be the nifty ASP.NET Web API stack that has recently been released. Using the Web API, you can implement a nice REST API that your client application can access securely. Windows Azure Web Sites can host Web API endpoints. Check out the "reserved instance" capability too.
I would start out with Windows Azure Web Sites, but as my service grew in complexity/sophistication, check out the Windows Azure Cloud Service (as a more advance approach to building server-side components).
Our company has until bought a lot VS Pro/Premium and Ultimate Licenses, and each includes a free Azure Account.
At the Azure Info day we have been told the best way would be to bundle them into one big account
(there is just too much overhead if every developer here would register that account on his own).
Do you know how to do this ?
Is there a special account manager we should contact ?
Thanks in advance,
Mathias Held
Each MSDN subscription has its own Windows Azure subscription with a given number of resources allocated per month. Those resources cannot be combined. For example, if you have 10 developers with MSDN Ultimate subscriptions, each with 1,500 Compute hours per month, you can NOT combine them into a single account with 15,000 Compute hours.
Regarding too much overhead: The task of enabling Windows Azure resources is incredibly simple. In fact, if you go to the new Windows Azure portal and sign in with the Live ID associated with your MSDN account, the portal will recognize that there's an associated Windows Azure subscription.
If your concern is that an individual dev won't have enough Windows Azure Compute resources monthly, this is more of an educational issue. At 1,500 monthly Compute hours (and Extra Small instances running at 1/3 Compute Hour), you have enough resources to run 2 Small instances 24x7 (or 6 Extra Small). The prudent advice is to delete all deployments when not in use (e.g. after work hours or between test deployments). This will give you much more breathing room and let you run much larger VM sizes without risk of going over allotted resources.