I'm in the process of implementing a series of web api services that must be separated and isolated from each other when running. For this, each service is a different Asp.NET Web Api project, but for simplicity and cohesion, we have it all in the same solution.
We plan on deploying the services using Azure Cloud Services but I can't find a way to set up the projects so each one is published on a different CloudService.
Thanks
Related
I want to consolidate a collection of Azure Functions and a WebAPI on the same App Service. Can't figure out the best way to go about it and be able to manage both solutions in the portal.
An App Service plan supports multiple resources deployed to it: Function apps, Api apps, Web apps, etc. There shouldn't be any issue doing this.
Each app deployed to a service plan will get its own uri and local storage, but will share the app service plan's capacity (e.g. if you have an S2 plan running on 3 instances, all of your deployed apps to that App Service plan will run on all 3 instances, utilizing the resources of the S2-based instances).
Instances of the same app share disk resources. Your different apps are isolated from each other.
You can't run them in the same site (ie, with the same URL like mysite.azurewebsites.net). Although you could use Function Proxies to forward out part of the function url namespace to the WebAPI. Your azure function and WebAPI would be 2 separate entities in the portal, similar to having 2 separate WebAPIs.
As others have said, this is possible.
For the function app, you need to choose "app service plan", not "consumption based".
You also need to have an app service plan which isn't on the Free or Shared tier. i.e. it has to be a minimum of B1 - no minutes/hour usage limits.
My understanding so far on PaaS deployment using WebRoles or Worker Roles-
Spinning Web roles or Worker roles will create Cloud service to manage it.
However, in ARM resource group, their is no concept of Cloud service, then how are web & worker roles managed in ARM resource group?
Also I tried adding the webroles via JSON Outline in VS 2015, but no option to add webroles. So not sure if you can deploy webroles via JSON template?
Any information will be of great help.
Cloud Services have been around since the beginning of Azure.
To the deploy or manage them, you have to use the old APIs (Azure Service Management).
As far as I know, they won't be migrated to the new APIs (Azure Resource Manager), but you could use Virtual Machine Scale Sets instead.
Azure Resource Manager Web apps rely on the concept of App Service Plans, rather than cloud services. Basically this is the underlying VM(s) that the service runs on. You can specify the size and number of servers that make up the App Service plan, and then deploy on to those as a single unit.
You create an App service plan, then run web / worker roles inside that (as well as Logic, API, Functions)
As far as Web / Worker roles are concerned, App Service Plans do not draw a distinction between the two. You simply deploy code to it and it will run it however it is packaged. See here
The concept of cloud services simply don't exist within the Azure Resource Management model.
You can find a template for deploying a Web App here
I have an Azure cloud service in which there are multiple background processing tasks which I would like to turn into WebJobs. I've read all I could find on the subject but it seems that WebJobs are tightly related to Web Apps and not Cloud services. I managed to create a web job in my cloud service solution and it seems it deployed correctly but I can't find a way to see it or its output on the new Azure portal (I couldn't see it in the classic management portal either)
Can one have a set of WebJobs running with a cloud service?
Web Jobs is a feature specific to Azure Web Apps. You'd need to create a Web App (in an App Service Plan) to create your Web Jobs. These are unrelated to Cloud Services (web/worker roles).
When I publish an api to azure from visual studio I see an existing app-service plan and also an option to create a new plan. The api I am going deploy will be used by the web application which was deployed using the existing service.
I have the following questions:
If I use the existing plan what would happen to the sites which are
already deployed using that plan?
Should I create new or use
existing?
Cost-wise which is the best option?
By using the same service plan to host the web app and the api, nothing will happen to the existing website besides you won't have any extra cost. The web apps will share the same resources.
If you create a new service plan for you api, you will have extra cost depending on the pricing tier you need.
The choice can depend on your scaling needs. If you need to define differents scaling plan for the api and the web app, it's a good idea to use two services plan, if not an unique service plan can be used.
I'm trying to migrate a number of solutions into Azure.
The solutions consist of multiple projects but the projects come down to three basic types:
ASP.NET MVC/WebForms Application
ASP.NET WebApi Application
.Net Windows Services (We have a large number of these)
Each of these projects utilize a RabbitMQ cluster that we run.
At the moment these are all running on our windows servers in our data center.
We do not want to just pick up and start running Virtual Machines in the cloud, we want to move to utilize the PaaS offerings as managing and maintaining the servers is not something we want to do.
However I am confused on what Microsoft's recommended process is when it comes to migrating a Windows Service to Azure PaaS. There is talk about Worker roles, Web Roles, Logic Apps and Web Jobs.
It initially looked like worker roles would be the thing to go towards so I implemented a very simple worker role that talks to a RabbitMQ cluster on my local machine and it worked fine.
I then setup 2 virtual machines in a virtual network in Azure (Resource Manager) and now I find that worker roles can only connect to a virtual network created via the classic portal (WTF).
So my question is:
What is the recommended approach to having windows services in Azure, remembering that we want to utilize PaaS offerings rather than IaaS wherever possible.
The documentation seams to be all over the place, some places are talking about the classic portal some are talking about the new portal.
I cannot believe that I'm the first person to ever want to have an ASP.NET WebApp be able to talk to a virtual machine on a Azure Virtual Network and also have some kind of windows service also talk to the same virtual machine.
The answer is, as always, "It depends".
The full answer can be very long, but in 2 words:
You can take new Azure portal as "Azure2.0". Among other changes, Azure completely changed the way its resources are created and managed
As far as Web / Worker roles (cloud services) are belongs to "old" model, you have limitations you described.
WebJobs and Logic Apps can be great, as well as Azure Functions - but each of them is limiting your code / solution to its restrictions.
I'd consider to check out Azure Service Fabric - it should allow you to more effectively deploy and reuse compute resources of your migrated services