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.
Related
There are probably no less than 150 different configuration options for an instance/application of Azure App Service Web Apps. This is only part of the list and each of these items have various options and inputs.
Authentication/Authorization
Application insights
Managed service identity
Backups
Networking settings
Scaling settings
WebJobs
Push
MySQL in App
easy tables
data connections
API definitions
CORS settings
... etc, etc
From a configuration management perspective, how do I either source control these settings (preferred) in a config file or use a configuration management tool to manage them?
I don't see a way to define the individual apps in an ARM template.
My goal is to have a consistent and repeatable application configuration across multiple applications and prevent mistakes with manual setup.
Per my understanding, the settings you mentioned includes the whole configurations of the web app, like Deployment slots, Backups, etc.
AFAIK, you may not be able to control them(at least like Deployment slots, Backups,etc) via the ways you mentioned.
My goal is to have a consistent and repeatable application configuration across multiple applications and prevent mistakes with manual setup.
Currently, the closest way is to clone web app, you could use it via the portal or powershell, but it could not support clone the whole configurations in the web app even if you use it.
Also note: App cloning is currently only supported for premium tier app service plans.
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 have an MVC front end application (relatively small) with its own DAL implementation using repository pattern. I am thinking of moving the DAL in its own WebAPI project to maintain cleaner separation. The MVC app is hosted in Azure using a cloud service (web role). The WebAPI will only be used by the front end application and would not be exposed to any other external application for now, but even then i would still want it to be hosted as a separate app/web/worker role rather than keeping the DAL in same project.
Would it be a good idea to:
1) Host the WebAPI project within the same Cloud Service as a Web/Worker role or should I create a new website/cloud service for hosting it? Using the same cloud service is preferred keeping the cost factor and n/w latency issues in mind.
2) If I host in same cloud service, what is more advisable to use for web api project - web or worker role?
3) Somewhere i read that I should make use of Service Bus in Azure for interaction between MVC frontend and WebAPI backend. Is this the suggested way of doing it or is there any simpler way of getting it done?
I would suggest you to use the same cloud service. The reason being complexity and failure scenarios, when you split your app into multiple cloud services the problem comes when you are updating them service from your source control
You will need to do two deployments and make sure they are in sync etc.
I would keep the service runtime simple in one cloud service.
Again it is preference and comfort, if you really want to separate them at code level and know they will work fine. The two cloud services should be OK.
From experience, refactoring decision like these add a lot of work in the future. Positive or negative depends on your understand of the problem and the image of the bigger picture you have in your head that cannot be put on paper :).
Happy to Help, Yours Truly -CB
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
Please tell me what is the relation between Windows azure and multitenacy application?
How to make multi tenant application?
It possible to host multi tenant application in windows azure platform?
Windows Azure is a platform upon which you can build web applications and services. Windows Azure does not provide multi-tennancy support built-in (multiple separate clients using the same app instance but not sharing data between clients).
Your options are two write your application for single-tennancy and configure a new instance of that app for each client, or implement your app for multi-tennancy and handle user accounts and user separation internal to your app.
Windows Azure does support multi tenancy, but you have to architect for it.
The most typical model I've seen used is a multi tenant web and business layer with a single tenant data store. You can debate multi tenant data, but single tenancy seems the preference from a risk perspective. If one client is compromised or corrupted, you don't want to affect all your customers.
You can do that quite easily by
Ensuring that your web and business
components are stateless.
Use a common security layer
Switch data context per request
The data context switching is the most complex part, but it could be something as simple as having a per user/role Entity Connection string if you're using EF, or a Partition naming pattern if you're using Table storage.