"Private" TCP WCF services in Azure?

1
votes

We have three "types" applications:

  1. MainSite (MVC Web Role, 6 instances)
  2. CoreServices (TCP-based WCF Worker Role, 20 instances)
  3. NewFeaturesPreviewSiteOne (MVC Web Role, 3 instances)
  4. NewFeaturesPreviewSiteTwo
  5. ... 14. NewFeaturesPreviewSiteTwelve

Both MainSite and CoreServices are bundled up as two roles in one deployment. This is updated ~once every 2 months. MainSite accesses CoreServices via an InternalEndpoint on CoreServices. This works great!

We now want to add NewFeaturesPreviewSite (in reality, we have 12 totally different/unrelated apps that you can think of like this). NewFeaturesPreviewSite is updated every couple days and is its own deployment. However, we REALLY want this to consume the already-deployed CoreServices app.

What is the best (or a good) way to accomplish this while considering the following?

  1. Load-balancing is a must-have (20+ CoreServices instances handling requests from three NewFeaturesPreviewSite instances).
  2. We do NOT want CoreServices being publicly exposed to the internet or to anything outside of our applications we're deploying to Azure.
  3. I'd really like to have a solution that leverages Azure's PaaS platform rather than its IaaS platform.

Ultimately, I suspect there's something with Azure's Local Network or Virtual Private Network features that might help me here but I'm not sure - there's something about those that I don't quite get yet.

1
wcfsecurityazure

1 Answers

0
votes

From the public documents from Microsoft you might not be able to communicate through internal endpoints from another deployment (cloud service). This means you have to open an input endpoint on your core service for your new feature services. But I have the impression that Steve Marx had had a blog post said if you somehow know the internal endpoint, you can just connect to it from another cloud service role if both of them are located in the same data center.