Azure web sites (standard) has always allowed scaling up to 10 instances per the documentation and the management portal. However, as of yesterday (3/11/14), I can only scale up to 3. I do not see any announcements regarding this change. Is this a bug in the portal or did something change?
There was an issue, but it has been mitigated.
Related
I am new to the Azure platform and hosting in general and I am currently moving some web apps to Azure Paas and have configured a single App Service Plan which contains 3 applications.
I have read all the documentation I can find and I know the plan guarantees 99.95% up time but I cant find any info in regard to hardware failures. i.e. if there is a hardware failure on a rack where my app is hosted am I automatically covered by the plan? Does my app exist in multiple fault domains?
Hope someone can help
Thanks
You can see the details here. I'd say hardware failures are considered as downtime:
https://azure.microsoft.com/en-us/support/legal/sla/app-service/v1_4/
Microsoft guarantee that Apps running in a customer subscription will be available 99.95% of the time.
Note: No SLA is provided for Apps under either the Free or Shared tiers.
For more information, refer SLA for App Service.
This SLA works based on the fault domain and update domains, understand how fault domains and update domains works in Azure.
Is it possible to put app to sleep during night time anymore?
I have the app service setting NOT on "Always On", but this setting is not respected.
The bills used to be twice as much as they are now, because in past they app set itself to sleep. How do I know this? The service hours are now around 730 (that's a full month). Is Azure no more "Pay-As -You-Go?"
Thanks.
#Joonas, There was never an option to put the app to sleep in Azure Web Apps. The only way to ensure that you are not getting billed is to Scale down the corresponding App Service Plan of the web app to FREE tier.
You can configure scale settings based on a specific schedule so that the app service plan can be scaled up.
Always On is a setting used to keep your app up and running at all times. Assume that you have 10 web apps hosted on a server, out of which 8 are your dev or least used sites, while the other 2 are busy sites accessed throughout the day. In such a scenario you don't want the dev sites to be running at all times as they will hold system resources. The Always On feature is handy in such scenarios. You can set Always On to true for the 2 busy sites and false for the other 8 sites.
Check the number of App Service Plans in your subscription and
also their pricing tier. This will help you understand the costs. In
Azure App Service, you get billed for the App Service Plan and not
the Web App.
This image should help you understand App Service Plan
You can get the answer from this official FAQ:
Am I charged for apps while they are in stopped state?
Yes. Rates listed apply to apps in stopped state. Please delete apps that are not in use or update tier to Free to avoid charges.
I am looking at possibly running some of our business on Azure.
I am trying to pick the services that would work best for my company, but I am getting mixed signals.
Because I am starting a new system, I want to pick the offerings that are not "legacy" (aka "current"). But there seems to be no way straight forward way to know that.
For example, this page of the Microsoft Documentation says
Cloud Services is similar to Service Fabric in degree of control versus ease of use, but it’s now a legacy service and Service Fabric is recommended for new development.
This page clearly states that Cloud Services is "legacy". However, you would never know this by going to the Cloud Services overview page. It has great marketing material that sells Cloud Services as a great option. But if I picked it, then I would be starting out on a platform that is in a legacy status.
Now I know that about Cloud Services vs Service Fabric. But there are tons offerings on Azure. I am trying to research them one by one to find out which ones are the most recent incarnation, but I feel like I am wasting my time.
Another example is storage. Lucky for me an Azure MVP answered my question on this one. Apparently, there is "older storage account" based disks and "managed" disks. Turns out managed disks are the new, easy way to do things. The storage account is harder. Still available, but not really what a new user should be picking. But again, this is very hard to find out unless someone who has been working with this stuff for a long time tells you.
I was about to start in on App Services and Web Apps, but I thought I would ask first to see if I am doing research that is already done and posted out there.
Is there somewhere that shows the current list of Azure services that you should look at if you are starting a new project?
I asked the similar question almost a year ago, and I even spoke with Azure Support Team after that. At that time, Microsoft did not officially state Cloud Service is legacy.
Does Azure App Service/Web App replace Azure Cloud Service?
We have been hosting our enterprise applications in Cloud Service since 2013, and a couple of them are in App Service. Here is my thought -
4 years ago we only have Cloud Service - Web Role and Worker Role,and App Service (formally named as Web App) is not fully ready for enterprise applications yet. Since App Service came up, Microsoft heavily promote App Service compare to Cloud Service. In addition, what I notice is Cloud Service did not get new features like App Service.
Service Fabric is quite new, and it doesn't have all the belts and whistles like App Service, so we might have to wait a bit for enterprise applications.
Only advantage of Cloud Service is you can remote desktop to a role instance, after the application is deployed.
If I host a new application in Azure today, I'll definitely use App Service.
Microsoft has published a list of Azure reference architectures. It was last updated in November 2016. You can browse it here, and there is some guidance given. But for example, you mentioned using Service Fabric (which is a great way to go for a robust app that really needs to scale), but Service Fabric isn't mentioned in the aforementioned resource.
I spend a lot of time running down Azure resources in relation to web applications (not to be confused with App Service Web Apps), and I have not found a definitive source of the type of info you're looking for personally.
I am looking into web Apps Monitoring in Microsoft Azure and I can see a variety of options in the portal. I have some questions in those which I will put forward one by one. The question length may be a bit long so apologies in advance :-)
Process Explorer
Here we can find process details per instance which are running for my Web App.In case of scale out we will also see multiple instances. I want to know why we are seeing 2 processes per instance and what is the significance of each process.
2.Metrics Per Instance (Apps)
While looking at this report, I can see 2 different tabs (see image), I am unable to map it to the instances I am having in my web apps.
2.A) Is it true that If I have multiple deployment slots/ scaled out instances I will see that many tabs in the report?
2.B) Is there a way by which I can map these to my Web App instances in the Process Explorer
3.Metrics Per Instance App Service Plan
Here Again we have to different indicators same as in Apps. Can some please help me how to decipher these.
Can you guys please help me out with the reports as it seems to be quite confusing and I am unable to map it with my Instances, Deployment Slots in relation to the app service Plan.
Once again apologies for a long question.
Thanks in Advance,
Mayank
Looks like no one answered this in a long time. Let me see if I can explain this better.
This blade that you are talking about is accessible under "Diagnose and solve problems" options of an App Service Web App. Lot of changes has been made in the last few months to this feature. Read more about it here: App Lens - Azure App Service
1. Why we are seeing 2 processes per instance and what is the significance of each process.
In Azure App Service. For every web app there is another web app provisioned. This site is known as KUDU. So one w3wp.exe corresponds to the process hosting your code and the second w3wp.exe corresponds to the process hosting the KUDU. This process will have a SCM tag appended against it. You can read more about it here: Project Kudu - Github
2.Is it true that If I have multiple deployment slots/ scaled out instances I will see that many tabs in the report? Is there a way by which I can map these to my Web App instances in the Process Explorer
To answer the first part, YES, the tabs corresponds to the number of instances the app service plan is scaled out to. So if your web app is scaled out to 7 instances, then you will see 7 tabs in the report.
There is no straight approach to correlate the instance names to process explorer. There is an alternate way. I have a blog post using which you can connect to the KUDU site of a web app on a specific instance. See this: Connect to Kudu site of a specific instance
3. Metrics Per Instance App Service Plan Here Again we have to different indicators same as in Apps. Can some please help me how to decipher these.
as the name says, Metrics per instance (App Service Plan) displays data for the entire VM, while Metrics per Instance (Apps) displays data for a specific web app or process (w3wp.exe). In Azure App Service, you can provision several web apps inside a VM. So, this view provides a holistic view of the overall usage of the VM. This will help you in determining whether you need to scale out or scale up.
I hope this answers this question.
We have set up 40 sites on 4 different hosting plans. One of the plans has very high memory use even though it only has 9 sites, but I can't see which 9 sites this plan contains!
In addition, though I can see the overall memory use for the plan, is there any way to tell which site is using all the memory?
Two part answer:
To see which sites are under which plan, browse to the Web Hosting Plan in the preview portal (portal.azure.com).
To see the memory used by a given site you can go to that site's kudu portal (located at http://.scm.azurewebsites.net) and log in with your Microsoft credentials. Click on the Process Explorer tab. Now you'll see all the processes running in that site and exactly how much memory each of them is taking.
You can also see memory usage in the preview portal but the kudu portal will give you better details as to what's going on