Tag Archives: Open Source

Red Hat releases MRG 2.0 – messaging for the cloud.

We’ve touched on Red Hat’s Cloud strategy in a number of posts. To summarize they’re trying to play at all levels in the stack, from IAAS and PaaS through to hypervisor and of course operating system. All layers are open, and as you get further down the stack towards virtualization they are pushing KVM but they are clear that they have to co-exist with Microsoft and VMware.  In the IaaS layer they have DeltaCloud, which is nominally open but is really a Red Hat product with an open veneer. In the PaaS layer they have a stack of really good middleware from JBoss, and an openness to a whole bunch of Java/JVM and non-JVM languages.  They’re punting this out to the world as OpenShift.

So far, although there are nuances that differ from other vendors, the main conclusion is that each individual layer is comparable to offerings from competitors.  However, there is one layer that sets Red Hat apart from competitive offerings, known as MRG – Messaging Realtime and Grid, pronounced “Merge”.  If you’re wondering what this is, it seems also that some of are bits of Red Hat’s marketing department that haven’t got a clue either because the market positioning is a bit vague. Continue reading Red Hat releases MRG 2.0 – messaging for the cloud.

Citrix announces IaaS Project Olympus built on OpenStack

I like OpenStack (the Open Source IaaS Cloud Platform intiative), partly because of the model of open innovation and permissive licencing (which reminds me of my time at Eclipse) and partly because even within the existing governance model (which I have criticised) there is the opportunity for different agendas to surface and to drive the project in different directions and this diversity makes an analyst’s life more interesting.

One of the most intriguing names that has hitherto been at the periphery of the OpenStack initiative is Citrix. Up until last week, Citrix’s contribution was to ensure OpenStack ran on XenServer, something which I’m sure Citrix cares about, but perhaps wasn’t top of the list of requirements for the rest of the world. However, this week at it’s Synergy event, Citrix made some more sigificant announcements about Project Olympus, through which it aims to provide (in collaboration with Dell and Rackspace) a route to commercial exploitation of the OpenStack codebase. Continue reading Citrix announces IaaS Project Olympus built on OpenStack

Why would a Developer choose VMware?

It is interesting to see Edward’s comment that according to EMC/VMware, widespread production deployment of Cloud Apps is 3-5 years off.  If that is the case the VMware CloudFoundry initiative should be focused on cutting-edge development rather than porting existing apps, and in much the same way that Microsoft has always courted developers, CloudFoundry should be the latest cool thing for developer productivity. It’s interesting to talk about this stuff in the abstract, and at the strategic level, but sometimes it’s worth understanding what happens when you need to make the decisions for yourself.

So, although I’m more of an Architect than a Developer I’m knocking up a prototype application – this isn’t a thought experiment I really am building a real prototype with a view to showing to a real enterprise customer (in fact several), but it’s not being built for one specific customer so there aren’t any pre-defined corporate standards on the technology that I have to build it on.  Continue reading Why would a Developer choose VMware?

Is Gluster the answer to Scalable Cloud Storage and the Amazon Outage?

One of the differentiating features of an IaaS cloud implementation, is that you do not get access to a consolidated scalable storage infrastructure. At least not in the same way that you might expect if you were just scaling out compute nodes attached to the same SAN.  You get remote block storage (Elastic Block Storage, EBS, in the case of Amazon) connected to a specific machine image, and you get REST-style object storage (Simple Storage Service, S3, in the case of Amazon) which is shared amongst images but does n0t speak the traditional APIs.

A lot of people have become dependent on EBS as it seems closest to what they are used to. Amazon failed because of simultaneous failure of its EBS  in two Availability zones.  If you were dependent on one of these (or mirrored across the two) you lost access to the filesystem from your Instances. It is also worth noting that EBS images are not like CIFS or NFS filesystems in that they can only be attached from a single instance, so you are still left with a bunch of headaches if you have a replicated mid-tier that expects to see a filesystem (for example to retrieve unstructured data). It may be sensible to move to the use of the S3 mechanism (or some portable abstraction over it) for new applications, but if you have an existing application that expects to see a filesystem in the traditional way, this will require you to rewrite your code, so you are left looking for a distributed cloud-agnostic shared filesystem with multi-way replication (including asynchronous replication), and this is where Gluster fits in. Continue reading Is Gluster the answer to Scalable Cloud Storage and the Amazon Outage?

VMware’s CloudFoundry and Red Hat’s OpenShift – Compare and Contrast

Over the last few weeks, VMware (as we indicated in an earlier post) and Red Hat have initiated two very similar initiatives known respectively as CloudFoundry and OpenShift. These are Platform as a Service (PaaS) plays, being developed for the longer term, primarily looking to encourage the development of (and thereafter to provide infrastructure for) applications specificallysuited to the the cloud. In this article we compare and contrast the two offerings and discuss their significance for the PaaS market as a whole. Continue reading VMware’s CloudFoundry and Red Hat’s OpenShift – Compare and Contrast

Technically, the Amazon Cloud didn’t actually fail

As the dust settles on the Amazon Cloud Outage (or the mist lifts, or whatever cloud-related metaphorical cliché you prefer) I’d like to make a number of conclusions related to scalability performance, reliability and openness.

For those of you who haven’t followed the minutiae of the story, it appears that Amazon failed because a network event caused Elastic Block Storage (EBS) to start re-mirroring itself, which in turn saturated the network and caused more mirroring events in a cascade that made EBS unavailable. Continue reading Technically, the Amazon Cloud didn’t actually fail