I want to connect to On-Premises database from Azure. Basically i will be hosting my web Application on azure and will be using Database from On-Premises.
According to www.WindowsAzure.com both Azure Service Bus and Windows Azure Virtual Network are used for connecting to On-Premises database. But what is the difference between these two and which of them should be used according to different situation ?
There is a big difference between both approaches:
Service Bus is connectivity on application or messaging level. Here you will have two options:
Service Bus Relay : here you have to expose a web service (that connects to your local database) over the Relay binding. This will
make a publically reachable service in a firewall friendly way. This
is mostly a synchronous approach.
Service Bus messaging: you will have to have a local process that listens on messages / events that you put on a queue or a
topic/subscription from your application. This is mostly an
asynchronous approach.
Virtual Networking: here you can set up connectivity on network level and you would be able to connect to your database as if he is on the same network as your cloud based application. The advantage here is that your code would not have to change, compared to a standard application (except for connectivity retries)
Both approaches are totally different, but can be valid, depending on your preference of architecture. (web service oriented, network level connectivity, or asynchronous processing).
Hope this helps.
Related
I can see multiple places that web sockets are not supported in function apps. I just want to create a web socket for some seconds and close it down again. So I do not have a need for a complex socket framework. I was wondering why this settings is present if it is not supported? Has Microsoft started supporting this feature?
Azure Functions are generally hosted in 2 ways:
Consumption Plan (Serverless)
App Service Plan (Dedicated)
Consumption Plan (Serverless)
In this plan, the underlying machine is de-provisioned when the server is idle. So, you may lose your active Web-Socket connections when the machine is idle and de-provisioned.
Also, below is the statement from the Microsoft Azure Function team:
There are some challenges here because WebSocket is really a stateful protocol (you have a long lived connection between a given client and a given server) while Azure Functions is designed to be stateless. For example, we will often deprovision a Function App from one VM and start it on a different VM (perhaps in a different scale unit) based on capacity constraints. This is safe to do for us today because of our stateless design - but if we did it when there were WebSockets connections to that VM, we'd be terminating those connections. Source: GitHub
App Service Plan (Dedicated)
If you are using a dedicated App Service Plan, then Web Sockets will work for sure, because there is a machine in the background which is not serverless (always available).
Just make sure you have enabled Web Sockets in the configuration (as you have done already).
Check web-socket connection limits for App Service Plans from here -
App Service limits
What are the differences between Hybrid Connection and the On-Premises Data Gateway?
Initially my focus is on Azure App Services (Web Apps, Logic Apps, maybe API Apps) connecting to internal web services
I started checking out Hybrid Connections versus Service Bus Relay, but another member of the team mentioned the On-Premises Data Gateway which is coming from the Microsoft business application platform, so Power BI, Microsoft Flow and Power Apps
So I'm now confused over the direction ... is the Gateway replacing Hybrid and Relay?
I'm not totally sure about this but it seems that On-Premises Data Gateway is a connection between On-Premise and servers (IaaS) in Azure. Hybrid Connection is used to connect On-Premise to e.g. Web Apps (PaaS) in Azure.
So I would say that at least one difference is whether On-Premise is connected to IaaS or PaaS.
My answer above is based on information in following links:
https://learn.microsoft.com/en-us/azure/analysis-services/analysis-services-gateway
https://azure.microsoft.com/sv-se/resources/videos/josh-twist-introduces-hybrid-connections
From an integration perspective, let's say you want to read some data from on-premises SQL server as a step in a logic app.
If you have either a Site-to-Site VPN or ExpressRoute providing connectivity between your on-premises network and Azure VNET, create an Azure ISE (Integration Services Environment) deployed to an Azure VNET. You will then be able to connect directly to the SQL server from your Logic App (since it is resolvable / contactable via DNS). Ref:
https://learn.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview
If you do not have this connectivity in place, you can install a Data Gateway component on-premises to present configured internal data sources to Azure using a persistent outbound connection (like app proxy). Ref:
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection
However, even if you do have network connectivity in place, in some scenarios (and from experiences) there may be a benefit in using the Data Gateway for it's caching capabilities (if applicable to the scenario). Ref:
https://learn.microsoft.com/en-us/power-bi/guidance/gateway-onprem-sizing
I have a azure cloud service (a server) where i host a Redis database. I also have a web site hosted in azure web sites. I want the web site to be able to talk to the Redis DB on port 6379. I know I can configure a public endpoint for that port on my server but that would open it for whole Internet. I want it opened only for azure web sites (or even better, only for my web site). How can i do this?
Windows Azure Web Sites is in an isolation bubble separate from your Cloud Services and there's no way to bridge that gap. Ideally you'd do this by connecting the web site machine to other Azure services via a Virtual Network, but this FAQ confirms you can't do that right now:
Can I use Windows Azure websites with Virtual Network?
No. We do not support websites with virtual networks.
Opening Redis up over the internet shouldn't even be considered as it doesn't have the kind of security you'd want out of the box to be opening up its port publicly as it is meant to be co-located with your application, so you really wouldn't want to do that. Never mind the added network overhead which will eat into the performance you expect to get by leveraging something like Redis anyway.
I believe your best bet given your current configuration is to add a Web Role that's part of the same Azure Cloud Service and run your web based application out of that so that it can communicate with worker role. It only requires a little bit of configuration to get this going (i.e. adding an InternalEndpoint to the Redis Worker Role). While I realize Web Roles don't offer as frictionless a development model as Web Sites, you have to choose the right tool for the job.
Another option, if you want to setup your Redis on a VM instead of tying it to the Cloud Service directly, is that you can setup a Virtual Network, put the Redis VM on the virtual network and then configure the Cloud Service so that it's part of the same affinity group and add the NetworkConfiguration/VirtualNetworkSite configuration section to the Cloud Service's .cscfg.
Which approach makes more sense all depends on how you leverage your Redis instance, but the main benefit of the latter approach is that the Redis instance is not recreated each time you deploy your Cloud Service and, so, any data that's in it will stay available between deployments. Another benefit is if you want to build and leverage a Redis cluster across multiple Cloud Services this enables you to do that.
We have used an Azure Service Bus relay REST Service to expose our internal WCF webservice to external customers.
Functionally all good, but we have noticed that it's significantly slower than connecting directly to WCF end point. I would have thought that Azure Service Bus just relays the internal endpoint without introducing any performance bottleneck.
Could someone please share what are the things to consider (in terms of performance) for Azure Service Bus? Any hints on how we can optimize the performance will be great.
The Service Relay REST Service is 16seconds slower than connecting directly to WCF Service. I noticed the main bottle neck is between Service Bus and Internal WCF call.
1) If your clients are using ChannelFactory, then cache the channels.
2) Is your endpoint on a data center near you and your customers? If not, I would highly suggest you change that.
3) According to the docs, if you are using NetTcpRelayBinding you can also set the TcpConnectionMode to Hybrid, which will establish "direct connections between two parties that sit behind opposing Firewalls and NAT devices"
Can anybody tell me how to connect a web app running on azure to existing web services (.ASMX) on premises?
We do not have the source for the services they are exposed by third party applications and we do not want to open them up to public access.
Sounds like Azure's Service Bus Relay Service might be what you're looking for...
There might be three options based on your scenario. But I personally prefer the third one.
If you used azure cloud service (web role, worker role), you can use Windows Azure Connect. It builds an IP-sec communication between the azure machine and your local machine. Then you can connect to your local service through the its IPv6 address.
If you used azure virtual machine to host your azure project you can use Virtual Network. It's more powerful than the Windows Azure Connect.
You can use Windows Azure Service Bus Relay. It can open your local service to the cloud regardless how your azure project is hosted. But since it's only support WCF of Service Relay, and since you cannot change codes and config of your service, you might need some more works. Maybe you can create a small WCF on your local machine as a proxy, register it to Service Bus Relay, and pass all request/response to your local service.