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.
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 created my Free Azure subscription and have been hosting a couple of Apps out there since around April of this year (2020).
All of my resources; Subscription, Resource Group, AppService, and Apps are F1 service rather than S1 to ensure they are running free and my cost forecast for the month should always say $0.0. This was something confusing in the beginning that I had to reach out to Microsoft to help me with in setting up my hierocracy of resources.
In my main web app I now need to deploy an SQL Database. I've been developing using LocalDB in my ASP.Net Core 3.1 app.
Now the Free Azure description here:
https://azure.microsoft.com/en-us/free/
gives these specs for SQL Server with your free subscription for the first year:
250GBs. Now I'm thinking 250GB of storage, not memory. But when you start selecting your DB configuration they are talking memory. So now I'm confused with that. Do you get 250GB of Storage or memory with free SQL Server with free Azure subscription.
Also, the free service really just says free SQL Database. Not free SQL Server. So I am confused here as well. Do you just get one Database? I know you have to set up an SQL Server in order to set up the Database.
Next I found a quick tutorial on creating an SQL Server Database her:
https://learn.microsoft.com/en-us/azure/azure-sql/database/single-database-create-quickstart?tabs=azure-portal
I want to go through the three versions of this tutorial:
Using:
Portal
Azure CLI
PowerShell
so I can get a feel for the environment and find the way that best suites me.
I am going through the Portal tutorial first.
On step 9, the default is General Purpose, Serverless.
This says "up to 40 vCores, up to 120 GB memory".
But you are supposed to have 250GBs with the free subscription.
So this is not it.
I click provisioned and now it says "up to 80 vCores, up to 408 GB memory".
Well 408GB is too much; over 250GB.
So I click, "Looking for Basic, Standard, or Premium?"
And from there click Standard because it is the 250GB configuration I think I am looking for to get the free SQL Database with the free Azure Subscription. (Again do I just get one database?)
But now instead of talking vCores, the cost is per DTU. What the hec is a DTU? I tried to read up on it. Seems like a unit of performance rather than a transaction. So standard is estimated at 10 DTUs a month I believe. Hopefully that does not mean 10 transactions per month but rather again a measure of performance.
Estimated Cost $15 dollars a month.
That "Standard S0" above scares me I think that would start charging me.
It should say F1 shouldn't it.
I've come accross some similar questions to this online. A lot of people seem to have the same confusion and question I have. Main question is how do I get an F1 level database for my app. And is one database all I get. That would suck. Not really a free subscription then since most web apps in ASP.Net/Core which is Microsoft are dynamic and need a DB and Azure is Microsoft right?
Or should I just go ahead and review and create. And S0 is just how they do it for free Azure subscription? Like you wouldn't get charged for S0? But I don't think so.
Trying to get a concrete answer somewhere so I know how to proceed.
UPDATE 10/20/20
I have just gone in a different way and am creating an SQL Server instead of Sql Database.
This appears to be free and cost estimate per month says:
"No extra charges"
Ok everybody.
Let's consider this a tentative answer until it all proves out to be true.
I opened up a support ticket with Azure/Microsoft.
Here is part(s) of the response I got:
First, I would like to thank you very much for providing me with such a detailed service request. After my investigation, I was able to determine that the estimated price does not show the discount with the free services. Therefore, using the S0 database in Azure SQL Database at the Basic service tier will be included in the free services. The free service limitation states that you can use up to 250 GB. So, anything deployed below 250 GB is ok to use if it is correctly configuring all around. As long as you stay within the limits, you're will not be charged.
My reply here:
So thank you for the information on S0 being considered free as part of the F1 subscription.
(Although, I really wish they would include next to S0 on the pricing sheet to use as part of F1 in parenthesis or something)
Does it matter if you use vCores or DTUs?
And if you use DTUs does it matter if you go above the max?
Or as you said I guess as long as I stay under 250GB I'm ok.
Her response continued:
Lastly, I would like to leave you with a link on how to avoid charges on your free service account: https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/avoid-charges-free-account.
I hope this information was beneficial to you, Sam. Please let me know if you have any additional questions.
Everybody notice the link to track your free services which enables us to make sure we do not use a service outside of the free services or exceed the amount of what we get with a free service. I think this is a gold mine find of a URL.
And one more question I sent her:
Can I create a 250GB application for each app I deploy out there.
Or do I only get one and have to make all my apps share it?
At least we know that Basic S0 is free now.
I will update this answer with better information as I work through the details.
This is the best answer.
I have worked out a procedure that works for me.
And I understand a lot of things better now.
It seems like the whole answer is not in one place since Azure is so vast and everyone's
scenario is different.
So I wrote up an article to document what worked for me.
I hope this helps someone out there:
https://ctas.azurewebsites.net/TechCorner/AspNetCore3/HowTos/DeployWebAppWithLocalDbToAzure
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!
How many instances do I need to configure to ensure that my site stays available during planned maintenance performed on the underlying OS/VM.
I understand the availability model for web roles, but I am not clear if it is the same for web sites on Azure.
With web roles, you have to configure at least 2 instances in separate upgrade domains to get the SLA from Microsoft and to ensure that your site is routinely available. This ensures that your site will stay available as Microsoft performs maintenance on the underlying OS (updating to a newer version of the OS image, etc).
What's the equivalent story for web sites? Do I need to have two instances of my web site or does Microsoft proactively move my site to a new VM before they perform maintenance (since web sites are more "managed" than web roles, that seems like it may be possible that they do this)?
Does the answer change between Free, Shared, and Reserved web sites?
Note, I understand that during sudden, unplanned downtime, having a single instance means my site will be unavailable until it is restarted on a new node. I am not worried about that for my low-volume hobby site. What I am more interested in is the routine, planned maintenance activities that are much more common than unplanned failures of the VM or host hardware.
Edit for clarification: Clearly, having 2 (or more) reserved instances is going to be the best option for high availability, but that is cost prohibitive for a hobby site at just short of $120 per month. My question really is if a single Shared or Reserved instance is going to have routine downtime for planned maintenance. I'm specifically wondering if anyone has concrete information on this (from a blog post I may have missed or from a phone call with the Microsoft support guys, etc). Maybe the answer is "no one knows because Microsoft hasn't clarified how things will work outside of the preview yet".
I also don't want to get hung up on the term "High Availability". I guess I am just looking for "Not Low Availability". It's just a hobby site, after all.
Please note that Azure Web Sites are still in preview. That means that there is no SLA what so ever. When the Web Sites come out of preview, I would suggest having at least 2 reserved instances for high-availability.
Both Free and Shared instance imply usage quotas - CPU/Memory/Bandwitdth (Shared has no quota on the bandwidth, but still apply quota on CPU and Memory).
Having usage quotas in place is controversial to High Availability in my understanding for that term. That's why I suggest Reserved. It is same for the number of instances.
There is no SLA since Web Sites are still in preview, but I also wondered about downtime during updates and found an explanation on twitter from a member of the Azure team:
https://twitter.com/nirmsk/status/342087643779198977
Apparently they keep a "buffer" of machines that are used if the current machine needs to be rebooted, crashes, or you change the scaling options (between Shared and Reserved).
Having multiple instances won't solve the problem since any change you make on one instance is automatically propagated to all other instances.
However Azure websites now supports having a staging version of your website and swapping between staging and production versions of the site. That would be ideal for your scenario. See here for more info: http://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Hopefully my question is in the right forum here. I've just checked out the pricing model of windows azure and checked out the different configuration options:
http://www.windowsazure.com/de-de/pricing/calculator/
I have been working as a developer for almost two years now and worked a lot with IIS and the WPF technology. As a little private project I checked out HTML 5 and JS with MVC4 Web API and wondered what azure configuration I'd need to host a MVC 4 Web API project. Would it be rather a virtual machine or a full calculator? What benefits grants one over another?
I am going to start my studies soon, so I'd like the cheapest I can possibly get. I won't use it a lot (mainly for testing reasons), as well I think there won't be too much traffic either. Would a virtual machine also include the possibility of using IIS?
Could I also run a MVC project with something else than VM/full calculator?
And what would happen if for some reason my traffic just explodes? Would my services just be shut down until I increase the power of my machine? Or would I just get a huge bill and be surprised quite a lot?
Use websites.
You can start with 10 Web Sites absolutely free! So this is the cheapest. And it certainly supports MVC4 Web API.
For starter you can get a 3 month trial with enough credits to start. By default you'll have a spending limit on your account. This mean if you start to get too much traffic your services will shut down and you won't have to pay any extra. I think you can configure how much you are willing to pay but I never tried, it is still the default which is 0$.
You should start with Shared Web Sites and move to reserved instance, VM or web role later if you ever need to scale up or out.