Asked by:

Networking and Service Bus

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.

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.