Networking and Service Bus RRS feed

  • General discussion

  • This discussion is to ask questions and get answer about the various aspects of Windows Azure Networking and Service Bus. This includes, Azure Networks, Service Bus, Azure Connect, connecting between on-premises and cloud, and other networking considerations.  Feel free to ask your questions, make suggestions and chat in general. Try to keep things in the right topics though so we can keep things in the right train of thought.
    Thursday, February 28, 2013 1:44 AM

All replies

  • Can someone explain how to set up a Hybrid Application using Azure Networking?

    Thursday, February 28, 2013 4:20 AM
  • Funny you asked Rocky,

    Azure Networking allows you to connect your on premise network/servers to your Azure footprint through -

    typically a VPN IPSEC connection. This is configured at both ends to route traffic on certain network ranges (CIDR based). e.g. (Azure) <-> on prem.

    So when deploying new services/VMs into the cloud, if you assign them within that network range on your 'virtual network setup' then they'll be able to talk back to the organisation as if they were just one of the machines.

    There's a bunch of other capabilities within Virtual Networks - such as isolating your cloud deployment, which maybe great for a load test scenario where you want to test in peace and not be concerned of other Azure Services/servers within the same Azure footprint.

    Azure Connect - is specially designed for 'point to point' style communications, where you'd like to connect a single (or maybe a couple) machine to Services/Servers running in Azure. Example would be a local on-prem SQL Server holding the secret lotto winning formula. You'd like to query it, but not relocate it.

    Both of these technologies are protocol agnostic, and you for e.g. could talk to FTP servers/mail and so on.


    So your Hybrid application in this setup would typically know nothing of the underlying components and to the Solution Designers/Architects & even builders, this would be a solution that simply involves a distributed environment of services and other scalable endpoints. (Azure just fits in nicely)

    In scenario #2 - where there is *no* underlying Azure connectivity, the Hybrid app would need to know more about the Azure deployment, URLs, credentials etc.

    In these cases we typically deploy:

    1) Azure Service Bus - allowing the Application to talk to Azure & expose it's own functionality through Azure as WCF endpoints. Azure will re-broadcast out each WCF endpoint the Hybrid app wants to expose.

    Here the app now has all the benefits of Azure/Scale/Resilience etc. while staying relatively unchanged.

    Here the App needs to be up and running for the Azure endpoints to be active. If the app shuts down so too do the endpoints (we can have up to 25 instances of the 'app' publishing that endpoint too)

    To reduce this requirement - we could also employ Service Bus Queues (which the newer SDK will tell you when a message has arrived on the queue as an Event). By having a queue, the client + app can suffer disconnects and disruptions.

    So to summarise:

    1) Azure Networks - apps don't even notice and automatically enjoy Azure capabilities across all protocols/ports.

    2) Azure Connect - specific servers connecting to Azure via a VPN.

    3) Service Bus - exposing WCF endpoints in particular ways.

    4) Possible option here - simply use Azure Storage (tables, blobs, queues) to connect Apps to Azure worker roles and visa versa.



    Mick Badran - http://blogs.breezetraining.com.au/mickb

    Thursday, February 28, 2013 4:53 AM