azure-functions are a special type of App Service on Azure. The other main Azure App Services (web & api) support multiple deployment slots on a sufficient App Service Plan (S1 and up). It seems likely that this is also an option for azure-functions, but I can not find the configuration area. Am I just not finding it or is this functionally not available for azure-functions?
Update 5/13/2017: slots are now supported as a Preview feature.
Original answer:
Deployment slots are not supported at this time in Azure Functions. However, they will be supported going forward. Slots raise some interesting issues, and we want to make sure we tackle them before enabling this.
Related
App services have a good integration with application insights. Request can be traced from the caller through the dependencies across service boundaries.
This is not available by default with AKS.
I am trying to use this lab .
https://azure.github.io/kube-labs/5-aks-appinsights.html#objective-of-the-lab
Although when I reach the third step which is to execute init.sh,it gives me error.
ERROR: After approving csr app-monitoring-webhook.kube-system, the signed certificate did not appear on the resource. Giving up after 10 attempts.
I have modified the init.sh.
Changed apiVersion: certificates.k8s.io/v1 from v1beta1.
Used this link: https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers
Still getting this error.Is there any other way to link app insights with aks?
I am doing this for a .net core project.
[I'm from Application Insights team]
We're actively investing into providing similar experience for AKS as we do for App Services (glad that the latter is working for you!). Unfortunately, above lab is a few years old and based on private preview bits. We'll try to update this lab.
One option which is available today (and many AKS customers use it) is to instrument with Application Insights .NET SDK. Essentially you'll get exactly the same experience as with App Services (all incoming/outgoing requests will be auto-discovered and collected).
We have a bunch of Windows Services. We need to be able to continue to deploy our code as Windows service on premise, but would like to deploy to Azure where appropriate. The goal is to manage less infrastructure. I'm not keen on deploying dozens of bits an pieces as Azure Functions, but not entirely opposed to it either. Azure Batch / Webjobs are also another option. However, the long term goal is to move all of our services over to an orchestration server like Service Fabric so that all the services can be deployed and orchestrated from the one place. This is mainly a deployment consideration.
We will break the existing C# code in to .NET Core class libraries and reference them from either Service Fabric hosted in Azure, on-premise Service Fabric, or on-premise Windows Service. Is Service Fabric an appropriate choice? Or, is there a strong reason to run background jobs as Azure Batch / Functions / Webjobs?
This is Microsoft's diagram from here:
The answer to the question is that we don't really need full fledged orchestration right now, but it will become more important moving in to future. I have to balance being able to deploy all our code in one hit with the ease of ad hoc deployment that Azure Functions offer.
(Stateful) Services can be an excellent way to run background jobs. They offer the RunAsync entry point, in which you can run your job, check (and store) progress. SF really shines when multiple services collaborate on tasks, offering SF Remoting as a communication channel, with built-in retry support.
You can choose to containerize your software, which would free you from platform lock-in, but prevent you from using some platform features.
By automating delivery of services (CI/CD), you can deploy to any platform you choose. This is not something that is specific to SF.
We have the challenge of implementing services that can be deployed both in an Azure Cloud (On-Demand) as well as in a local LAN On-Premises scenario. This is fine with .NET-Core, SQL-Server, Redis etc.
What we are missing is a common feature for Functions-as-a-service or WebJobs. Both of these Azure services appear to be cloud-only. Is something like Hangfire the most viable approach, or are we missing something?
Thanks
Azure Functions Runtime enables you to run Function Apps on premise. Note that it's still in preview though.
I am having a problem with a third-party library. It worked last week but this week is failing. I wish to turn on the network tracing as I would normally configure in web.config such as is described for an Azure App Services job here:
https://blogs.msdn.microsoft.com/waws/2017/03/14/how-to-get-a-system-net-trace-of-your-c-web-job/
Is this in any way possible with Azure Functions, or is there an alternative?
Unfortunately this isn't possible with consumption plan as we don't allow you to modify the web.config.
If you can set up an app service plan for testing, you can deploy the functions runtime as a private site extension with your web.config changes, see here: https://github.com/Azure/azure-webjobs-sdk-script/wiki#deployment
A related option to help you with diagnostics/analytics is the preview app insights support: https://github.com/Azure/Azure-Functions/wiki/App-Insights-Early-Preview
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.