1

In a microservice architecture it's quite common to have tens of "internal" services, i.e. those services that are only intended to be called by other services in the architecture and not publicly accessible.

We're very happy with Azure Cloud Services (web and worker roles) and all the nice PAAS deployment benefits they bring. We'd like to develop several internal microservices as Azure Cloud Services but at the same time avoid having to add custom application security code to them (OAuth etc.) by ensuring they can only be accessed by other machines in the same Azure Virtual Network.

What are the options for achieving this? Is there anyway to stop an Azure Cloud Service being assigned a Public VIP Address / Site URL (*.cloudapp.net)?

One option we're aware of is using the IIS ipSecurity element to lock down the services to a defined range of internal IP addresses but wondering if there are any better alternatives?

Simon Ness
  • 2,272
  • 22
  • 28
  • You can host a WCF service and for the endpoint choose internal port so ithe service would be accessible only through your other cloud services – Coder1409 May 27 '15 at 14:03

1 Answers1

1

Look into Internal Endpoints. They allow your services to communicate internally without going thru public internet and thus allow you to not have any public endpoints

https://msdn.microsoft.com/en-us/library/azure/hh180158.aspx

HTH

Igorek
  • 15,716
  • 3
  • 54
  • 92
  • Thanks @igorek :) Definitely something to consider. The drawback I can see for our use case is that all web roles need to be defined in a single Cloud Service (.csdef file) to be able to set up the Network Traffic Rules. Thus losing one of the key benefits of a microservices architecture, independently scalable services, as all roles will be hosted on each instance of the Cloud Service, unless I'm mistaken? It won't be unusual for us to need 20x service A and 1x service B based on demand, be that a queue length or CPU %. – Simon Ness May 27 '15 at 18:25
  • You can have multiple roles within a single Cloud Service. Each role can be scaled independently. Although you're right, there are certain... deployment pains with respect to having all Roles in one service. Everything is always deployed together – Igorek May 28 '15 at 04:51