Dynamic IP-address filtering for Azure

Putting applications in the cloud is great, and offers a lot of benefits (as well as some complications). We get great scalability, elasticity, low cost of ownership etc. One problem however, is that the cloud is very public. I guess this isn’t a problem in most cases, but if what you are putting up there is supposed to be secret, or at least needs to limit who gets to use it, it becomes an issue.

I am currently working on a project like this. I am not going to talk about the project as such as it is under NDA, but the fact that it is is a service in the cloud that should only be used by certain clients is not uncommon.

The service has a front end that consists of WCF services, hosted in a web role, which is what we need to secure. The worker roles behind the web roles are by default secure as they do not communicate with the outside world at all.


Windows Azure Service Bus - Lost in Intro

I have recently posted a few posts on how to use some of the new features of the Azure Service Bus. They seem to have been somewhat popular, which is fun. They are however very light weight introductions, and not that I am going to dig a whole lot deeper at the moment, but there are a few little things I want to mention.Mainly around brokered messages.

As you know from the previous posts, a brokered message, is a message that is sent to the bus from a client, and picked up by a service at some point. The message can contain a body, which could be more or less any class that you would like, as well as metadata about the message. The only thing to remember with those things, is the fact that the message size is limited to 256kb.


Using the Windows Azure Service Bus - Topics and Subscribers

I guess it is time for another Azure Service Bus post. The previous ones has been relatively popular, so I thought I would do one more post to cover one last feature in the bus. (I say one last now, but I am pretty sure I will be back…)

Topics and subscribers are the basic units behind the Service Bus implementation of the pub/sub pattern. And as expected from a “simple” pattern like this, it should be simple to implement, and it is. The basics would be, create a topic, add subscribers that subscribe to messages from the topic, and finally push some messages to the topic, which are then relayed to the subscribers. Simple as…


Weird bug/feature in Visual Studio 2010

As I was working with some of my demo code for the Azure posts I have been putting up lately, I came across a very odd thing. I had a solution with several projects that built and worked perfectly fine. I did however need to make some changes to the solution before zipping it up and putting it on my blog. So I made a copy of the solution folder, removed my source control bindings and everything else that shouldn’t be in the zip.

Before zipping it up, I thought I would just make sure it built ok after my changes, which it obviously should as I made no code changes. So I loaded the solution into Visual Studio and everything looked fine. But pressing Ctrl+Shift+B made Visual Studio cough and tell me that XXX was not available in namespace YYY, which is really odd as I had made no code changes.


Using the Windows Azure Service Bus - Queuing

I guess it is time for another look at the Azure Service Bus. My previous posts about it has covered the basics, message relaying and relaying REST. So I guess it is time to step away from the relaying and look at the other way you can work with the service bus.

When I say “the other” way, it doesn’t mean that we are actually stepping away from relaying. All messages are still relayed via the bus, but in “the other” case, we utilize the man in the middle a bit more.

“The other” way means utilizing the message bus for “storage” as well. It means that we send  a message to the bus, let the bus store it for us until the service feels like picking it up and handling it.

There are several ways that this can be utilized, but in this post, I will focus on queuing.


Using Azure Service Bus relaying for REST services

I am now about a week and a half into my latest Azure project, which so far has been a lot of fun and educational. But the funky thing is that I am still excited about working with the Service Bus, even though we are a week and a half into the project. I guess there is still another half week before my normal 2 week attentions span is up, but still!
So what is so cool about the bus, well, my last 2 posts covered some of it, but it is just so many cool possibilities that open up with it.
This post has very little to do with what I am currently working on, and to be honest, the sample is contrived and stupid, but it shows how we can use REST based services with the bus.

Using the Windows Azure Service Bus - Message relaying

My last post was a bit light on the coding side I know. I also know that I promised to make up for that with a post with some actual code. And this is it! Actually, this is one of them. My plan is to walk through several of the features over the next few posts in the n00b kind of way.

That is, I am going to go through the basics for each of the features I deem interesting, making it easy to follow for people who are new to the Service Bus. And please don’t be offended by the “n00b” comment. We are all “n00bs” at some point in every thing we do.


What is the Windows Azure Service Bus?

For the last year, there have been few things in the development space I have heard as much about, as I have heard about Windows Azure. Microsoft has been pushing the Azure platform hard, we all know that, but not all of us have had the chance to try it out though.

Luckily I have had the fortune of being on a few projects that have been using it, but to be honest, I haven’t been really blown away yet. Yes…it does offer some awesome features that work extremely well in certain scenarios, but I would still claim that it isn’t for everyone. Having that said, I admit that I have only scratched the surface of the platform…

Lately however, more or less every time I hear Azure, it comes bundled with the term Service Bus. Either in “this would be such a great scenario for the service bus”, or in “wonder if we can get the service bus in there so that we can try it out”. Ok…so one of these are ok, the other isn’t to be honest… Playing with the service bus isn’t hard, as I will show you in future posts, and thus does not need to be added to a project to be tried. But before I start coding, I want to have a little rant about what it is. Or at least a rant about how I have understood it…


Windows 8 communication is not very Microsofty

A couple of weeks has gone by since Microsoft unveiled Windows 8 at the BUILD conference in Anaheim, and things are kind of back to normal. Except for the fact that Microsoft has gagged all of their normal information channels.

Apparently, Microsoft representatives are not allowed to talk about Windows 8 at all. And speakers at some conferences have been informed that they are not to talk about Windows 8 on stage. At least not their personal opinions. I assume that they are allowed to talk about the facts that were unveiled in Anaheim…


Choosing technology for Windows development

I feel that the one thing that has been lacking here at Build is information about the fact that “old” windows application technologies are still there in Windows 8, and are just as much first class citizens as the new Metro style apps. They even have a lot on offer that the new apps don’t.

Microsoft promises that any application that runs on Windows 7 will also run on Windows 8. They are also saying, repeatedly but not loud enough, that the “old” technologies are still a very viable option for developing apps. You should not necessarily default to building a Metro style app when creating a new application. To be honest, in my world at least, I am very likely to lean towards another technology when starting a new project.