The content below is taken from the original (Connecting Users to the Azure Cloud), to continue reading please visit the site. Remember to respect the Author & Copyright.

In this article I’m going to discuss the most forgotten aspect of migrating or deploying services into the cloud: Exactly how will the users connect to the services that will be running in Azure?

Wormhole Area Networking

I invented a new form of networking last year to deal with a common problem I am encountering with people who are considering deploying new services or migrating old services to the cloud. Lots of people have tried to hop onto the cloud bandwagon as it has been zooming past them. But when caught in that flash, they fail to account for considerations that they’ve been dealing with for over a decade: If I put the user in Place A and the server in Place B, with a latent network connection between them, then how will the user connect to the service?

What will the client experience be like when accessing a database over an 80 MS connection when you’ve always had less than 1 MS between the thick client application and the server?

And then I realized that these people had been planning to use WHAN … wormhole area networking. Packets would simply dematerialize from the user’s PC and rematerialize on the Azure virtual machine’s virtual NIC. Obviously, this is the way forward, so I *cough* trademarked it. Hey! If Apple can patent rounded icons then I can claim WHAN!

Wormhole Area Networking (WHAN) [Image credit: Aidan Finn]

Let’s get serious. What can you do to connect users? Here are some options to consider, from the traditional to the more cloud-suitable options.

VPN

If you want to consider traditional network connectivity that is tried and trusted, then you can go with VPN. Adding a gateway to an Azure virtual network means that you can get private and secured network connections to Azure virtual machines. There are two options:

• Point-to-site VPN: Users have the ability to VPN onto the Azure network. It’s a simple solution to set up, but users don’t do well with VPN clients, and the solution is limited to 128 connections.
• Site-to-site VPN: Depending on the gateway you configure, you can have between 1 and 30 sites connecting into an Azure network. This means that you can have simple connectivity for users that are in one of your sites. Problems will occur with roaming users.

One of the downsides of VPN is that Microsoft cannot provide an SLA between the outside of your firewall and their data center. Another is that VPN is limited to connecting to Azure virtual networks (virtual machines).

ExpressRoute

Microsoft has partnered with other telecommunications companies to provide SLA-protected private connections between a customer and their Azure subscriptions (not just virtual networks). You can either:

• Add Azure to your MPLS WAN
• Connect to a point-of-presence data center, which in turn connects you to Azure

These plans are limited to a small set of service providers in a small number of markets. ExpressRoute is also very expensive.

Remote Desktop Services (RDS)

With VPN and ExpressRoute, we have a latent connection between the end user and the service. We can throw bandwidth at the problem, but that just means more old applications can have the same bad experience. My favorite method for connecting users to remote services is to use RDS. This is an old technique that:

• Solves the latency issue by moving the client experience to the same place as the services and data.
• Provides easy-to-use connections to services for users – no VPN client to remember thanks to an “SSL” gateway.

There are two ways to do deploy RDS in Azure:

• Deploy RDS for yourself: You’ll have to deal with all the complexities of deploying an RDS farm. (Citrix seems so much easier when scaling out.) In terms of licensing, you will either need RDS CALs with Software Assurance via volume licensing or RDS SALs via SPLA-R licensing.
• Use RemoteApp: I like RemoteApp. It’s the connectivity solution that I recommend the most. It takes RDS and makes it easy. All you need to do is supply RemoteApp with a template of a session host, and RemoteApp does the rest. The per-user cost accounts for all of your RDS virtual machine and licensing costs.

How can I forget Citrix? If you do some searching you will encounter a paper called Deploying XenApp 7.5 on Microsoft Azure Cloud. Interestingly, Citrix also found (as did Microsoft any others) that the Standard A3 virtual machine gave them the sweet spot between performance and price.

Cloud

Modern applications don’t use thick clients anymore. You either use a web browser or an app, and the connectivity between the user and the service is based on HTTP or HTTPS. Any service that is built on HTTP/S is:

• Designed to minimize data transfer between the server and end user. This improves performance and allows for controls over data leakage.
• Designed to scale the way the cloud intends. Sessionless web servers or Azure web application instances can be powered on and off quickly. This simplifies scale-out/in, optimizes consumption based on demand/profit, and allows for easy high availability (to qualify for the Azure SLA).

Summary

When you are considering the cloud as an option, you need to think of more than just virtual machines. You need to consider storage, networking, security, and those annoying people that want to use the services and data. Remember to investigate the workloads that Azure will be hosting, and plan for a suitable way for users to connect to this services.

The post Connecting Users to the Azure Cloud appeared first on Petri.