Related
What are the material differences between the new Azure Web Sites and the traditional Azure Web Roles for an ASP.NET MVC application? What reason would I choose a "web site" over a "web role" or vice versa?
Let's assume that I would need equal capacity in either case (e.g. 2 small instances). The prices seem comparable other than the fact that there is a 33% temporary discount for web sites while they are in their preview period.
Are there things that I can do with a "web site" that are difficulty or impossible with a web role? For example, does it become easy to put multiple web sites in a single set of VMs using "web sites"? Do I lose anything with a "web site" vs a "web role"? Ability to fine tune IIS? Ability to use the Cache service locally?
Web Roles give you several features beyond Web Apps (formerly Web Sites):
Ability to run elevated startup scripts to install apps, modify registry settings, install performance counters, fine-tune IIS, etc.
Ability to split an app up into tiers (maybe Web Role for front end, Worker Role for backend processing) and scale independently
Ability to RDP into your VM for debugging purposes
Network isolation
Dedicated virtual IP address, which allows web role instances in a cloud service to access IP-restricted Virtual Machines
ACL-restricted endpoints (added in Azure SDK 2.3, April 2014)
Support for any TCP/UDP ports (Web Sites are restricted to TCP 80/443)
Web Apps have advantages over Web Roles though:
Near-instant deployment with deployment history / rollbacks
Visual Studio Online, github, local git, ftp, CodePlex, DropBox, BitBucket deployment support
Ability to roll out one of numerous CMS's and frameworks, (like WordPress, Joomla, Django, MediaWiki, etc.)
Use of SQL Database or MySQL
Simple and fast to scale from free tier to shared tier to dedicated tier
Web Jobs
Backups of Web Site content
Built-in web-based debugging tools (simple cmd/powershell debug console, process explorer, diagnostic tools like log streaming, etc.)
With the April 2014 and September 2014 rollouts, there are now some features common to both Web Apps and Web Roles (and Worker Roles), including:
Staging+production slots
Wildcard DNS, SSL certificates
Visual Studio integration
Traffic Manager support
Virtual Network support
Here's a screengrab I took from the Web Sites gallery selection form:
I think Web Apps are a great way to get up and running quickly, where you can move from shared to reserved resources. Once you outgrow this, you can then move up to Web Roles and expand as you need.
EDIT 2014: For what it's worth, a lot of the info in this answer is no longer correct - see comments.
Add more to #David response:
With Windows Azure Websites, you don't have control over IIS or web Server because you are using a resources slice along with hundreds of other website on the same machine, you are sharing resources like any other so there is no control over IIS.
The big difference between a website shared and Azure web role is that a web-site is considered process bound while roles are VM bound.
Websites are stored on a content share which is accessible from all the "web servers" in the farm so there is no replication or anything like that required.
Windows Azure websites can not have their own host name instead they must use websitename.azurewebsites.net only and you sure can use CNAME setting in your DNS provider to route your request exactly same with previous Windows Azure Role only when they are running in reserved mode. CNAME setting is not supported for shared websites.
I've just posted a comprehensive blog post on this very subject at http://robdmoore.id.au/blog/2012/06/09/windows-azure-web-sites-vs-web-roles/.
An excerpt from my conclusion: If you need enormous scale, SSL, Asian or West US data centres, a non-standard configuration (of IIS, ports, diagnostics, security certs or start up scripts), RDP or cost-effective Worker Roles (combined with your Web Role) then you are going to have to stick to Web Roles for now.
Otherwise, Web Sites is a great option!
Azure Web Role is like a virtual private host. You get a VM that acts as your web server, and you own that VM instance.
Azure Web Sites are like an elastic shared hosting service. You deploy your app to a web server that is not controlled by you and which also servers other users' sites. You can scale your site up and down (at some extra charge) to make it more elastic as your resource needs shift.
There is one more scenario that is up the air: After these 500 exceptions are eliminated, they haven't said anything about the ability of Azure Websites to handle wildcard CNAME's. Several of us are using Nate's Web Role Accelerator in Cloud Services, becuase a one-line hack provided wildcard subdomain capability in Nate's software. We can't move these wildcard subdomain apps until we know that Azure Websites will be able to handle them. If it won't ever be able to do that, then it goes down as a positive on the Web Role side of the equation. Also of note is that with pricing being exactly the same (after the preview discount expires), I'm not sure I want to give up my access to RDC and Event Viewer (just to mention two things).
Azure Web Sites enables you to build highly scalable web sites quickly on Azure. You can use the Azure Portal or the command-line tools to set up a web site with popular languages such as .NET, PHP, Node.js, and Python. Supported frameworks are already deployed and do not require more installation steps. The Azure Web Sites gallery contains many third-party applications, such as Drupal and WordPress as well as development frameworks such as Django and CakePHP. After creating a site, you can either migrate an existing web site or build a completely new web site. Web Sites eliminates the need to manage the physical hardware, and it also provides several scaling options. You can move from a shared multi-tenant model to a standard mode where dedicated machines service incoming traffic. Web Sites also enable you to integrate with other Azure services, such as SQL Database, Service Bus, and Storage. Using the Azure WebJobs SDK preview, you can add background processing. In summary, Azure Web Sites make it easier to focus on application development by supporting a wide range of languages, open source applications, and deployment methodologies (FTP, Git, Web Deploy, or TFS). If you don’t have specialized requirements that require Cloud Services or Virtual Machines, an Azure Web Site is most likely the best choice.
Cloud Services enable you to create highly-available, scalable web applications in a rich Platform as a Service (PaaS) environment. Unlike Web Sites, a cloud service is created first in a development environment, such as Visual Studio, before being deployed to Azure. Frameworks, such as PHP, require custom deployment steps or tasks that install the framework on role startup. The main advantage of Cloud Services is the ability to support more complex multitier architectures. A single cloud service could consist of a frontend web role and one or more worker roles. Each tier can be scaled independently. There is also an increased level of control over your web application infrastructure. For example, you can remote desktop onto the machines that are running the role instances. You can also script more advanced IIS and machine configuration changes that run at role startup, including tasks that require administrator control.
Virtual Machines enable you to run web applications on virtual machines in Azure. This capability is also known as Infrastructure as a Service (IaaS). Create new Windows Server or Linux machines through the portal, or upload an existing virtual machine image. Virtual Machines give you the most control over the operating system, configuration, and installed software and services. This is a good option for quickly migrating complex on-premises web applications to the cloud, because the machines can be moved as a whole. With Virtual Networks, you can also connect these virtual machines to on-premises corporate networks. As with Cloud Services, you have remote access to these machines and the ability to perform configuration changes at the administrative level. However, unlike Web Sites and Cloud Services, you must manage your virtual machine images and application architecture completely at the infrastructure level. One basic example is that you have to apply your own patches to the operating system.
See updated and comprehensive comparison from this link: http://azure.microsoft.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/
Azure Websites, Web Workers and Virtual Machines are three different computing approaches available on Windows Azure. They differ in the level of control and responsibilities:
Azure Website have lowest level of control, but you don't care about keeping in health virtual machine and IIS, because Azure stuff do this for you
Web Roles give you more control (traffic manager, remote desktop), but more administration is possible on your side which means that you can break something via remote desktop for example
Virtual Machines gives you full control of VM, so require the most administration efforts.
There is no one best choice, because it depends on what level of control you need, what features you need and what you want to leave Azure stuff to maintain. And it is big topic..
Please look at this articles for more information to make more informed choice:
http://www.windowsazure.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/
http://davidpallmann.blogspot.com/2012/06/reintroducing-windows-azure-part-2.html
It boils down to tradeoff between ease of use and capabilities.
Two more things I found was cost of getting SSL for a custom domain site and Multi-tenant configurations.
For website you need to pay monthly on top of standard instance (Small instance is the cheapest option). This means in order to get custom domain https would cost you ~70/month for small instance plus ~41/ month for SSL that supports all browser.
For WebRole you can get XS instance and add your own SSL for free, which means ~$15 per month
and you have a custom domain with SSL.
For multi-tenant website check out
Multi-tenant Azure dynamic wildcard CName
A web role is a virtual machine that hosts multiple websites
This is a common question, and I would like to give out an excerpt from msdn.
Access to services like Caching, Service Bus, Storage, SQL Azure Database- WebSite:Yes WebRole:Yes
Support for ASP.NET, classic ASP, Node.js, PHP- WebSite: Yes WebRole:Yes
Shared content and configuration- WebSite:Yes WebRole:No
Deploy code with GIT, FTP- WebSite:Yes WebRole:No
Near-instant deployment-WebSite:Yes WebRole:No
Integrated MySQL-as-a-service support-WebSite:Yes WebRole:Yes
Multiple deployment environments (production and staging)-WebSite:No WebRole:Yes
Network isolation-WebSite:No WebRole:Yes
Remote desktop access to servers-WebSite:No WebRole:Yes
Ability to run programs with elevated permissions-WebSite:No WebRole:Yes
Ability to define/execute start-up tasks-WebSite:No WebRole:Yes
Ability to use unsupported frameworks or libraries-WebSite:No WebRole:Yes
Support for Windows Azure Connect/ Windows Azure Network-WebSite:No WebRole:Yes
To get a more in detail, visit this link: http://blogs.msdn.com/b/silverlining/archive/2012/06/27/windows-azure-websites-web-roles-and-vms-when-to-use-which.aspx
I'm looking to set up two web roles or websites on my Azure Cloud Service.
The websites need to share the same database schema. I use NHibernate ORM, so I have to make sure that both projects are always using the same data model, or else it will cause major problems.
I've researched setting up multiple websites on a single web role (which seems odd to me, can't I just run multiple web roles, each with a single site)?
http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx
Like any good developer, I use a staging server. If I have to manually set the domain name is configuration files, how will azure know not to be sending people who visit that domain to the staging server?! I.E. If they visit blah.foo.com and I have two deployments (staging and production), is IIS going to be able to know only to send people to the production environment?
Please advise on the best way to go about doing this.
First, you can certainly have multiple web roles, each with a single site; however, each role instance will be deployed to different virtual machines. For example, if you do set up two web roles when you deploy this with one instance each then there are two virtual machines you'll be paying for. If you want the SLA to apply to your deployment you'd need to actually set the instance count to 2 for each web role, which now means you have four virtual machines running. By combining web sites onto the same web role you'll cut down on the number of instances you need to run and still get the SLA; however, that option is not without some considersations. The link you provided is how you can set up multiple websites to run on the same virtual machine when deployed. Note that there are some gotchas with using that method. I'd suggest reading Michael Collier's Tips for Publishing Multiple Sites in a Web Role.
Second, if you do NOT need to have a lot of control over the virtual machine (such as registering special components, etc.) you might want to look at Windows Azure Web Sites as an option. You can elect to take one of the paid levels of Web Sites and still have dedicated machines, but you can deploy the websites separately. I will say though, that your requirement of having both sites in lock step because they share the underlying database schema means that it will be less likely you will want to deploy separate changes, but it is still possible.
Finally, regarding the staging server. If you are testing locally you'll want to modify your hosts file to get the host names to point to your local address. Wade Wegner has a post on Running Multiple Websites in a Windows Azure Web Role. Once you deploy to Windows Azure you'd want to change your hosts file back, or comment them out. If you are using the actual idea of the Staging deployment slot you can use the same trick with the hosts file to point to the IP address of the staging deployment when testing.
I am new to Azure and website deployment, and I am trying to make sure I understand how things work. As far as I understand, once I create a website, a web application is created and begins to run in the cloud before publishing my own site even.
I know that the cloud provides scalability, load-balancing (among multiple datacenters), ease of publishing/testing, etc...things that don't exist in traditional web hosting.
So my question is since my website is in the cloud/Azure now, would my website be replicated globally in MS datacenters? If yes, is it something different from load-balancing? in other words, is the idea behind it is to get my site replicated to provide faster access from all over the world. And if all these are correct, I suppose traditional web hosting doesn't support replication.
Sorry for the simple questions, but I really need to understand, and I would appreciate any details you could provide.
Q: So my question is since my website is in the cloud/Azure now, would my website be replicated globally in MS datacenters?
A: Your website won't be automatically replicated globally to all MS datacenters. Each azure service, whether it is an cloud-service, sql-azure, storage, website or VM is located at a location of your choice. Within a location you can scale some of the services to run in multiple instances. If you spawn a new instance your website gets replicated. But it still runs at the same geo-location.
Q: If yes, is it something different from load-balancing?
A: In Azure you need to distinguish between load-balancing and traffic-management. If you run multiple instances within one location, there is only one external URL to reach it. The load-balancer distributes traffic equally to every running service instance.
The Traffic Manager allows you to control the distribution of user traffic to Windows Azure hosted services. The hosted services can be running in the same data center or in different centers across the world. Traffic Manager works by applying an policy engine to the Domain Name Service (DNS) queries on your domain name(s).
So in general, if you want to spread your application all over the world, you have to do it by yourself.
Create your service on all the location of your choice and use Traffic Manager to connect them.
I'm looking at Azure Reserved Web Sites as an option for ASP.NET application hosting. But I couldn't find information about the following two aspects:
Is the Reserved instance size/resources (e.g. Medium VM, 2 x 1.6GHz CPU, 3.5GB RAM) shared with the instance OS and OS services, just like a VM? Or is this a dedicated computing capacity excluding the OS?
In a blog post (http://weblogs.asp.net/scottgu/archive/2012/09/17/announcing-great-improvements-to-windows-azure-web-sites.aspx) Scott Guthrie mentioned about running multiple sites in a single Reserved instance (much like a VM but without fully-managed), but it's not clear to me as to how multiple sites (with different domains names) are setup/configured in Reserved instances from the Management Tool:
you could run a single site within a reserved instance VM or 100 web-sites within it for the same cost
Any clarification is appreciated.
Just like a VM, it will be shared with instance OS and OS services.
For hosting multiple web sites in reserved instance...read here...Is it possible to have multiple azure web sites running off a single reserved instance
also.
and How to configure multiple host headers for one Azure WebSite reserved instance
You can also read more about host headers in Microsoft documentation.
In order to run multiple web sites on a single server go to your azure management portal. Pick a web site you would like to scale to a standard server. You will see the list of all your web sites deployed to azure. You can pick the ones you want to be deployed to your standard server instance together.
See screenshot below from the management portal.
What are the material differences between the new Azure Web Sites and the traditional Azure Web Roles for an ASP.NET MVC application? What reason would I choose a "web site" over a "web role" or vice versa?
Let's assume that I would need equal capacity in either case (e.g. 2 small instances). The prices seem comparable other than the fact that there is a 33% temporary discount for web sites while they are in their preview period.
Are there things that I can do with a "web site" that are difficulty or impossible with a web role? For example, does it become easy to put multiple web sites in a single set of VMs using "web sites"? Do I lose anything with a "web site" vs a "web role"? Ability to fine tune IIS? Ability to use the Cache service locally?
Web Roles give you several features beyond Web Apps (formerly Web Sites):
Ability to run elevated startup scripts to install apps, modify registry settings, install performance counters, fine-tune IIS, etc.
Ability to split an app up into tiers (maybe Web Role for front end, Worker Role for backend processing) and scale independently
Ability to RDP into your VM for debugging purposes
Network isolation
Dedicated virtual IP address, which allows web role instances in a cloud service to access IP-restricted Virtual Machines
ACL-restricted endpoints (added in Azure SDK 2.3, April 2014)
Support for any TCP/UDP ports (Web Sites are restricted to TCP 80/443)
Web Apps have advantages over Web Roles though:
Near-instant deployment with deployment history / rollbacks
Visual Studio Online, github, local git, ftp, CodePlex, DropBox, BitBucket deployment support
Ability to roll out one of numerous CMS's and frameworks, (like WordPress, Joomla, Django, MediaWiki, etc.)
Use of SQL Database or MySQL
Simple and fast to scale from free tier to shared tier to dedicated tier
Web Jobs
Backups of Web Site content
Built-in web-based debugging tools (simple cmd/powershell debug console, process explorer, diagnostic tools like log streaming, etc.)
With the April 2014 and September 2014 rollouts, there are now some features common to both Web Apps and Web Roles (and Worker Roles), including:
Staging+production slots
Wildcard DNS, SSL certificates
Visual Studio integration
Traffic Manager support
Virtual Network support
Here's a screengrab I took from the Web Sites gallery selection form:
I think Web Apps are a great way to get up and running quickly, where you can move from shared to reserved resources. Once you outgrow this, you can then move up to Web Roles and expand as you need.
EDIT 2014: For what it's worth, a lot of the info in this answer is no longer correct - see comments.
Add more to #David response:
With Windows Azure Websites, you don't have control over IIS or web Server because you are using a resources slice along with hundreds of other website on the same machine, you are sharing resources like any other so there is no control over IIS.
The big difference between a website shared and Azure web role is that a web-site is considered process bound while roles are VM bound.
Websites are stored on a content share which is accessible from all the "web servers" in the farm so there is no replication or anything like that required.
Windows Azure websites can not have their own host name instead they must use websitename.azurewebsites.net only and you sure can use CNAME setting in your DNS provider to route your request exactly same with previous Windows Azure Role only when they are running in reserved mode. CNAME setting is not supported for shared websites.
I've just posted a comprehensive blog post on this very subject at http://robdmoore.id.au/blog/2012/06/09/windows-azure-web-sites-vs-web-roles/.
An excerpt from my conclusion: If you need enormous scale, SSL, Asian or West US data centres, a non-standard configuration (of IIS, ports, diagnostics, security certs or start up scripts), RDP or cost-effective Worker Roles (combined with your Web Role) then you are going to have to stick to Web Roles for now.
Otherwise, Web Sites is a great option!
Azure Web Role is like a virtual private host. You get a VM that acts as your web server, and you own that VM instance.
Azure Web Sites are like an elastic shared hosting service. You deploy your app to a web server that is not controlled by you and which also servers other users' sites. You can scale your site up and down (at some extra charge) to make it more elastic as your resource needs shift.
There is one more scenario that is up the air: After these 500 exceptions are eliminated, they haven't said anything about the ability of Azure Websites to handle wildcard CNAME's. Several of us are using Nate's Web Role Accelerator in Cloud Services, becuase a one-line hack provided wildcard subdomain capability in Nate's software. We can't move these wildcard subdomain apps until we know that Azure Websites will be able to handle them. If it won't ever be able to do that, then it goes down as a positive on the Web Role side of the equation. Also of note is that with pricing being exactly the same (after the preview discount expires), I'm not sure I want to give up my access to RDC and Event Viewer (just to mention two things).
Azure Web Sites enables you to build highly scalable web sites quickly on Azure. You can use the Azure Portal or the command-line tools to set up a web site with popular languages such as .NET, PHP, Node.js, and Python. Supported frameworks are already deployed and do not require more installation steps. The Azure Web Sites gallery contains many third-party applications, such as Drupal and WordPress as well as development frameworks such as Django and CakePHP. After creating a site, you can either migrate an existing web site or build a completely new web site. Web Sites eliminates the need to manage the physical hardware, and it also provides several scaling options. You can move from a shared multi-tenant model to a standard mode where dedicated machines service incoming traffic. Web Sites also enable you to integrate with other Azure services, such as SQL Database, Service Bus, and Storage. Using the Azure WebJobs SDK preview, you can add background processing. In summary, Azure Web Sites make it easier to focus on application development by supporting a wide range of languages, open source applications, and deployment methodologies (FTP, Git, Web Deploy, or TFS). If you don’t have specialized requirements that require Cloud Services or Virtual Machines, an Azure Web Site is most likely the best choice.
Cloud Services enable you to create highly-available, scalable web applications in a rich Platform as a Service (PaaS) environment. Unlike Web Sites, a cloud service is created first in a development environment, such as Visual Studio, before being deployed to Azure. Frameworks, such as PHP, require custom deployment steps or tasks that install the framework on role startup. The main advantage of Cloud Services is the ability to support more complex multitier architectures. A single cloud service could consist of a frontend web role and one or more worker roles. Each tier can be scaled independently. There is also an increased level of control over your web application infrastructure. For example, you can remote desktop onto the machines that are running the role instances. You can also script more advanced IIS and machine configuration changes that run at role startup, including tasks that require administrator control.
Virtual Machines enable you to run web applications on virtual machines in Azure. This capability is also known as Infrastructure as a Service (IaaS). Create new Windows Server or Linux machines through the portal, or upload an existing virtual machine image. Virtual Machines give you the most control over the operating system, configuration, and installed software and services. This is a good option for quickly migrating complex on-premises web applications to the cloud, because the machines can be moved as a whole. With Virtual Networks, you can also connect these virtual machines to on-premises corporate networks. As with Cloud Services, you have remote access to these machines and the ability to perform configuration changes at the administrative level. However, unlike Web Sites and Cloud Services, you must manage your virtual machine images and application architecture completely at the infrastructure level. One basic example is that you have to apply your own patches to the operating system.
See updated and comprehensive comparison from this link: http://azure.microsoft.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/
Azure Websites, Web Workers and Virtual Machines are three different computing approaches available on Windows Azure. They differ in the level of control and responsibilities:
Azure Website have lowest level of control, but you don't care about keeping in health virtual machine and IIS, because Azure stuff do this for you
Web Roles give you more control (traffic manager, remote desktop), but more administration is possible on your side which means that you can break something via remote desktop for example
Virtual Machines gives you full control of VM, so require the most administration efforts.
There is no one best choice, because it depends on what level of control you need, what features you need and what you want to leave Azure stuff to maintain. And it is big topic..
Please look at this articles for more information to make more informed choice:
http://www.windowsazure.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/
http://davidpallmann.blogspot.com/2012/06/reintroducing-windows-azure-part-2.html
It boils down to tradeoff between ease of use and capabilities.
Two more things I found was cost of getting SSL for a custom domain site and Multi-tenant configurations.
For website you need to pay monthly on top of standard instance (Small instance is the cheapest option). This means in order to get custom domain https would cost you ~70/month for small instance plus ~41/ month for SSL that supports all browser.
For WebRole you can get XS instance and add your own SSL for free, which means ~$15 per month
and you have a custom domain with SSL.
For multi-tenant website check out
Multi-tenant Azure dynamic wildcard CName
A web role is a virtual machine that hosts multiple websites
This is a common question, and I would like to give out an excerpt from msdn.
Access to services like Caching, Service Bus, Storage, SQL Azure Database- WebSite:Yes WebRole:Yes
Support for ASP.NET, classic ASP, Node.js, PHP- WebSite: Yes WebRole:Yes
Shared content and configuration- WebSite:Yes WebRole:No
Deploy code with GIT, FTP- WebSite:Yes WebRole:No
Near-instant deployment-WebSite:Yes WebRole:No
Integrated MySQL-as-a-service support-WebSite:Yes WebRole:Yes
Multiple deployment environments (production and staging)-WebSite:No WebRole:Yes
Network isolation-WebSite:No WebRole:Yes
Remote desktop access to servers-WebSite:No WebRole:Yes
Ability to run programs with elevated permissions-WebSite:No WebRole:Yes
Ability to define/execute start-up tasks-WebSite:No WebRole:Yes
Ability to use unsupported frameworks or libraries-WebSite:No WebRole:Yes
Support for Windows Azure Connect/ Windows Azure Network-WebSite:No WebRole:Yes
To get a more in detail, visit this link: http://blogs.msdn.com/b/silverlining/archive/2012/06/27/windows-azure-websites-web-roles-and-vms-when-to-use-which.aspx