I am developing a Xamarin mobile app that requires a central cloud data storage (so a database). I also need an app service to host an API to interface with the database. I have been leaning towards Azure for both of these needs to keep everything in the Microsoft/Azure space and I am also familiar with it, but I am not sure if that would be overkill for my needs.
The data I need to store is only a few hundred records across a couple of tables and does not contain sensitive information. The app service would be quite small. I used their cost calculator with the cheapest options and that came out to only about $7/month for a small database and they have a Free Tier for the app service, although I have read that it is very slow, not sure to what extent though for the simple use case I have for it. This is very reasonable unless I have to upgrade to the Basic Tier App Service which jumps up to $70/month, that becomes a bit more than what I am looking to spend for this.
Wondering if folks know if the Free Tier of the Azure App Service would be impractically slow to host an API. It is listed as using Shared Cores, 1 GB RAM, and 1GB of storage. Also open to suggestions for other options that play well with .NET. Thanks!
I run several web services between AWS and Azure. Depending on how you are planning to write your App Service you can go with Azure VM Standard B1s and they will fall under FREE tier usage. Else around $10 per month.
You can run an embedded DB like SQL Lite with ASP.net. I use Spring Boot and works well.
Related
Background
Our company designs and hosts websites for approx. 500 clients, each client has one website. Each website is built on ASP.net. Our current hosting infrastructure is built on hypervisors with virtual machines running Windows. We have 3 virtual machines all running the same spec (8 cores, 24 GB RAM). The 500 client sites are split over these three web servers, there is no load balancing or fault tolerance – the website exists in only one location.
Therefore, as we accumulate clients each web server’s site count increases. When we max out each server, we bring another one online and start again, then once that one is full we spin another VM up etc.
Goal
We would like to move (eventually) our sites over to Azure, however we do not want to replicate our current set up on Azure, instead we would like to move each website over to Azure Web app instead to take advantage of scaling.
We would also like more fine-grained control over our costs when bringing online additional sites. Currently, we bring online a VM and costs us X (for an empty server), it may take us 3 months to fill this. We would like to steadily add to our hosting hosts, not in big steps.
My question
I have investigated for many days on this and cannot find a tutorial or guide on what the ideal set up looks like on Azure Web apps when hosting 100’s of websites. Almost all tutorials assume you only ever going to have one website, so there is a 1:1 relationship between a site and the underlying resource. They never talk about how you should organise your apps into App Service Plans etc.
I understand the concept of adding a website, choosing the appropriate pricing tier and setting the scale settings, what I do not understand is why people online talk about scaling out Azure Apps – surely if an ASP.net websites consumes a certain amount of RAM on a system, by bringing online another VM all you are doing is immediately consuming that amount of RAM again on another system. So scaling out in this sense is to ONLY improve availability – is this correct?
If someone is able to provide some of their own experiences when dealing with a lot of websites on Azure (even better if they own a web design company who hosts on Azure) it would be very much appreciated.
Think of AppService plan as a VM or pool of VMs (in case you run multiple instances) that runs the same applications simultaneously and share the same data disc. If you scale out, you add a new VM to the pool, if you scale up, you change the size of VMs (actually they aren't VMs, but from the user's point of view it is simmilar).
So basically in case like yours, where you run many applications (potentially) smaller applications, scaling up/down establishes the baseline - how many websites you can run, how many applications you can fit in the memory. And then scaling out gives your better reliability and more CPU power that helps you to cope with high traffic.
Our company is much smaller than yours, we host dozens of websites not hundreds. But there are some points that our experience have taught us:
Use at least S2 instances that have 2 cores, with S1 instances a single app can easily degrade performance of other apps in the same AppService plan
Use TrafficManager. If a need arises (e.g. an outage of the service in your region), you can easily move to another region
Split webistes between more smaller AppService plans and collocate applications with the similar usage patterns to the AppService plans. That way you can run one instance, when the traffic is low and spin up new instances when the traffic spikes up.
You are correct that in all pricing tiers (except free and shared) web apps are scaled to all machines in an app service plan. This is an availability feature from the perspective of a web app. Scaling an app service plan from 1 to 2 machines(or auto-scaling) essentially provisions the same web app on all the machines. This of course is no good for your situation, but all is not lost. Generally, the unit of scaling is the app service plan. You could break down web apps into buckets of app service plans. Say first 100+ web apps in AppServicePlan1, then roll over to the next 100+ in AppServicePlan2. The downside is that you will have to manage tracking what app service plan to place the next web app in.
I have actually pay-as-you-go plan in my account right now and I am using free 20MB database to all my projects in this account. I've created mobile services for my mobile app and it's time to release this project. So I think the best for me right now is move from Free Mobile Services to Basic so I can have unlimited devices to use this. But I don't know how much database size and bandwidth I would need. I just want to set my plan to Basic and create new database and then pay how much bandwidth and database size I would need.
I found this calculator and I just want to buy that Basic services with 1 unit and I just don't want to fill any other things (not because I don't want them because I just don't know how many and that it would be great that with rising app using there would be rising too). Is it possible?
I hope I explained my problem well.
Btw: What unit means in "1.5M API calls per unit"?
Thanks
Yes, you can continue to use Free SQL DB with Basic tier of Windows Azure Mobile Services. SQL and Mobile Services are separate items on your subscription and each can be scaled independently of the other. In practice if you have a lot of load, you will likely need to scale both - for architectural reasons.
Egress bandwidth for Mobile Service responses to the client is included in Mobile Services pricing. If you don't use SQL in the same data center, you may incur separate bandwidth charges. Although for latency reasons, we strongly recommend using a database and Mobile Service in the same data center which also eliminates egress costs for Mobile Service - SQL interaction.
You can purchase 1-6 units of Basic tier of Mobile Services. Each unit provides 1.5M API calls per month. So if you buy 2 Basic units, you will get 3M API calls per month and so on.
Thanks.
Dinesh Kulkarni
(Program Manager, Windows Azure)
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).
I am using a normal IIS web host to host my website and web services.. It is just a hobby and I get very little traffic. I would let to be using Azure instead since I would like an excuse to learn azure.
Is anyone out there using Azure in this way and can tell me about what is thier monthly cost? I long ago subscribed to azure and forgot about it and a month later had a $90 bill so that really scares me.
Right now my web host + sql is about $25 a month.
Is there a way to have azure shut the service off if it gets over a certain monthly cost?
Well, even a very small instance costs $0.05/hour, and the SLA is only guaranteed if you run two or more instances. That in itself adds up to approximately $75/month.
SQL Azure is at least $9.99/month. Add to this charges for traffic, etc.
There are reasons why the SQL Azure pricing model is like this. You do get your very own virtual machine instances with dedicated RAM, which you typically don't get in a web hotel, so taking that into account, the Azure price may be reasonable, but isn't very competitive for very small hobby sites.
The official price list is here: http://www.microsoft.com/windowsazure/pricing/
Unfortunately, Azure is not designed to host hobbyist sites. You won't be able to beat $25 a month, but then you don't need things like SLA's and HA databass. But, as I commented earlier, it is nice to be able to work with it to train up on the platform.
There are ways of getting onto Azure cheaply.
Firstly There is the free introductory offer. Very much a "toe in the water" just to play/learn the platform. There aren't enough compute hours to host a site.
Secondly, if you're prepared to put in a little effort you can join either the partner or Bizspark programs which will give you access to enough resources to host a site for free, but there is an expectation that you're trying to build "something".
Oh, and for a hobbyist site you don't need the SLA so a single instance is fine.
I'm considering to join the Windows Azure Platform Introductory Special, but I'm a little bit afraid of losing money with it. I don't wanna develop any fancy large scale application, I want to join just to learn Azure and do my experiments, what should I be afraid of?
In the transference, it says: "Data Transfers (per region)", what does that mean?
Can I put limits to stop the app if it goes over this plan in order to avoid get charged?
Can it be "pre pay" instead "bill pay"?
Would it be enough for a blog?
Any experiencie so far?
Kind regards.
As ligget pointed out, Azure isn't cost affect as a host for an application that can be easily deployed to a traditional shared hosting provider. Azure's target market are those that want dedicated resources without the need to micro-manage the infrasture and the capability to easily scale up/down based on demand.
That said, here's the answers to the questions you posted:
Data Transfers are based on bandwidth in and out of the hosting data center. bandwidth for communication occuring within components (SQL Azure, Windows Azure, Azure Storage, etc...) in the same datacenter are not billable.
Your usage is not currently capped when the free quotas are used up. However, you will recieved warning emails when those items approach their usage threadsholds.
There is the option to pay your subscription using a PO, but the minimum threshold for most of these operations is $500/month. So as a hobbyist, its unlikely you're wanting that route.
The introductory special does not provide enough resources for hosting a 24x7 personal blog. That level includes only 25hrs of compute resources. Each hour a single instance of your application is deployed will count against this, even if the application received no traffic. Think of it like renting office space. You still pay rent on the office even if there are no customers there.
All this said, there's still much to be learned with the introductory special. The azure development tools allows you to work with Windows Azure and Azure storage locally and get a feel for how they work. The introductory special then lets you deploy those solutions so you can see what works and what doesn't (not everything that works locally works hosted).
I would recommend you host your blog somewhere else - it's a waste of resources running it on Azure and you'll find much cheaper options. A recently introduced extra small instance would be a better choice in this case, but AFAIK it is charged separately as of now, e.g. even when you have an MSDN subscription those extra small instance hours do not count towards free Azure hours that come with the subscription.
There is no pre-pay option I know of and it's not possible to stop the app automatically. It'll be running until the deployment is deleted (beware! even if suspended/stopped the deployment will continue to accrue charges). I believe you will be sent a notification shortly before reaching your free hours threshold.
Be aware that when launching more than 1 instance you are charged for every hour of every instance combined. This can happen for example when you have more than one role in your Azure project (1 web role + 1 worker role - a separate instance will be started for each role).
Data trasfer means your entire data trasfer: blobs/Table storage/queues (transfers between your hosted service and storage account inside the same data center are free) + whatever data is transfered in/out of your hosted application, e.g. when somebody visits your pages. When you create storage accounts and hosted services in Azure you will specify a region that will be hosting your account/app - hosting in Asia is slightly more expensive than in Europe/U.S.
Your best bet would be to contact Microsoft with these questions.