1

I have seen variations of this question but couldn't find any that dealt with our particular scenario.

We have an existing aps.net website that links to a SQL Server database. The database has clr user-defined types, hence it can only be hosted in Azure VM since Cloud Services don't support said types.

We initially wanted to use a vm for the database and cloud service for the front-end, but then some issues arose:

  1. We use StateServer for storing State, but Azure doesn't support that. We would need to configure either Table storage, SQL Databases, or a Worker role dedicated to State management (a new worker role is an added cost). Table storage wouldn't be ideal due to performance. The other 2 options are preferable but they introduce cost or app-reconfiguration disadvantages.
  2. We use SimpleMembership for user management. We would need to migrate the membership tables from our vm instance sql server to Azure's SQL Databases. This is an inconvenience as we want to keep all our tables in the same database, and splitting up the 2 may require making some code changes.

We are looking for a quick solution to have this app live as soon as possible, and at manageable cost. We are desperately trying to avoid re-factoring our code just to accommodate hosting part of the app in Azure Cloud services.

Questions:

  • Should we just go the VM route for hosting everything?
  • Is there any cost benefit in leveraging a VM instance (for sql server) and a Cloud Service instance (for the front-end)?
  • It seems to me every added "background process" to a Cloud Service will require a new worker role. For example, if we wanted to enable smtp for email services, this would require a new role, and hence more cost. Is this correct?
VividSam
  • 13
  • 4

2 Answers2

0

To run SQL Server with CLR etc, you'll need to run SQL Server in a Virtual Machine.

For the web tier, there are advantages to Cloud Services (web roles), as they are stateless - very easy to scale out/in without worrying about OS setup. And app setup is done through startup scripts upon bootup. If you can host your session content appropriately, the stateless model will be simpler to scale and maintain. However: If you have any type of complex installations to perform that take a while (or manual intervention), then a Virtual Machine may indeed be the better route, since you can build the VM out, and then create a master image from that VM. You'll still have OS and app maintenance issues to contend with, just as you would in an on-premises environment.

Let me correct you on your 3rd bullet regarding background processes. A cloud service's web role (or worker role) instances are merely Windows Server VM's with some scaffolding code for startup and process monitoring. You don't need a separate role for each. Feel free to run your entire app on a single web role and scale out; you'll just be scaling at a very coarse-grain level.

David Makogon
  • 69,407
  • 21
  • 141
  • 189
  • Since we will be hosting SQL server in 2 VMs for high availability anyways, I do not see the incentive to use a web role for the front end. Having 2 VMs and 2 role instances to ensure high-availability will be costly. Please advice on this direction if I am mistaken. Thanks so much. – VividSam Aug 28 '13 at 20:25
0

Some things to consider...

If you want to be cheap, you can have your web/worker role share the same code on a single machine by adding the RoleEntryPoint. Here is a post that actually shows how to do what you are trying to do with sending email: http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx

Session management is painfully slow in SQL Azure DB, I would use the Azure Cache if you can..it is fast.

SQL Server with VMs is going to cause problems for you, because you will also need to create a virtual network between that and any cloud services. This is really stupid, but if you deploy a cloud service AND a VM they communicate over the PUBLIC LOAD BALANCER causing a potential security concern and network latency. So, first you need to virtual network them (that is an extra cost)..then you also need to host a DNS server to address the SQL Server VM. Yes this is really stupid, unless you are OK with your web/worker roles communicating with your SQL Server over the internet :)

EDIT: changed "public internet" to "public load balancer" (and noted latency)

EDIT: The above information is 100% correct contrary to the comment by David below. Please read the guidance from Microsoft here:

http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario

DIRECTLY FROM MICROSOFT GUIDANCE speaking about cross Cloud Service communication (VM->web/worker roles):

"We recommend that you implement the first option as the connection process would not need to go through the public Internet. Therefore, it would provide a better network performance."

As of today (8/29/2013) Azure VMs and Worker/Web Roles are deployed into DIFFERENT "Cloud Services". Therefore communication between them needs to be secured via a Virtual Network that exposes private IP addresses between the instances.

To follow up on David's point below, that about adding an ACL. You are still sending packets over the internet using TDS (SQL Server protocol). That can be encrypted, but no sane architect/enterprise governance/security governance would "allow" this scenario to happen in a production environment.

Bart Czernicki
  • 3,663
  • 1
  • 21
  • 19
  • Your information about a cloud service and VM communicating over the internet and not the azure internal network: untrue. If both are deployed in the same data center, traffic stays within the data center, *even if you use the xxx.cloudapp.net name*. – David Makogon Aug 29 '13 at 01:39
  • Further: You don't necessarily need a virtual network, as you can create an ACL'd endpoint on the SQL VM that's IP whitelisted for just the Cloud Service's VIP. A few simple lines of PowerShell and you're all set. – David Makogon Aug 29 '13 at 01:40
  • @DavidMakogon Wow you are 100% wrong. Please find guidance from Microsoft here: http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario clearly stating: "We recommend that you implement the first option as the connection process would not need to go through the public Internet. Therefore, it would provide a better network performance." – Bart Czernicki Aug 29 '13 at 19:24
  • I don't know why that guidance is written that way. Data is not traveling over the public Internet between two services in the same data center. Same goes for Storage hosted in the same data center: Imagine if that were true, your data disk content would flow over the Internet between storage and compute, since they're in blobs. Further, there's no outbound bandwidth charges for said data transfer, since it doesn't leave the data center ([pricing link](http://www.windowsazure.com/en-us/pricing/details/data-transfers/)) – David Makogon Aug 29 '13 at 20:39
  • @DavidMakogon You are mixing up services..those "distributed services" are auto-magically routed internally. You might want to check out this video from the BUILD 2012 conference (by the guy who architected the IaaS offering): http://channel9.msdn.com/Events/Build/2012/2-011 (starts at 58.5 minute mark) It is "written that way", because that is the guidance and it is less secure (as echoed by the: guidance, Windows Azure Training Kit and the video linked above!) BTW..Feel free to remove the downvote anytime! – Bart Czernicki Aug 29 '13 at 21:37
  • Please re-watch Mark's video, from 1:01:55. To quote Mark, when describing comm between cloud services: "I get a little higher latency because now I'm going through the public **load balancer**." This is *not* the same as going through the public **Internet**. Next quote: "It's a little less secure because now I've got this VIP sitting on the open Internet..." This means the endpoint's port is visible on the public side (which may then blocked with firewall rules, as stated in the video, or using the new ACL feature). Mark *never* mentions traffic going outside the data center. – David Makogon Aug 30 '13 at 02:00
  • @DavidMakogon So how does the DNS address get resolved, does it use a public DNS server? (going through the internet, right?) Also cloud services create a network boundary that prevents things like DDoS which goes through the PUBLIC internet. Even with your ACLs you still are exposing content to the public internet even though the server may not echo/respond back. Private VLAN filtering (part of the Cloud Service network boundary protects). This is the VERY reason Microsoft is working on fixing this. Semantically, I will change my answer (even though MSFT docs say public internet) – Bart Czernicki Aug 30 '13 at 03:04