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
One of the basic tenants of virtualization security is to protect the management components of your virtualization hosts by placing these all important components on a separate network. These components often include management servers such as SCOM, vCenter, XenCenter, VirtManager, etc. as well as the management appliances of your virtualization hosts. In essence, the use of a properly configured, firewalled, and monitored virtualization management network would be the simplest and most effective security measure that can be made to day within any virtual environment. A message shared by Citrix, VMware, myself, and many others.
The problem is that not everything is as black and white as security folks desire. If we implement performance and other management tools, we often need to expose part of our all important virtualization management network to others. But how do we do this safely, securely, with minimal impact to usability? Why do we need to this is also another question. You just have to take one look at the Virtualization ASsessment TOolkit (Vasto) to realize the importance of this security requirement. But the question still exists, how do you implement other necessary tools within your virtual environment without impacting usability? Which we discussed on the May 5th Virtualization Security Podcast. Continue reading Security of Performance and Management tools within the Virtual Environment
VMTurbo has broken some significant new ground in terms of what is available for free in a virtual appliance that manages the performance and capacity of VMware vSphere environments. This new free tool is not time limited, nor is it limited in terms of the size of the environment that it can address. Continue reading VMTurbo Breaks New Ground for Free vSphere Monitoring Tools
In “Cloud SLAs Are Worthless But Does this Matter?“, we concluded that there are some significant differences in how SLA’s are perceived between those being in place with an IT organization and those offered by a public cloud vendor. The principle difference appears to be that an IT SLA is an agreement that an IT organization strives to honor, in contrast to a public cloud SLA which is more of a marketing statement designed so that the cloud vendor can never violate it. Continue reading So What Should a Cloud SLA Look Like?
Mike DiPetrillo’s post entitled VMware is Building Clouds sparked some interesting thoughts and discussion about what it means to have federated clouds and how do you define such federation? Is federated required to make ‘cloud’ ubiquitous or are we already there? But is the discussion really about federated clouds or simplistic data object movement between the VMs or about cloud management?
When we talk about cloud data we often speak about moving virtual machines around, but is that the proper way to do this? Given that a VM could be 100s of gigabytes, could the movement between clouds happen fast? What about the runtime and security contexts that surround the data to be moved (whether a VM or not). Does this move with the data object or does it stay within the source environment. I have this question regardless of cloud type. Continue reading Federated Clouds? Possible?
A Service Level Agreement (SLA) is an excellent expectations-managing mechanism, but it’s important to manage your own expectations of what an SLA can realistically accomplish. Just those three words “Service” “Level” and “Agreement” is often an attention turn-off I know: SLAs are to infrastructure bods what documentation is to developers. Yet, when considering taking up cloud and utility services many consider that the SLAs offered aren’t reliable, if they exist at all. So the SLA becomes the blocker – ‘If I move services out of my data centre, how will I guarantee availability and performance’.
Are SLAs for Cloud services really worthless and if they are, will the wider adoption of cloud services be impacted because of this?