Citrix Release Cloudplatform 3.0.5 Burbank
Last week Citrix (rather quietly) announced their latest release (3.0.5) of their “CloudPlatform (powered by Apache Cloudstack)” cloud orchestration product. Giles Sirett, Managing Consultant of ShapeBlue has a first look at the new release.
3.0.5, codenamed Burbank, has always been played down by Citrix as a minor release containing mainly bugfixes and only a few new features. From the release notes, I count 76 bug fixes and only 6 new features.
Many people, myself included, found it strange that Citrix should remain committed to this release when Apache is due to release version 4.0 in a couple of weeks.
My take is that this is simply a timing thing. Citrix are keen to get some of these features in as they see them key to CloudStack’s continued growth in the commercial market, whereas Apache have been focussing on getting CloudStack through incubation. It’s worth noting that all of the features of 3.0.5 have already been contributed to the Apache codebase so we expect to see them in 4.0.
So, for the purposes of easy reading, I’m going to refer to the product as Cloudstack, even though technically there isn’t a 3.0.5 of CloudStack.
Before we look at the features, it may be worth taking stock on where Cloudstack (and the wider cloud orchestration market) is right now. When considering cloud orchestration, there’s really two flavours of technology:
1. Orchestration built on open standards such as CloudStack and OpenStack.
2. Proprietary technologies such as VmWare VCloud Director.
Right now, the service-provider space seems to favour open platforms for their ease of integration and their ability to be more reactive to market demands whereas enterprise (often with much greater technology lock-in & inertia) will stick to a propriety offering, often on top of a converged infrastructure offering. However, increasingly at ShapeBlue, we’re seeing enterprise customers asking specifically for open orchestration technologies (mainly Cloudstack for us) as it keeps open for that enterprise so many technology choices for the medium term. They are now coming round to what many of us have been saying for some time: should my orchestration layer dictate my hardware and/or virtualisation technology? – I’ve always said the answer is no. The maturity of platforms such has Cloudstack is allowing this step-change to happen.
But there has always been some key missing features from CloudStack that have shown that it’s primary USE-CASE was service provider & public cloud. Burbank now adds these features and, although there’s no surprises, the new features all point to Citrix wanting to play heavily in that Enterprise space with Cloudstack. And, as for the battle with OpenStack, I know where I’d put my money.
The new features
Cloudstack’s network model has always been one of it’s strongest features. However, the inability to route between VLAN’s restricted the ability to create multi-tiered networks as are used across so many applications within the enterprise (i.e. db, application & web layers). Inter-VLAN routing now gives this. We haven’t yet got anything to quite rival VMWare’s VApps but inter-VLAN routing is a key building block for such functionality and, with CloudStack’s API, it should be possible wrap this up quite easily into a VAPP style offering.
To date the single most important missing feature of CloudStack was lack of site-to-site VPN functionality. Service providers want to sell virtual private Datacenters to their customers. If they’re going to do so, then those customers need a simple way of connecting their existing network to their new cloud DC. There are lots of much cleverer ways of bridging our clouds with existing infrastructure these days, but site-to-site VPN should have been there from the beginning. At last it is. Cisco ISR and Juniper J-Series are the supported end-points.
Version 3.0 of Cloudstack , released back in February, introduced direct support for Citrix’s own load balancer, NetScaler (and before anybody from Citrix jumps on me, I know that NetScaler is far more than a load balancer, but for the purpose of this article I’ll ignore all of it’s other features.)
That integration has now been heavily stepped up with CloudStack’s Netscaler autoscaling. The ability to scale easily is one of the major USE-CASE’s for cloud and it is somewhere that, to date, Amazon have set the pace. Rightscale have some really clever technology to manage scaling & bursting but many people have always thought that it should be simple to scale up and down, without having to buy 3rd party technology. With CloudStack’s Netscaler autoscaling I can use the NetScaler to monitor usage based on a wide number of metrics and then create and destroy CloudStack instances as required.
The single biggest cost in most IaaS clouds is the storage. For some time with Cloudstack we’ve been able to leverage local (read “cheap”) storage for VM instances, but we were limited to data disk’s being on primary shared (read “expensive”) storage. The ability to use Local storage for data volumes means that we really can truly exploit the concept of cheap commodity hardware. I wouldn’t want to store somebody’s critical data on a local disk, but for R&D & test USE CASE’s this will present a significant cost saving in IaaS provision.
All virtual resources (instances, templates, volumes, networks, etc,etc) can now be categorised with a schema of name/value pairs called Tags, very similar to AWS tags . This allows grouping of resources beyond CloudStack’s built in Account and Project levels. For example, it could be used for department level grouping of resources in order to allocate usage & costs across those departments.
Changes to both the CloudStack API and it’s EC2 API have been made to support Tags.
There’s no surprises in the Burbank release, just a whole bunch of stuff, some may argue, that should have been there from the beginning. But it is important functionality and it is a good indication of CloudStack’s adoption that Citrix feel they need to release prior to 4.0
My guess is this is the last time that we will see Citrix releasing prior to Apache.