I currently work with a legacy asp.net web application and one of the requirements going forward is that it be deployable to windows azure.
I would like to know how difficult it will be to manage deployment to both Azure and a traditional IIS web server.
Azure seems to require a specific customized version of a web applicaiton project is it possible to deploy the customized web application to a standard IIS instance once it has been converted.
EDIT:
It is a ASP.NET Web Application rather than a Web Site (compiles everything into one dll)
UPDATE:
In the end due to the amount of work involved in converting the application to work in Azure and the cost of Azure compared with other cloud solutions it was decided to go with a traditional Cloud hosted virtual server.
And thank you for the really good answers.
Whether or not you can deploy your application to Azure almost as is depends a lot on how your application works. Azure pretty much requires your application be stateless. If it's a plain vanilla web application that stores data in the session or application cache only and saves data to a database only, then you can deploy it to Azure.
If you have stateful services running like background threads (which is bad anyways), or if you save data to the file system (besides temporary caching), then you may have issues. Really, the issues moving to Azure are really the same as moving to any multi-server load balanced solution. One caveat is permanent storage.
If you need to store data in a place other than the database, then you're best off working with Azure's storage solution which has an API and client library for storing binary data, key/value data (they call it tables, but really, it's not tables), and queues. They also do have a transparent blob-as-file-system option for compatibility. If you want to use these in your app that also is used outside of Azure then you need to write an extra layer between your code and the Azure client library that supports both Azure services and standard local service. Azure SDK does include emulators for Azure services, but they're definitely not meant for production use.
As far as the mechanics of Azure-specific projects, that is actually not that difficult. Yes, you need to create an Azure-specific project in your solution that defines the Web Role and what gets deployed, but it will reference your existing Web Application, not the other way around. You can deploy the Azure Web Role to Azure or you can continue to deploy the existing application to IIS normally and concurrently.
Web Site, Web Application, MVC, really doesn't make much of a difference. Actually doesn't have to be .NET either. Can be PHP or Java or whatever you want to put on your VM. It'll all work the same as far as Azure is concerned.
MS likes to push Azure as a Platform-as-a-Service (Paas) solution where they have a ton of services they offer and you run apps on their standard platform, and contrasts that with Amazon AWS which they call Infrastructure-as-a-Service (Iaas) which is "just" a Virtual Machine. However, MS is really just as much a IaaS solution as AWS, perhaps even more so. The only difference between AWS and Azure is AWS allows you to choose what to install on your VM and with Azure you have to use Windows Server 2008 R2 as the basis for your VM (but you can customize the VM image to install custom software on top of windows). With both Azure and AWS, the hosts offer additional PaaS services you can take advantage of for data storage and message routing. AWS also offers tons of extra services like video streaming.
Also note that with Azure (and AWS I think) you can use the services they offer even in a non-hosted application. If you want to use Azure's data storage from a non-Azure application, you can do that, it's just HTTP REST calls to get/put data. The only differences you pay for data in/out between datacenter and your non-datacenter-hosted application which would be free if the app was also inside the datacenter (just the data in/out is free in-datacenter, you still have storage and transaction fees).
A few things:
Samuel Neff's answer mentioned mounting a file system in a blob (a Cloud Drive). Only one instance may lock this cloud drive for writing, so it does not behave like a network file share. You'll need to plan for this.
You'll need to integrate with the Windows Azure diagnostics subsystem, to gain visibility into your app's run state (e.g. performance counters, trace logs, etc.).
If there are 3rd-party apps that your web app depends on, you'll need to install these. These actually get installed as part of the role instance's boot process, either via your OnStart() event handler or as a startup task. The latter allows for admin-level installs (including registry changes, COM component installations, etc.). You'll need to carefully manage these installations, as they impact the boot time of the instance.
For an asp.net app, you'll need to think about session state. In-proc session state won't work, because each instance will have its own state store in memory. The SQL Azure session state provider doesn't have background cleanup agents, so you'll need to build this into your web or worker role instance (see this blog post by the SQL Azure team for the implementation). The best option is to use the AppFabric Cache, a new service that just went into production. This cache-as-a-service provides an custom session state provider for asp.net as well. Note: As of today, the AppFabric Cache service is only accessible via a .NET interface; there's no REST interface for it (all other storage services - tables, blobs, queues - have a REST interface). .NET, Java, and PHP all have storage client libraries. Ruby has one from the open source community.
You'll have to manage scaling out to more than one instance, when the need arises. This is not a built-in service today, but there are 3rd-party services such as ParaLeap's AzureWatch. There's also Microsoft's System Center Operations Manager, which now has Windows Azure monitoring support. You'll also need to handle scale-back situations, where you reduce the number of server instances.
I have some additional details in an answer for a similar StackOverflow question, here.
I have not tried Windows Azure Migration Scanner personally, but if it works as advertised, this would really come in handy.
Related
We have multiple clients and we use Azure web sites to host our web application. When we upgrade a client to a newer version of our software we have to upgrade all of our clients to the latest version.
We would like to be able to upgrade a subset of clients when we release a new version. This would give us the ability to test that the new solution is working properly before we bring all of our clients to the new version. We would like to offer a beta version option to selected clients so that they can access new features of our software and are aware that the version they are using is still in a 'beta' mode.
When we deploy a new version we would like to create a web site just for this new version whilst leaving the other clients on the more stable previous version. To do this we are thinking of writing a reverse proxy that directs traffic to the different versioned web sites depending on the client.
Can we host multiple versions of the web site using the same Azure web site. (IIS directories) The documentation I have read relating to this does not mention being able to build multiple versions of the web site based on different code bases.
Is there a way to set up the build so that each new version is deployed to a directory on the Azure same web site so we can effectively host multiple versions of our app under the same azure web site?
We could do every versioned build to a new Azure web site but this could get quite expensive as we run two instances so as to maintain a good SLA. It is feasible that we could end up with ten versions in the wild at once, running 20 Azure web sites to support these versions could get expensive. How can we save on costs and give our clients a good experience?
You can have up to 5 deployment slots including production on azure web apps. Each slot can use a different branch of your source control system like git or tfs. If you use any of these two, deploy is also automatic (continuous deployment) and you can swap slots any time very fast with minimium to none downtime. Each slot has it's own url for external access.
To save costs, you can run multiple web apps on the same hosting plan. There's no limit for the number of web apps running on the same hosting plan. For each hosting plan it's possible to have 10 small/medium/large instances.
Set up staging environments for web apps in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Azure App Service plans in-depth overview
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
Yes this is possible. In management portal, You need to configure the details for the IIS virtual directory or application in the website’s configuration.
Ref - http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx
I'm completely new on Azure, I have a aspx.net site that talks to a MySQL db, I would like to run both, site and db on Azure, what would be the bext way to do so? Thanks
There are a number of options here depending on the load and bandwidth you expect, what kind of service level agreement you need, the amount of control you want over the application, etc. Let me start by saying you can try all these options out - free - for 90 days with a trial account.
The easiest (and cheapest) entry point would be Windows Azure Web Sites Depending on your bandwidth requirements, you could actually run this completely free (along with a MySQL DB on Azure for a year). Web Sites are shared infrastructure, though there is a higher tier (reserved) which can give you a more consistent availability and throughput. At this time, Web Sites are in a preview mode, so there is no SLA. For a walkthrough see this tutorial.
Via Windows Azure Cloud Services (Platform-as-a-Service) you could deploy your ASP.NET site to a Web Role and use the ClearDB offering (their free offering is what you get as part of Web Sites above). Cloud Services give you a lot more flexibility to scale your application and couple it with other enterprise-grade services in the cloud, and it's covered by a 99.95 SLA. You are charged an hourly rate depending on the configuration and number of virtual machines running your app. With Cloud Services, you'd use Visual Studio and simply deploy your application as a Cloud Service - the management of the underlying resources (virtual machines, etc.) is handled for you by Windows Azure - hence "Platform-as-a-Service"
Lastly there's the newly released Virtual Machines option (Infrastructure-as-a-Service) where you take complete control of the VM that hosts your application. Unlike, Cloud Services you own your VM, so it's up to you to apply operating system patches, install your application and any other ancillary software, and apply any necessary configuration steps. It's a lot of power with a lot of responsibility. In general, I'd only consider Virtual Machines for your scenario if there's a specific technical reason Cloud Services won't work. For the MySQL side, you could also use a Virtual Machine to run MySQL on your own, but again you would own the administration of that service, have to apply patches, clear logs, etc.
I have an existing ASP.NET website that I would like to port to Azure within my free trial.
I would like the migration to be as painless as possible. The application uses log4net and NHibernate, plus it needs to share data with an application supposed to run on a virtual server.
Two questions can be asked as 1
How do I configure paths in Web.config to access a shared drive?
I need to configure the paths into which logs will be stored and, most important, I have to specify where the application will read the files written by the daemon that will run on my Azure Linux VM.
When both the app and the daemon ran on the same server (yes, I had Mono running fine) I just had to choose a shared local directory.
I'm not sure I'm totally understanding the scenario, but I'll try to give you a few options.
One - Windows Azure Web Sites (currently in Preview) could be a great option for your ASP.NET site. Of course, it depends what needs your site has. But, you can write your log4net files with web site and using NHibernate too.
Two - Web roles work great for situations like this. You would likely have to change some code to use blob storage for persistant file storage. You could use Windows Azure drives as a way to get a persistent location for log files. Windows Azure drives don't have a pre-determined drive letter, so you'd want to use the API to get to that. That may, or may not, be a good option for your situation. With web roles you could also write the log4net files to local storage and use Windows Azure diagnostics to transfer them periodically to blob storage. Just another way to persist the files.
Three - Using Windows Azure Virtual Machines (currently in Preview) you could write the log files to a data disk, which is backed by blob storage.
In the end, if you have files you need to share across instances and/or roles, then leveraging blob storage is likely your best option.
I've created an Azure server instance. I've deployed a simple application to it. As part of the deployment process I enabled Remote Desktop Connections.
I have some standard ASP.net applications that run on Windows, is there something to stop me deploying these applications manually to IIS using Remote Desktop. I've read so much about having to migrate standard ASP.net apps to Azure. I don't want to this as we will have customers who will still use Windows Server 2003/2008 so I don't want to have to maintain 2 versions.
Well, as I understand it, in theory you could deploy stuff using remote desktop. But when the instance shuts down/restarts you'll lose it all (unless you've built it into your startup scripts) and have to re-load everything each time. The main reason they suggest you have at least two instances is so that when one shuts down for updates etc there is always at least one other running.
The "Windows Azure Accelerator for Web Roles" project allows you to create an Azure web role which then enables you to use web deploy for all your other web sites - I'm guessing that will be a whole lot better approach and is definitely worth a look. Also, I believe smarx.com is a good place to browse for info and ideas.
Using a startup task and the Azure Bootstrapper you can download, unzip, install almost any kind of 3rd party software that supports either xcopy deployment (just copy the files) or an unattended(silent) install.
Assuming you aren't using Azure storage or anything like that, there shouldn't be any difference with the IIS application. If you are using anything specific to Azure, you can use the RoleEnvironment.IsAvailable to test if you are running inside Azure or not. That will return true for the emulator as well. If you want to use Azure storage from both, you can add the settings in the web.config to use if not running in Azure.
Im looking at writing a application for a web 2.0 start up site which will essential monitor specific RSS feeds.
Due to the expected up take of such a service I am expecting that taking advantage of cloud computing would be the way to do it, however with my lack of experience I do not know if it is possible to run a Windows service in the cloud.
There will be a web front end to this but it isn't imagined that that will have a heavy load as it will be just for sign up, then users will recevie notifications by SMS/Email
You can run a "service" in the cloud, when using Azure. It's called a "Worker Role" see the Architecture here.
If you're looking at running Windows Azure (which splits into a web role and worker role).
You'll have to sign up for an Azure key (The Bizspark pack includes one I believe) to get started, download the SDK and Azure tools.
It looks like you would only really need the web role for this, in which case it's just a normal ASP.NET / MVC site that you'd write as normal.
Essentially the benefit you'd get here would be being able to ramp up the number of server instances running your application by tweaking the config file.
The other option is the Amazon EC2 Cloud which allows you to instantiate as many instances of Windows2k3 Data Centre edition as you need. I run Windows Services, IIS, Postgresql etc. on such an instance with no issues.
Managed to find this link to publishing WCF services in the cloud. Im new to WCF so not sure if it will offer the solution I require, it probably will but I need to do some more research
Link