We are planning to deploy one of our reporting application/product on Microsoft Azure platform for testing & research purpose.
Application is built on .NET framework 4.5 , and thankfully Azure does support 4.5 now.
Application is not Azure ready yet. I assume some config level changes are required to deploy it over Azure. Not much is required in Azure websites though.
Our Application has three major components , one is the MVC web layer built using n tier approach. Second component is an independent window service that pulls data periodically from an external system, and pushes that into the third component, a SQL Server database. MVC Web layer coupled with a business layer uses this SQL server to perform R/W operations.
Had it been a typical case of web application with a database, I'd have gone for Azure websites. Now that I have a window service/(Schedule based data puller) in picture as well, I am confused what accounts & services I should opt for , within the Azure platform ?.
Azure provides bouquet of services such as Websites, Service Bus, Cloud services, VM etc, but I am pretty confused what setup will fit in good for this application.
Some additional details about the application :
UserBase (for a single instance) : 10-30 users at a given time.
Data volume collected from external system/web service : approx 100 mb per
day.
Do I need to setup multiple services like Azure websites at one end with a database, and for scheduler/window service something else ?
Since you have a background windows service keep pulling data currently, I'd like recommend you using Windows Azure Cloud Service (WACS). You can migrate your MVC web portal as a web role and the background service logic into a worker role. Then your worker role can pull data from the external service and insert data into Windows Azure SQL Database (WASD). Then your web role can r/w data from WASD and display them in the portal.
The Windows Azure Web Site (WAWS) currently doesn't have the symmetrical feature as worker role. But since both WAWS and WACS can use WASD, you can move your web portal to WASD, and your background job into WACS worker role.
Hope this makes sense and helps
Related
I have a long running console application, using while(true)... structure
It implemented by using Net Core
What type of Azure App Service I should create to host that application ?
Decision tree for Azure compute services
Azure offers a number of ways to host your application code. The term compute refers to the hosting model for the computing resources that your application runs on. The following flowchart will help you to choose a compute service for your application. The flowchart guides you through a set of key decision criteria to reach a recommendation.
Treat this flowchart as a starting point. Every application has unique requirements, so use the recommendation as a starting point. Then perform a more detailed evaluation, looking at aspects such as:
Feature set
Service limits
Cost
SLA
Regional availability
Developer ecosystem and team skills
Compute comparison tables
I recommend reading this guide afterwards
Criteria for choosing an Azure compute service
Another great entry point for developers concerned with a similar question
.NET application architecture
You have to use "Azure App Service as a WebJob"
To deploy the .NET Core console application to an Azure App Service Web App Web Job access the Azure portal and navigate to the Azure App Service where you will host the WebJob.
Clicking on the Add button renders the blade
Once the WebJob is successfuly uploaded, it will render in the WebJob blade. Click on it and you will see the Run button. As this WebJob is a manually triggered job, you must click on the Run button in order for the job logic within the .NET Core console application to run.
After starting the .NET Core WebJob, click on the Logs link and a new browser tab is opened and you can see the most current state of the WebJob
I am having problems with the number of pooled connections in my Azure web app. And it will help me a lot if I can see the number of pooled connections so I can understand how it relates to the application usage.
On classic Windows machines I can view the ADO.NET performance counter "NumberOfPooledConnections" using the "Performance Monitor" tool. But I could not figure out how to do the same thing when I am using an Azure App Service.
Unfortunately, performance counters are not supported on Azure App Services due its multitenant nature of it.
See: Access performance counter programmatically in Microsoft Azure web app
Three things that you may want to try however is:
Enable Application Insights (https://learn.microsoft.com/en-us/azure/application-insights/app-insights-performance-counters) or New Relic.
If your application is for test purpose, I can also suggest to deploy to cloudservice where you will have access to the full VM and traditional Perf counter
Try deploying to App Service Environments & I believe you will get access thru programmatically at least. This does get expensive.
We have an application which is an Asp MVC application which communicates via WCF to a middle tier application. We will be rewriting this and want to target Azure
It's split into 3 tiers, web, business, database, which are all on separate machines, as some of the business processes can take a few seconds. When the web calls the middle tier it must wait for a response before returning to the user, i.e. something like a message queue isn't appropriate here
I'm thinking for the new architecture we have
Client: AngularJS
Web: Probably Asp MVC controllers in a Web App
Middle tier: ?
Database: Azure SQL Database
The middle tier is where it gets confusing, what is this in terms of Web Apps and how does it communicate with the web? I think we'd prefer a RPC approach rather than REST based if possible. We just want to send serialized classes back and forth
What about scalability? We're presently assuming that the web will need to be stateless
Since Azure Web Apps is a platform that builds on top of IIS, you can run an IIS-hosted WCF-service on Web Apps just fine.
As for scalability, Azure App Service allows you to scale horizontally manually or automatically.
If the Web and Middle tier share scaling requirements, you can place both on the same App Service Plan. Then they share the instances and scale simultaneously. If however their scaling requirements are quite different, I recommend you put them in their own App Service Plans. Then one's scaling doesn't affect the other.
I'm curious to know if this is possible, and if so, is it a good or bad idea?
We are developing an Azure application that is largely centered around worker roles that receive their work on a CloudQueue, and put the results in a CloudBlob, that the client then downloads. The web interface itself is a dead-simple ASP.NET MVC site that throws jobs in the CloudQueue, and builds URLs to download CloudBlobs.
Currently we accomplish this by having a Azure Cloud Project in our solution, which has a Web Role with the UI, and Worker Roles with the actual work.
Could we use Azure Websites to publish and host the UI, which calls back to our Worker Roles? The Azure DLLs are just regular old .NET libraries, I'm assuming Azure Websites won't have a problem with them. So, when we want to update the UI, we just publish with Visual Studio. And when we want to update the Worker Role - which is 300MB+ and has a bunch of nasty dependencies like Crystal Reports - we can build the cloud bundle and update the Cloud Service through the Azure management portal.
This seems to me like doing this would make it easier to update the UI. I think it would also be cheaper to host it, as we won't have to buy a bunch of instances for the Web Role.
If your question is "Could we use Windows Azure Websites*", based on your application architecture, you sure can use Azure Website to deploy your front end and configure all the networking connection properly so you can continue access other Azure Storage services. As you are using mostly Blob and Queue, you can continue use HTTP/HTTPS settings in the Azure websites. You can keep worker role by as it is however if it is very complex to deploy, using Windows Azure VM may be another direction to go.
I could say website deployment could be easier if your web app does not have something complex to configure in web server as websites may not be able to match web server level configuration compare to webrole and Azure VM. Answering "Easier and cheap" could be very subjective as this is all depend on load and distribution so you would have to try and evaluate it.
Lets say I have an application, that is separated into various layers (Presentation, Business, Data Access). How to deploy those layers to Azure independently? The question is about Azure configuration, not about the architecture of application.
An app is usually divided up into various roles, each role being Windows Server 2008 R2 with a defined size and number of instances. You'd typically break your app up into roles for scaling and management purposes. It's often simplest to deploy an app within a single deployment.
On to your scenario: If, say, you want to push up a Web Services layer that lives independently of your app (or maybe it serves multiple apps of yours), then you would put that Web Services layer (in a Web Role, let's say) in its own deployment. You'd need to manage authentication / authorization, since the Web Services would then be using a public endpoint for communication (or you could use Service Bus).
In your example: you could push your Presentation tier (e.g. website) to one deployment with a set of Web Roles, along with supporting services such as Cache. You'd have your Business Layer in another deployment, maybe running with web Services as in my example above. Then your data layer could be SQL Azure (Database-as-a-Service) or maybe a standalone database like MongoDB, running in its own deployment.
Each deployment would have its own project, and you'd deploy and manage each one separately. There's no configuration that spans all deployments.