MemorableURL.com

Some Definitions – Cloudpeople, Clouds and Private Cloud

Back to Virtualization and Cloud Index

I read a lot of junk on the internet…some people would argue that I don’t just read it, I’m also responsible for writing a fair bit of it. Occasionally though I’ll read an innocuous-enough looking article that turns out to be a gem. Here’s one…from "The Cloud: Battle of the Tech Titans" I pulled the following definitions:

Cloudpeople

People who work in the cloud…not fluffy IT professionals.

The Cloud:

the amorphous, out-of-sight, out-of-mind mess of computer tasks that happen on someone else's equipment.

"the Internet" ;-)

the ethereal place somewhere on the network where work gets done."

The Private Cloud

The heavyweights are encouraging customers to buy virtualization software, which makes it possible to run more business applications on each individual server. This means customers get more bang for their buck when buying hardware. To keep these new systems running smoothly as a unified whole, customers may also purchase new management software. Add these parts together, and you end up with a nimbler, more efficient version of traditional IT infrastructure known as the private cloud.

The private cloud is everything the incumbents love. They view it as a pragmatic transition toward a smooth-running computing infrastructure. Most customers will stick with the sellers they trust, paying for some consulting service to help them put the new technology to use.

If you have time read the rest of the article, it puts things into a great general perspective.

http://www.businessweek.com/magazine/content/11_11/b4219052599182.htm?chan=rss_topStories_ssi_5

BTW- Did you know that each day, Amazon Web Services (AWS) adds enough computing muscle to power one whole Amazon.com circa 2000, when it was a $2.8 billion business? You do now!

Virtualization of Enterprise Systems – vApps

Back to Virtualization and Cloud Index

In my first post in this series I described the primary building blocks in a virtual deployment of a complex enterprise solution. Basically, you run your applications on virtual servers (VMs) which are bundled together into logical collections of VMs to represent a solution (a vApp) and these are managed using vCloud Director.

The key building block when building up virtual enterprise solutions is the vApp. If you look back at the table on the primer posting you’ll see that a vApp is a “collection of VMs bundled up with the associated network relationships and policies which can be replicated, distributed and deployed to represent a typical server collection”. Hopefully you get the general idea – a vApp is a way of packaging Virtual Machine Images into logical packages that represent something useful…”but”, I hear you say, “please tell me more” and tell you a little more I will.

Let’s start with a standard, everyone loves a standard. OVF – (DMTF’s Open Virtualization Format) is a standard that allows vendors to put their virtual machines and associated bits into a package. There are many different products that allow you to create vApps including the aforementioned vCloud Director. A completed OVF file contains:

• The actual Virtual Machine images.
• Mandatory and optional metadata for the content - product name, build number/date, etc.
• Information about the virtual environment - virtual hardware information, virtual drive details, OS details, network topology, VM startup/shutdown order/actions.
• Additional supporting information – deployment options, EULA, product information, localization, and general annotations for upgrade instructions, etc.

So now you have a nice encapsulation of not just the VMs but all of the pieces that are required to support them running as a group regardless of the vendor. The OVF package can be electronically signed and supports compression.

So, what use is a standard in this case? Well, packages that conform to the OVF standard can be deployed onto any OVF-compliant hypervisor, (in the primer I explain briefly that the hypervisor is the layer that emulates the actual hardware and allocates resources to the VM image). So in theory (and in practice I guess) you can create your vApps and then distribute them out into different environments.

I’m aware that I am not answering the ‘why should I care?’ question yet but bear with me. I’ll write-up the vCloud Director piece, expand on some of the other elements and then once we are all on the same page we can dive into that question.

Virtualization of Enterprise Systems - Primer

eSaysSomething, iDontUnderstand, vCanHelp

Back to Virtualization and Cloud Index

I find that my best blog entries have two characteristics; they are a series of articles and they are written as I research and learn a new topic. So, right now I am researching virtualization so here we go with a set of articles based "ECM and Virtualization".

BTW, the subtitle of this post makes more sense if you say it with a German accent – it is no funnier but it makes a bit more sense…maybe.

It goes without saying that virtualization, as the technology behind most public and private clouds, is something that is in everyone's future. I for one have been using the wrong vWords in the wrong vPlaces and I'm guessing that most people that I work with don't know the vDifference because they are not correcting me. For this reason I decided that I needed a better understanding of the basic technology and real-life usage patterns. I jumped online and did a search for "VMware Primer" and “a vApp is a” and managed to find some high-level marketing overviews of vApps, VMware images, etc. I also found some great technical descriptions but I couldn't find a simple overview of the relationship between all of the parts and how they relate to an enterprise system like a traditional ECM solution.

Let me apologize to VMware ahead of time, my oversimplification of your products is more about making them relevant to this one specific case than it is about me not caring about your products.

In this series, I'll start with an overview of the relevant pieces of the virtualization stack, a description of each and then their relationship to a standard ECM deployment. Then once we have established technically how the stack fits into a vWorld we will look at what models can be used in relation to ECM and finally a practical look into what works in real life…aka, why you should care. I’ll also take some time to look at SharePoint online and how SharePoint in the cloud might work in your on- or off-premise virtualized ECM environment.

You'll notice that I'm not using the word ‘Cloud’ much at all, I'll avoid this word because it seems that no one quite understands what Cloud might actually mean (other than a meteorologist that is). Rather than entering into a ecumenical debate about what is a cloud and what is just suspended water vapor I'll focus on virtualization and you can decide what's vapor and what's just vapid.

So, let's start at a high level with the most relevant pieces of the VMware stack. In order to try to explain what each of these is I'm going to relate them to both their physical and ECM counterparts. In the table below I have listed each of the pieces in the virtual stack, on the left is what this thing would look like in non-virtualized world, on the right is a an example of this in ECM terms.

Physical World	Virtual World	ECM World
An application	An application	An application
A single server including the hardware, OS and apps.	A VMware image	The web server, database server or core ECM system
A gaggle of servers supporting a single enterprise application (database, app, web, core etc.) plus associated network connections and policies.	A vApp	All of the servers need to support a single ECM deployment (content database, content management server, web servers, etc.)
The replicator off the Starship Enterprise.	vCloud Manager - creates non-conflicting instances of the entire vApp. Includes VMware vShield for security.	Paying Professional Services to install, configure and deploy another instance of the ECM system.

I'm intentionally glossing over some key components of the VMware architecture which also includes desktop/application virtualization, lower level system tools, reporting plus higher level datacenter management tools. If they turn out to be relevant to the stack then I'll add them later – when I’m finished I hope to have a much more comprehensive breakdown of the stack.

Hopefully you get the general idea from this - a VM (shorthand for a VMware image) acts just like a server, a vApp is a collection of VMs bundled up with the associated network relationships and policies which can be replicated, distributed and deployed to represent a typical server collection. There are a multitude of tools used to manage all of these bits but the one that you are most likely to be interested in would be vCloud Director which lets you (or even your end users) provision and manage vApps.

The list of products in the VMware library is pretty long and I do not have time/the interest to discuss all of them but some seem to crop up fairly often so I’ll attempt to give you a single paragraph for each of these:

• vCenter - The vCenter product is still used in some cases but vCloud Director will typically provide a superset of the vCenter functionality, I’m pretty sure that vCloud Director actually makes calls to vCenter behind the scenes but I’ll have to look into this in some more detail.
• Virtual Appliances are a subset of the newer vApps. vApps contain virtual machines packaged together in a platform independent format called OVF., I'll explain more in my vApp entry later.
• vSphere - The other piece to consider is the vSphere platform which controls the sharing of processor, memory, disk space and networking on a single server host (the actual physical machine). vSphere is effectively the runtime engine that manages the VMs are they are being executed on the physical server, . Don’t confuse this with vCenter or vCloud Director which are used to provision and manage the VMs before they are executed.
• Hypervisor - In order to fool the virtual OS into thinking that it is running on a real server (it does not know it has been virtualized which seems immoral) a layer of software sits between the physical server and the VM. This layer is called the ‘hypervisor’ and it allocates the hardware resources to the individual VMs in a way that makes it transparent to the VM.
• vFabric – VMware have a suite of development and run-time tools for application development optimized for a virtualized environment. This includes Spring, Hyperic, GemFire, etc. I might not bother with these as I feel strangely drawn to the infrastructure and cloud topics not the app development.

In my next post I'll drill down one more level to look into vApps and vCloud Director and how they might relate to a typical ECM (or any other multi-server) deployment.