Cloud Virtual Networks: PaaS and IaaS approaches

As applications that are used by employees of large corporate enterprises start to work their way in to the cloud, it becomes obvious that a need to integrate the network and security infrastructures of both environments becomes important. I’ve made a number of posts (here, here and here) on this blog in the past concerning Microsoft’s approach to this – Windows Azure Connect. But with the recent announcements from Amazon regarding Virtual Private Cloud and Virtual Networks, I was obviously interested.

It is very clear that the trajectories of the 2 companies sees Microsoft firmly of the opinion that the cloud platform is primarily a PaaS platform while Amazon clearly sees it as an IaaS platform. Yes there have been some moves which have recently weakened those arguments to a degree. Amazon’s Elastic Beanstalk and, some commentators say, Microsoft’s VM Role (though I hoped to explain - even this model is still clearly a PaaS model with this post, this post and this one) moves in the direction of IaaS (as opposed to being a full IaaS implementation).

Well, looking at the virtual networking models from each company also clearly shows where they sit. Amazon’s newest Virtual Private Cloud (VPC) effectively gives you controlled access to the underlying network infrastructure in the Amazon Datacentre. You can define subnets and make them either private or public (Internet-facing). You can also set up NAT between subnets and features such as Network ACLs, filters and so on give you pretty much management of the firewalls that protect the DMZ you create in your VPC.

Contrast that with the amount of network control you get with Windows Azure, and Windows Azure Connect. With Windows Azure – you don’t get control of the network at all. It is all entirely abstracted away. There are different subnets, networks zones, routers, load balancers and the other network infrastructure – you’ll rarely if ever hear anybody from Microsoft talk about it, other than in the sense of a “passing interest” (almost as I have done above!). That’s because in the same way that there’s a barrier between the code you write and the operating system, and as a developer you can never cross that barrier, it’s also true of the networking infrastructure. There is a network manager that looks after that for you. It’s not a person though – it’s the fabric and the fabric controller.

Amazon allows you to replicate the way the network is set up in your on-premise datacentre. You never have to get your network engineers crawling under the floor-boards with bits of wire and screwdrivers – they’ve given you software tools that allow you to configure their network infrastructure to your requirements. And I guess that all makes perfect sense for the way Amazon does cloud computing. You have the control and associated responsibility of making sure your instances are properly patched and managed: that all the correct security fixes, hotfixes, service packs and so on are applied – and so it is with the network infrastructure too, if you create a VPC.

With Windows Azure Connect, you do 3 things to make it work:

1. Make config changes to your application to enable the feature before you send it to the cloud
2. Install agents on your on-premise machines
3. Use a web-management portal to define which groups of one-premise machines can communicate with which roles you have deployed in Windows Azure.

That’s it. The underlying complexity, firewalls, subnets, networking and so on are hidden and you are denied access. But that’s OK, because you use Windows Azure because it has that abstraction and takes care of all those details for you. The aims with Windows Azure, as I think are well explained in this post, are to shield you from managing the infrastructure. Running applications has inherent value – managing the infrastructure they run on has no inherent value.

At this point someone’s going to say to me – “so Planky, which one’s best, PaaS or IaaS – Windows Azure or EC2?”… And the answer is of course – it depends. Some applications are so deeply embedded in to the underlying infrastructure they couldn’t possibly be moved to Windows Azure in their current state. You can take almost any application-plus the underlying OS (as long as it’s a supported OS I mean) and now, with the latest VPC, even the configuration of the network infrastructure it runs on and simply lift-and-shift it, lock, stock and barrel, to EC2. You definitely get the advantages of pay-per-use immediately. You have to manage all the infrastructure, but the time-to-benefit could be measured in hours in some cases. With the right applications, you can get the same with Windows Azure, plus additional benefits but you enter in to a sort of contract. Because it’s a PaaS system, the underlying infrastructure, including the network infrastructure is hidden (aside from a few very simple knobs and levers in Windows Azure Connect), but you have to write you applications in a way that can take advantage. You lose the burden of that thing which gives no inherent value (managing the infrastructure), but you have to architect applications in a specific way.

I think this latest announcement from Amazon highlights even more, the approaches the 2 companies are taking with their cloud offerings. Sure, Amazon have something that moves them a fraction to the left along the axis of the diagram above with their AWS Elastic Beanstalk offering. Microsoft has something which moves it further along to the right with VM Role. and who can say what will happen in the future as far as those things are concerned. But one thing we can be sure of with this latest announcement is that Amazon is first and foremost an IaaS provider and Microsoft is first and foremost a PaaS provider. Which one should you use? – “it depends”…

 

Planky – GBR-257