Hej!
We have just started using Windows Azure and are now in the phase of designing our infrastructure. A question that I haven't really found a stright answer for is weather there is a limit on how many endpoints I can have per subscriptions. Some research told me 25 and then I found another place saying 150. I haven't found anything on MS offical Azure site or blog.
Does anyone know? and have the limit been confirmed?
Thanks in advance,
Lucas
I think you're confusing subscription with deployment (a subscription is really a billing model for your Azure resources: compute, storage, bandwidth, etc. A deployment will have a collection of VMs (or web/worker roles) living behind a single xxx.cloudapp.net namespace. You'd then configure endpoints at a deployment level. For a Virtual Machine deployment, you'll only worry about external-facing (input) endpoints, since VMs can communicate internally across all ports. For web/worker Cloud Service deployments, you'll also have input endpoints.
Regard the number of endpoints per deployment: This number has grown over the years, and will continue to evolve. I'm not sure of the current limit, but... It's very simple to create an endpoint with PowerShell. With a simple for-loop, you should be able to create endpoints until an error is thrown.
Related
I have a couple unrelated websites that I host using the free subscription of Microsoft Azure. They are currently all under the same Resource Group and same App Service plan (though I don't understand those concepts well enough to know if they should or shouldn't be).
In the past, I've had a problem with individual apps eating up large amounts of some resource, like CPU Time or Data Out. The issue is that they all share one quota... so if Website A has a problem that consumes all the CPU Time for the day, then Website A, Website B, and Website C ALL go down until the quota resets, even though Website B and Website C aren't contributing to the problem.
In short, how do I prevent that so that each website has its own quota (not a shared quota)? Can I separate the websites into different Resource Groups? Different App Service plans? I tried to understand Microsoft's documentation on how these quotas work, but I was unable to find the answer to my question.
Thanks!
I have a couple unrelated websites that I host using the free subscription of Microsoft Azure. They are currently all under the same Resource Group and same App Service plan (though I don't understand those concepts well enough to know if they should or shouldn't be).
Resource groups define a way to group multiple related azure resources together. Typically all resources in the same resource group are deployed together, for example using ARM/Bicep templates.
An App Service plan defines a set of compute resources for web apps to run.The free tier provides 60 minutes of cpu time per day. You can host multiple web apps on the same plan, as you do. But in that case they all consume parts of that 60 minute cpu time quota.
In short, how do I prevent that so that each website has its own quota (not a shared quota)? Can I separate the websites into different Resource Groups? Different App Service plans? I tried to understand Microsoft's documentation on how these quotas work, but I was unable to find the answer to my question.
If you do not want to share the cpu time between the multiple web apps on the same app service plan you can create a free tier App Service Plan per web app, and deploy each web app to their own dedicated free tier App Service Plan.
I'd need to use Traffic Manager to route traffic to three app services I have in the same region (one app service with three instances won't work, I need more control on the load balancing).
I read here that this is possibile
I tried to set up the app services in different app service plans but still I cannot assign the same domain to more than one app service. In the doc I read "scale unit" but I do not know what it is, any ideas? Basically I cannot create two App Services in the same region with the same domain assigned to them.
I am not really sure that you need more App Service Plans, but let's say you need.
Than what you will be looking at is nested profiles.
There is also good documentation which explains the limitations:
Each Traffic Manager profile can have at most one Web App endpoint
from each Azure region. To work around for this constraint, you can
configure a Web App as an External endpoint. For more information, see
the FAQ.
and workarounds for some of them here.
The scale unit, is the one that bugs you. #juunas is on the correct path to help you find your scale unit. However AppServicePlan is not a single VM, but that's another subject.
So the basic idea:
you create an app service plan
you create a web app within it
you rung the nslookup yoursite.azurewebsites.net to discover your real DNS name. Just like #juunas pointed, it would be something like waws-prod-am2-077.vip.azurewebsites.windows.net. The waws-prod-am2-077 is your scale unit.
You repeat these steps until you discover that your App Service Plans run on different scale units.
It is really pity that this is not documented anywhere. And no, there is no easier way to check the scale unit of an app service plan. Neither is there easier way to deploy multiple app service plans across different scale units.
On the other hand, having your app service plans spread across different scale units will give your app much better resiliasncy against partial service outages :)
I thought one of the advantages of Azure was that I could turn services on and off depending on when I want them to be available.
However I cant see how to pause my App Service Plan.
Is it possible?
I want to use the S1 tier so that I can play with what it offers. However I want to be able to pause the cost accumulation when I am not using it.
I see from the app service pricing help that an app will still be billed for even though it is in the stopped state.
Yet the link also clearly states that I only pay for what I use. So how does that work?
If you put your hosting plan onto the free tier, you will stop being charged for it. However if you have things like deployment slots and certificates these will be deleted.
The ability to turn services on and off, is more to do with being able to scale services, so if you need 50 servers for an hour you can easily do that.
What you can do to make your solution temporary is to create a deployment script, using Powershell or Resource manager Templates then you can deploy your solution for exactly as long as you need it and then delete it again when you don't. In this sense you can turn your services on and off at a whim.
Azure provides building blocks for you to create the solution you need, it is up to you to figure out how to best use those building blocks to create the solution you seek.
Edited to answer extended question.
If you want to use the S1 pricing plan, and not have it charge when you are not using it, the only way of achieving that is by using automation. Fortunately, this is reasonably trivial to achieve.
If you look at this template it is pretty much all configured to deploy a website from Github to Azure on demand. If you edit that to configure it to your needs you can have a new Azure website online with 2 minutes of running the script.
Then you would have another script that deleted it once you had finished.
Doing it this way you would loose no functionality, and probably learn quite a bit about what is possible with Azure along the way.
App Service Plan
An app service plan is the hardware that a web app runs on. In the free and shared tier your web apps share an instance with other web apps. In the other tiers you have a dedicated virtual machine. It is this virtual machine that you pay for. In that case it is irrelevant whether or not you have web apps running on your app service or not, you still have a virtual machine running and you will be charged for that.
To change the App Service Plan via PowerShell, you can run the following command
Set-AzureRmAppServicePlan -ResourceGroupName $rg -Name $AppServicePlan -Tier Free
I was able to accomplish this using the dashboard by selecting the App Service Plan, clicking Scale up (App Service Plan), and then from there if you click Dev/Test you can select the Free tier.
As others have mentioned, you need to script this. Fortunately, I created a repository with one-click deployment to your Azure resources.
https://github.com/jraps20/jrap-AzureVerticalScaling
The steps are intended to be as simple and generic as possible:
Execute the one-click deployment from the repo readme
Select the subscription, resource group etc.
Deploy resource to Azure
Set up your schedule to scale up and scale down as-needed
The scripting relies on runbooks and variables to maintain the previous state of each App Service Plan and App Services within those plans. Some App Services cannot be scaled due to specific settings being used (AlwaysOn, Use32BitWOrkerProcess, ClientCertEnabled, etc.). In those cases, the previous values are stored as variables prior to down scaling and then the original values are reapplied when the services are scaled up.
For more clarity, I have written a blog post that goes into detail. The post is pertaining to Sitecore, but applies to any App Service setup- Drastically Reduce Azure PaaS Hosting Costs in Non-Prod Environments With Scheduled Vertical Scaling. It also includes a brief video tutorial to show its use case.
Myself and others have been using this repository/approach for well over a year and it works great. I mostly use it for POC's to reduce costs when I'm not actively working on something. However, its main intention was for targeting non-prod environments to save costs during non-work hours.
Azure App Service Plan is just an logical concept of a set of features and capacity that you can share across multiple apps. I don`t think you can "pause" a plan, instead you can pause your service. and depends on billing model of each service, you might or might not get charged.
Pausing = Delete or lower tier.
Scripting is the key.
Design Diagram
Use scripts to create (also consider shared resources)
Delete using scripts
Use scripts to recreate.
eg: If we use resource group properly per environment then
Export-AzureRmResourceGroup will create a template for us (everything in the resource group will be pulled out as script). So we can delete it and recreate it anytime.
To pause a VM and stop billing you need to shut is down and deallocate it. Just shutting down still has the capacity reserved as if its running.
Storage can't be shutdown - it can be moved to lower cost tiers.
I just read a small post of #pierreroman with the title Azure Cloud Service VS Azure Resource Manager. Unfortunately I was not able to comment his post (There was an error saving your comment. (Cannot create comment - access denied.)). Therefore and because I think this topic is interesting for many folks who are using azure cloud services right now, I write my "comment" here and send him a tweet. Maybe he or someone else can answer my questions.
I think that more interesting than the "what is the difference between cloud services and resource groups" is the question "should we plan to move from cloud services to azure resource groups?". Is it even possible? Or are we comparing apples to oranges?
What about scaling (for example adding new instances of a worker role with a simple slider or with auto scaling)?
The comparison is kind of apples(Cloud Service) and grocery(ARM) where can manage fruits, meats, and fishes.
But, very first concept of Cloud Service was similar to the ARM. That's why sometimes confusing.
Below quote is from free ebook Azure Web Apps for Developers (download), page 12 and 13.
An Azure Resource Group is a logical container for grouping Azure resources.
Grouping resources this way helps simplify the implementation, deployment, management, and monitoring of resources in the resource group. From a billing perspective, it gives you a way to view costs for the resource group rather than for individual resources, eliminating the need to figure out which resources are related. You can think of an Azure Resource Group as a unit of management.
The last line helps to understand clearly, Azure Resource Group is a unit of management.
We currently have a window service which send some notification emails to users after doing some processing on database(SQL database). Runs once in day.
We want to move this on azure cloud. One alternate is to put it on Azure VM as is. but I am finding some other best possible solution for that.
I study about recurring and on demand Web jobs but I am not sure is this is best solution.
Also is there any possibility to update configuration of service code in App.config without re-deploy the code of service on cloud. I means we can manage configuration from Azure portal.
Thanks in advance.
Update 11/4/2016
Since this was written, there are 2 additional features available in Azure that are both excellent choices depending on what functionality you need:
Azure Functions (which was based on the WebJobs described below): Serverless code that can be trigger/invoked in various ways, and has scaling support.
Azure Service Fabric: Microservice platform, with support for actor model, stateful and stateless services.
You've got 3 basic options:
Windows service running on VM
WebJob
Cloud service
There's a lot of information out there on the tradeoffs between these choices, but here's a brief summary.
VM - Advantages: you can move your service basically as it is without having to change much or any of your code. They also have the easiest connectivity with other resources in Azure (blob storage, virtual networks, etc). The disadvantage is you're giving up all the of PaaS advantages and are still stuck managing your own VM infrastructure
WebJob - Advantages: Multiple invocation options (queues, blobs, manually, queue receive loops, continuous while-loop style, etc), scheduled (would cover your case). Easy to deploy (can go with website, as a console app, automatically through Kudu), has some built in logging in Azure portal - and yes, to answer your question, you can alter the configuration in the portal itself for connection strings and app settings.
Disadvantages - you'll need to update code, you don't have access to underlying resources (if you need that), and more of something to keep in mind than a disadvantage - it uses the same resources as the webapp it's deployed with.
Web Jobs are the newest of the options, but at the same time appear to have active development going on to increase the functionality and usefulness.
Cloud Service - like a managed VM, has some deployment options, access to underlying VM if needed. Would require some code changes from your existing service.
There's nothing you've mentioned in your use case that makes me think a Web Job shouldn't be first thing you try.
(Edit: Troy Hunt has a great and relatively recent blog post illustrating most of the points I've mentioned about Web Jobs above: http://www.troyhunt.com/2015/01/azure-webjobs-are-awesome-and-you.html)