May 17, 2011 4 Comments
You ever have those days where you wake up, look around, and wonder how you got where are? Or better yet, what the heck you’re doing there? This pretty much sums up the last 6 months or so of my career. I have recently realized that I’ve been doing so much Windows Azure evangelizing (both internally and externally) as well working on actual projects and potential projects that I haven’t written a single technical blog post in almost 5 months (since my Azure App Fabric Management Service piece in November).
So I have a digital copy of Tron Legacy running in the background as I sit down to write a bit on something that I have found confusing. And judging by the questions I’ve been seeing on the MSDN forums, I’m likely not alone. So I thought I’d share my findings about Windows Azure Endpoints.
For every ending, there is a beginning
Originally, back in the CTP days, Windows Azure did not allow you to connect directly to a worker role. The “disconnected communications” model was pure. The problem with purity is that it’s often limiting. So when the platform moved from CTP to its production form in November of ’09, they introduced a new concept, internal endpoints.
Before this change, input endpoints were how we declared the ports that web roles would expose indirectly via a load balancer. Now with internal endpoints, we could declare one or more ports on which we could directly access the individual instances of our services. And they would work for ANY type of role.
It was a bit of a game-changer. We were now able to reduce latency by allowing direct communication between roles. It was a nice and necessary addition.
What does internal mean?
The question of “what does internal mean” is something I struggled with. I couldn’t find a clear answer for if internal endpoints could be reached from outside of Windows Azure, or more specifically outside of the boundary created by a hosted service.
We’re told that when you create a Windows Azure Service, all instances of that service are put on their own branch within the datacenter network to isolate them from other tenants of the datacenter. The Windows Azure load balancer sits in front of this network branch, and handles the routing of all traffic to the input endpoints that have been declared by that service. This is also why the ports your services’ input endpoints were configured for (the external facing one) and the port that your service is hosted on (behind the firewall) can be different.
So where does this leave internal endpoints? I ran some tests and I’ve asked around and unfortunately I was not been able to come to a definitive answer. What appears to be happening is that an internal endpoint is not visible outside of Windows Azure because it’s not managed by the load balancer. Therefore the internal endpoints simply aren’t visible to anything on the public side of the Azure Load balancer. Even if you know the port number to connect to, the IP addresses assigned to the instances isn’t known on the public side of the Azure load balancer.
But is this secure enough?
It turns out that this isn’t the end of how the endpoints are secured. I ran across a great blog post on what the Azure Fabric does when it configures the instance VM’s. Namely, its configuring the internal firewall.
I really want to salute Michael Washam for his info on the firewall. This wasn’t information I would have gone looking in the guest VM for. It’s also information I hadn’t seen anywhere else. In his post he discusses how the role’s firewall is set for restricting access to only the roles and their IP’s within a Windows Azure service. Presumably, these settings are automatically managed by the fabric agent as roles are spun up and down during normal service operation.
This would be important because as you recall from earlier, I discussed how each branch of the network is protected. So the firewall configuration compliments this by further ensuring that traffic is restricted. How if we could just apply the same filters to Azure storage services. J
But we’re missing here…
But this all has me thinking. There are likely a couple items missing yet. Windows Azure is a PaaS offering. It’s supposed to take away the mundane tasks we have to do today and replace them with features/services that do these tasks for us. If so, there’s two things missing.
As Michael Washam points out, if you’re spinning up internal ports yourself, you have to configure the firewall manually. IMHO, there should be a way to register connections with the Azure Fabric at run-time and have them auto-magically configured. Admittedly, this is a bit of an edge case and not something that’s being asked for.
The more important need that I see is one that is illustrated by a recent MSDN article, Load Balancing Private Endpoints on Worker Roles. In his article, Joseph Fultz talks about how they needed a “private” service but also one that’s load balanced. The internal endpoints were a perfect solution for privacy, but not load balancing. In Joseph’s article, he explains a couple of approaches to creating a load balanced internal service.
These approaches are valid and work well. But having to do this seems to fly in the face of what PaaS solutions are about. I don’t want to have to build my own load balanced solution just because I want to keep a service private. Its PaaS, I shouldn’t have to do this. To me, this shortcoming is almost as high on the feature list as fixed IP’s.
To this end, I have created my own entry in the MyGreatWindowsAzureIdea list. I have proposed being able to flag a load balanced input endpoint as either public or private. If it’s public, you get behavior as we see if today. If you flag it as private, then it’s accessible only to instances that are within its service boundary.
I normally try to make sure I’m adding to the discussion on any topic I cover in my blog. Unfortunately, with this topic I’m not adding anything new as much as aggregating several sources of information that I found scattered around the web. So I figured I’d leave this update with a list of some other sources on Azure Endpoints I recommend.
- Hands on Lab: Using Internal Endpoints for Inter-Role Communication
- Azure Team Blog: New Endpoint Options Enable Additional Application Patterns
- Creating an external facing Azure Worker Role endpoint
- MSDN: Enabling Communication for Role Instances in Windows Azure
- Overloading your web role
Until next time!
PS – It’s often asked how many endpoints you can have. The simple answer is that any role can have any of input and internal endpoints up to a maximum of 5 endpoints. Additionally, if you plan on enabling RDP, this will consume one of those endpoints.
Update: My post-script isn’t entirely correct (but still works if you just want to keep things simple), so my buddy David did a new post just moments after this that clarifies some additional info about the 5 endpoints per role limitation. He managed to get 50 total endpoints!