MemorableURL.com

Cloud Computing Business Considerations - Compliance to Regulations

Is moving regulated content to the cloud really an issue?

I’ve worked in product management of enterprise software for about 10 years now including heading up the EMC Records Management group for a while so when we started looking at the security implications of moving our systems to a cloud delivery model I was skeptical to say the least. Why? Because a move to the cloud surely means that you are putting your company’s assets out where any decently equipped hacker can access them without breaking a sweat...doesn’t it?

As we worked through the choices of cloud architectures it became apparent that actually a move to the right cloud-based system with a cooperative vendor could actually reduce your compliance exposure. Don’t believe me? Read on.

We have to start by separating cloud solutions by “available connection points”. That is, what is your cloud solution connected to? The public internet or directly into your secure corporate network? It is important that you understand this differentiation because it will have a huge impact on your risk profile after deployment.

Comparing Public and Private Cloud Solutions

• A public cloud solution is plumbed directly into the public internet; typically anyone can go to www.SomeCloudURL.com and access the cloud solution. This makes it ideal if you want public access but remember that this means that although your target audience can easily access the systems, so can those hacking miscreants.
• A private cloud does not have a public address; it is plumbed directly into your existing corporate network via a secure connection, (VPN for example). Only people inside your corporate network can get to those services.

Moving to a Public Cloud Solution

I am not going to say that a move to a public cloud-based solution will never work for content that you need to protect but I will say that your considerations to protect the data will be far more arduous. You will have to assume that undesirable types absolutely will get into the system and you should build your protection based on that premise.

I am actually not going to pretend to be an expert in enforcing this level of security, instead I am going to focus in on the approach that we took which is to remove the public access point and deploy solutions as a private cloud. This works well for enterprise systems that are typically used by internal people or integrated into existing internal systems.

Moving to a Private Cloud Solution

If your cloud service provider connects your instance of the solution directly, point-to-point, to your data center using a dedicated, secure connection then you have a cloud solution that is effectively just an extension of your existing data center, your current security model and your internal network. If the provider is flexible and will work with you on the connection, security, monitoring, authentication, etc. then the polices that you already have in place for protecting data, authenticating access, regulating the distribution of content etc. can often be used as-is. You get the benefits of the cloud delivery without giving up security.

In fact, the only significant thing that really changes when you move to a private cloud based solution is where the content is being stored. If you work for a large company then you already have data being stored in many locations – backups, remote servers, laptops, smart devices, etc. At least with a decent private cloud provider you will know where it is.

When you position it like this the move to an off-premise deployment does not seem quite as scary. In fact, if your service provider can illustrate how the content is protected from unauthorized access and you are ok with the location of their storage/backup then the move could easily enhance your compliance.

Access to protected customer data.

I’m calling this out as a specific topic because it is a recurring concern especially in some regions. As an example let me paraphrase HIPPA, you “must make reasonable efforts to disclose, only the minimum amount of health information needed to accomplish the intended purpose”. We translate this to say that only authorized people should have access to the health information and that they should only get to see what they need to see.

If your system can be accessed by administrators from your cloud service provider then you need to ensure that those admins have only the appropriate level of access to that health information. What is an appropriate level of access for them? None would seem like a good level. So you need to ensure that (1) the system admins cannot access the data and (2) if they do then you are notified of the breach.

Before you start to panic take a look at the sentence above,”If your system can be accessed by administrators from your cloud service provider…” and now replace “cloud service provider” with “internal IT department”. HIPPA doesn’t say that it is OK for your own internal IT department to see my medical data. Your HIPAA compliant application must already know how to protect data from your admins; it must be providing security and encryption levels to protect data from your own admins. You simply need to ensure that same protection is extended to the service provider.

You may need to ask your service provider to show you their processes to see how they will audit any attempts to bypass the application’s security but as long as the application can enforce the regulation then the move to the cloud should neither add to nor remove any of these controls.

So that’s it?

Pretty much, as usual the devil is in the details but remember that a move to the cloud is never going to solve any of your compliance issues, just like upgrading your hardware or network switch isn’t going to. Your compliance challenges will typically be solved by the application and your processes not the location of the servers.

Connectivity - Client, server and user locations

This entry is part of a series of postings that consider the challenges of deploying enterprise software into the cloud. I added this topic to the list because it does not really fit into one of my original categories. The topic relates to where you might deploy each part of a stack from end user to core servers and how that might affect the performance of your systems.

One concern that people often bring up is that moving any part of an enterprise deployment model into the cloud will naturally cause degradation in performance because of increased latency. In reality this is not always the case. Read on...

The Non-cloud Model

Think about the deployment of an enterprise system with a thin (web-based) client to a user sat in the office in the same building as the data center.

In the conventional (non-virtualized/non-cloud) deployment model the core system server and the web application server will be positioned very close to each other. Often they will be physically in the same data center with a fat umbilical cord of fiber linking them together. So very little latency there and no real bandwidth issues either. The end user connects to the local application server from her office and it serves up the client application into her browser.

The Perceived Cloud Model

The concern comes from taking the core server and web application server out to “the cloud”. Now those servers are in some undisclosed remote location. Now consider what happens when the user navigates around the repository and finds a nice fat 120MB PowerPoint presentation to download. That file needs to get from the web application server to the user’s desktop over the ether. Now she has latency and bandwidth challenges up the wazoo (technical term). The 120MB presentation is going to be downloaded lock, stock and barrel to the user's local desktop. Once it has all made it down (no byte streaming a PPT) she can open it.

It is the addition of this WAN layer into the architecture that concerns users of enterprise systems.

The Reality of the Cloud Model

Take the same business requirement: the user needs to work on her 120MB PowerPoint presentation which is on a server in the cloud. But now add something else that the wonderful world of virtualization gives us - virtualized desktops.

With a virtualized desktop the user uses a client application to connect to the instance of a desktop that is actually running on a server in the data center. The user sees that desktop and can interact with it from her machine but the OS and applications are actually running on the machine in the data center. In this image the user is actually using an iPad but the virtual (remote) desktop is running Windows.

All the user gets on their local machine is a "screen painting" of what is happening on the virtual desktop. So when she opens a 120MB PowerPoint file now it is actually transferred to the virtual desktop (which is running on a server in the data center) and opened there. The user sees the PowerPoint file open in seconds and can edit it, can email it...she can do everything that she would normally without the file ever moving across the ether to their machine.

Summary

So, why don’t we just virtualize all desktops? In the world of “choice computing” this might be a reality sooner than you think but don't get me wrong, there’s a litany of pros and cons to this approach. As well as performance there are other positive implications in security, desktop management, virus control, etc. However it might not work for everyone. I'm sitting on a United flight to Australia right now and there's no WiFi on the flight so I can't access a virtual desktop at all, also if you need very high fidelity or need to interact with files on your local machine then today’s virtual desktops might not work for you.

The balance of virtual desktops vs. local thick clients vs. conventional thin clients is going to be a balancing act for a while but for sure the virtualization of the client can make the cloud deployment model a reality for applications where it just may not have made sense in the past.

Customized Solutions in the Cloud

This entry is part of a series of postings that consider the challenges of deploying enterprise software into the cloud. Specifically, how to customers can solve their unique business problems in the cloud. Normally customers will customize their environment to suit but the cloud is an environment that typically does not tolerate customer-specific customizations.

As usual this is a balancing act. If you can take the cloud solution “as-is” and just configure it then you are in the best place from a technology and risk perspective. If you can isolate your custom processes outside of the core cloud offering then you can still leverage the benefits of the cloud but still have your custom processes. If you have to customize the core solution then you may have to stop calling it a “cloud” solution and call it an “managed service” or “hosted” model; not as sexy on your resume but a more accurate representation IMHO.

Why does the cloud create a customization issue?

Technically it isn’t the “cloud” or even multi-tenant models that cause the issue. It is the fact that the cloud provider wants to manage a large number of systems ‘en masse’. Specifically, they want to be able to push out updates, patches and performance enhancements to all of the systems without any risk of something in a specific instance breaking.

This does not just increase the hosting company’s profit margin it also gives you a much higher quality end product. How? If hundreds customers are all using exactly the same stack of software, at the same patch level and on the same hardware configuration then the chance that you will find an environmental bug is much lower. Also, the software developers will typically develop the code, do QA and benchmark on that exact stack so you have the most optimal environment possible.

So, we have established that the cloud provider wants you to run on a predictable platform. What does that mean from a practical perspective?

Customization vs. Configuration

People a lot smarter and more eloquent than I am have explained the difference between configuration and customization, usually around "writing code" vs. "using an admin client or changing XML files". However, in this case the difference is a little more specific. For the cloud, a configuration change is something that will not change the service provider's ability to manage the environment in a predictable way. However, a customization is something that removes that predictability.

The Problem with Customizations in the Cloud

An example of a customization might be custom code that writes to a non-standard database table or bypasses the standard APIs to perform operations using direct service calls.

• Writing to non-standard database tables: As the cloud service provider I have standard processes that backup the database tables...at least all of the standard ones. If my scripts don’t back up your tables and you need them to be recovered then you’ll be mighty upset. Even you adding a non-standard index to a table could be enough for one of my performance updates to take down your system.
• Bypassing supported APIs: The cloud provider’s contract with you is probably that they will document all API changes, give you fair warning before they start to deprecate functions etc. That contract only relates to the supported API set, they can change other private API calls without telling you.

Remember that in a multi-tenant model if you take down your system by bypassing these controls then you could also be taking hundreds of other systems down at the same time so the service provider is unlikely to make exceptions.

Your options: configure, customize or try something else.

Configuration:

By far the best model is to move to a configuration-driven solution. This should include configuration components for clients, server services and admin tasks. Vendors moving their solutions to the cloud cannot continue to rely on the model where they “are an open, fully extensible, platform for your custom applications”. To survive, vendors need to wake up and to start to support complex, business driven and predictable configuration-only models.

Customization:

I think that vendors need to make a call here.

1. Don’t support customizations – this restricts what your customers can do in the cloud but supports a low cost model.
2. Allow customizations but know that your cost to manage the services just increased exponentially and involves a lot of professional services work.

The latter model is closer to a managed service than a typical cloud deployment.

Something else:

This is the area where there’s the most latitude and opportunities for some creative thinking, maybe just until the configuration models mature.

Ideally, we are looking for a model where the customer gets his/her customizations but the cloud service provider still gets the predicable, uniform environment to manage.

Isolation:

The core cloud offering runs without any custom components/services but it communicates with a custom environment that includes all of the customer’s specialty code. The cloud provider can manage the core environment en masse and then someone (the cloud provider, partner or customer) is responsible for ensuring that the isolated custom pieces survive any changes to the core system. This model can work well in many cases but is predicated on the custom code not needing to run on the same servers as the actual core systems. This can work especially well for custom clients and interoperability with 3^rd party systems where the delineation is clear.

Certified Customizations:

This sounds good in principal but the reality is a little less clear. In this model the cloud service provider will publish a guide to the operations and behavior that can be tolerated in a customization. A 3^rd party (e.g. the customer or a partner) will build the custom code to that specification. An audit of the source code will be carried out which will ensure that only supported actions are being taken.

In theory, this means that the code will support the en masse management while also giving the customer the custom behavior that they need. So why isn’t this a clear winner?

1. It is expensive to carry out the certification process.

2. The process is not always 100% reliable at finding potential trouble spots.

3. Partners/customers may not be comfortable handing over the source code to the service provider for the audit.

4. In many cases the custom code will make calls to third partner components that are not available to be certified.

OEM the Cloud:

In this model the cloud service provider makes available the core product offering to a partner who then builds their solution on top of that. The partner is then responsible for delivering the end solution to their customers. They take the updates from the cloud service provider and certify that they will not do any harm to their end product before implementing them.

Conclusion

As I said at the start, this is a balancing act. If you can take the cloud solution “as-is” and just configure it then you are in the best place from a technology and risk perspective. If you can isolate your custom processes outside of the core cloud offering then you can still leverage the benefits of the cloud but still have your custom processes. If you have to customize the core solution then you may have to stop calling it a “cloud” solution and call it an “managed service” or “hosted” model; not as sexy on your resume but a more accurate representation IMHO.

Cloud Computing Business Considerations - Overview

What are the business issues that you need to consider when moving corporate assets into the cloud?

In 2011 when we started the project to move the EMC Content Management products into the cloud the list of issues to be resolved seemed daunting and only vaguely defined. I started blogging about each of the issues and just recently realized that my list of issues was really not so daunting after all. I just posted an article about the encapsulation of all of the issues. I also posted a number of articles about virtualization of enterprise systems which you might find enthralling.

Rather than overwhelming you with all of the issues I’m turning this into a simple list of the articles that you might be interested in…

	The single most important document
	Pricing Models
	Compliance to Regulations
	Dealing with Data Center Placement
	Client, server and user locations
	Customized Solutions in the Cloud

If you’re looking for the original list then here it is or I’m sure that Google will have it cached from pre July 2012.

Core Business Issues: Service Level Agreements, Pricing, Liability/Insurance, License ownership, Compliance to Regulations, Exit strategy,

Initial Implementation Issues: Data Center Placement, Services, Migration, Connectivity - Client, server and user locations, Connectivity - Enterprise applications, Customizations

Day-to-day Management: User (de)provisioning, Monitoring, Location issues, Backup, HA, DR, Patch management, Environment management,

Mobility and the Cloud

So this topic came up in one of the sessions at the Cloud Computer Expo during a Terremark session and I think that it stands alone for those of us in the enterprise software space.

When you say “Mobility” in the context of clouds people start to think about moving VMs between environments but if you accept that all enterprise clouds will have some element of hybridity (wow, that’s a real word!) then you have to accept that there will be differing levels of mobility depending on what you are looking at. You are going to have systems in the cloud and systems on premise and they are not going to work in isolation.

Here’s my swag at a list of potential mobile elements.

• VM images – infrequent. You don’t want to move these puppies around other than in a very controlled fashion. Movement between dev, test and production or from on-premise to off-premise during initial deployment perhaps. Moving VMs because you change cloud vendors is rare and probably not a good idea.
• Data objects – frequent. The chances are that data may be flowing back and forth on a regular basis. Best case (least movement) you are going to bring data back on premise as you realize that it is:
• Needed by another process
• Just became a record (formal or informal)
• Is subject to a subpoena
• Should never have been out there in the first place
• Metadata – frequent. Probably even more frequently than data objects. Imagine that you have an ERP system in the cloud but you store your attachments on premise. The synchronization of metadata about these attachments needs to be mobile.
• Log data/reporting – frequent. Not a big payload but there’s a good chance that your internal team are going to want to be able to store and analyze log/reporting data locally. If they don’t then you probably have not finished your audit qualification process yet.
• Configuration Information – moderate. Maybe it is user account information, group membership, policy changes…whatever it is you will have to be able to push/pull this on a periodic basis.
• Software (patches, etc.). Oh yes…depending on the model, someone needs to push changes out to the actual enterprise software.

Is this a comprehensive list? Have you ever seen a comprehensive list from me? I’m guessing that you get the point though; you will probably never see a real ‘Cloud only’ deployment of enterprise software and the thing that makes it hybrid is that relationship to the other systems. Why never a ‘Cloud-only’ enterprise deployment? Because by definition enterprise software means playing as part of the larger enterprise ecosystem and you don’t do that on your own.

Oh, the graphic? You need to be British and over the age of 35 to understand that one.

 

Cloud Expo #1: Security, Choice and Redundant Arrays of Jet Engines

I am at the Cloud Computing Expo in NYC this week...it's great to attend a conference where (1) i am not presenting and (2) I have a lot to learn about the subject matter. I'm going to post brief summaries of the sessions that I attend with an eye on how it relates to enterprise software.

Session One

I arrived half way through and passed the other meeting rooms which were sparsely attended but the session I wanted to go to was filled to overflowing. It was a session on "how to move legacy apps into the cloud". What does that tell us? Seems like people might be thinking about reengineering their apps for the cloud but in the interim we all want to get our current code lines up into the ether. Not too much to report because I missed the meat of the session. The bit I heard was a discussion about the 'best' hypervisors and how to select a vendor; annoyed that I missed the beginning of the session. Ho hum.

Session Two - War in the Clouds - Terry Woloszyn.

This was all about security and the cloud. This was interesting primarily because he took a very different approach than I'd expected. I'll summarize "if you put all of your eggs in someone else's basket then make sure that basket is secured". He wasn't talking so much about how to secure a cloud but more about understanding that a single data breach into a cloud provider can affect dozens/hundreds of dependent systems. Common sense but worth reminding people I guess.

Terry seemed fairly certain that the serious 'bad guys' were going to be attracted to the cloud because their effort to breach a cloud provider can yield much higher rewards – killing multiple pigs with one bird.

Session Three - Sam Machiz from Voxel - Why a "cloud only" strategy does not make sense.

Nice opening point - moving to the cloud is NOT a business goal...it is a deployment topology!! Your real goal MIGHT be satisfied by moving to the goal but your real goal is more likely to be cost savings, efficiency, speed to deployment, etc.

Another interesting point that hit home with my past life in compliance was what Sam called “VM sprawl”...who is governing where your VMs are and who has access to them? Who is auditing your VMs and making sure that they are being turned off and secured when necessary? Each VM is a potential silo which can contain data, metadata and processes that can represent a compliance headache.

Sam seems to be an advocate of using cloud solutions to supplement your existing on-premise systems using a hybrid deployment topology. He thinks that this works especially well for medium and large companies with existing investments in infrastructure. He also mentioned that if you are scared to put certain data in the cloud then deploy it locally but make it available to the cloud.

Session Four - Why Windows Will Not Be the Desktop of Cloud Computing by Rick German from Stoneware

Great session title if you want to get people in the room and stir up some Redmond controversy!

Rick relished the “Cloud computing is similar to mainframe computing” argument. We are bringing all of the compute power back from distributed computing into centralized computing...regardless of whether centralization is to a 3^rd party datacenter or your own. Rick questioned whether cloud computing is just marketing's answer to what to call the return to the mainframe model ;-)

He jumped into what we at EMC all "choice computing". Choice computing means that people want to use their choice of device (like my personal iPad that I am writing this on) and not the device that the company wants me to use. Delivering a Windows desktop solution for every problem isn't going to be the answer unless we virtualized Windows to every device which we will not be doing. Most of us would rather use a native app than a virtualized environment. Oh, BTW I'm not going to let IT manage the device that I purchased...the cloud needs to consider all of these factors.

His proposed answer...browser based solution. Why? The browser is pretty much the only app that exists on every single device in every single form factor. I guess that he is saying that a browser is like a hypervisor for choice devices. If you program to a browser then you are abstracted from the underlying implementations.

Seems like this wasn't a session about why Windows is NOT appropriate specifically but why we need a common deployment platform and the browser is the closest that we have so far.

One interesting thing he talked about was that systems in the future should make decisions on how to deliver an app depending on device, context, and user and then deliver the optimal service. What this means is that if you want to launch Excel the system should look at your device, bandwidth, user type, content type, etc. and launch either local Excel, web Excel, a virtualized Excel app or whatever makes the most sense. I liked this idea.

Session five - Evaluating Enterprise Clouds.

A bit of a marketing pitch for Terramark and very infrastructure focused but he did say one thing when comparing data centers to planes planes that resonated - he said that he likes to see that his plane to have "a redundant array of jet engines" before he boards. You know that the room is full of geeks when that gets the biggest laugh of the day!

Last session of the day (starting at 7:10) - How are Collaboration tools and Cloud trends coming together? Vipul Aggarwal from iGATE Patni.

Started with a way too detailed explanation of what collaboration is. I'd have to say that the speaker could have assumed that anyone attending the session would understand the basics of collaboration but maybe I'm just getting tired. Nope, after 15 minutes we are still hearing about different types of collaborative tools and reasons. More than half way in and we've learned nothing about “Cloud AND Collaboration”. The expo opens in 11 minutes and there's food there...I try not to walk out of sessions part way through but I'm probably going to have to...bye.

Conclusions

There's a lot of public bravado right now in the world about cloud computing. When you sit down in a room with a few thousand cloud people you realize that we are at the very beginning of a revolution. Getting apps to run efficiently in a cloud environment really is subtly but importantly different to just running in the Internet or on a mainframe. We are taking apps that were designed to run on individual servers but we are now co-locating multiple instances of these apps in a single environment.

I'll post more information tomorrow...really quite psyched.

Virtualization of Enterprise Systems – vBlocks

Now includes: Instructions to build your own vBlock!

vBlocks are especially confusing because the noun “vBlock” starts with a little ‘v’ so you’d think that these things were a virtual something…but they’re not, they are physical. [Ed: See Kenny's comment below for 'v' clarification] What exactly is inside a vBlock is the interesting element, according to one official document they contain “Units of IT infrastructure”…I’m sure that there’s a more vague way of describing the inner workings of the vBlock but I can’t think of one offhand!

Another description I found described a vBlock as a “reference architecture” delivered in a box. I thought that this was even less helpful until it dawned on me that’s exactly what they are:

• Let’s start with the most fundamental thing. If you buy a vBlock you’ll receive a box with something in it, not a just link to a download. It is a physical device with pre-installed software – like a Dell computer I guess but it is built to really only do one thing…host virtual systems.
• It was created by three companies – VMware, Cisco and EMC so the technology is proprietary[1]
• Basically these three companies sat down and said asked the question, “what would we deliver jointly to a customer who wanted a virtual datacenter in a box?” Rather than just writing a theoretical joint “reference architecture” paper they actually delivered the components ready to roll.

So, what exactly is in a vBlock? Rather than describing the parts in an abstract way I thought that I could build my own version using common household objects…well common in a household full of nerds. This way you’ll be able to associate the core industrial-strength components with things you are probably more familiar with.

A vBlock has five main components…the hardware bits (processing engine, the network pieces, the storage) and the software (virtualization and general management). There are three models 0,1 & 2 but we will stick with vBlock 1 as an example. The vBlock 1 is comprised of the following which I’ll demystify below:  “Cisco’s Unified Computing System (UCS), Nexus 1000v and MDS, EMC’s CLARiiON storage (secured by RSA), and the VMware vSphere platform”.

Here’s how I built the “vBlock-Chapman edition ®” compared side-by-side with the original.

Processing Power, Rack and Network Stuff

• The vBlock 1 has the Cisco Unified Computing System which includes between 16 and 32 blades of processing power, a Nexus 1000v network switch and an MDS storage interface.
• I found a AMD ATHLON II 250 3.0GHz X2 DUAL CORE BAREBONES PC on eBay ($259) and plus 4GB memory ($48). I added a 10/100M PCI Ethernet LAN adapter ($4.59) and a 4 Port SATA SERIAL ATA IDE PCI CONTROLLER ($3.99).

Storage

• The vBlock 1 has EMC’s CLARiiON storage (secured by RSA) with up to 64 TB of storage.
• I found a used WD WD10EADS 1TB Internal Desktop SATA Hard Drive for $52 inc. shipping. Mine was not secured by RSA but it was secured by two lengths of duct tape because I it didn’t quite fit in the case.

Virtualization and Management Software

• The vBlock 1 has the VMware vSphere, vCenter, UCS management, Ionix UIM, Navisphere plus some other major league tools and reporting software.
• I downloaded VMware player ($free), and SpeedUpMyPC 2011 ($29) which optimizes my memory, disk usage and ‘boosts my CPU’…according to their pop-up infected website.

Fabric

• The vBlock comes with a mass of fabric provisioning hardware and software.
• My fabric was stick on one side and consisted of 2 rolls of duct tape - I had some real problems getting all of the pieces working. I guess starting off with a reference architecture of my own might have been a good idea.

Hopefully comparing the contents of the the vBlock with what more common home PC components gives you the general idea. A vBlock is the is the hardware, interfaces, storage and software needed to run a virtual datacenter delivered in a pre-configured box.

Pricing So, my vBlock-Chapman Edition cost me $396.58 including tax and shipping. If I’d used the old PC in my closet which has onboard storage and networking then my vBlock would be sub-$100 but I wanted to level the playing fields! BTW, the VCE vBlock will cost you between $1M and $2.8M.

One small differentiator is that the vBlock-Chapman edition will probably run one small virtual machine (if you’re lucky) whereas the vBlock will run between 800 and 3,000 virtual machines so it might be more appropriate.

 

 

Note to the VCE coalition – Don’t be scared…I’m not really going into business in competition, this is just for illustrative purposes.

 

---

[1] I work for EMC but not in the hardware division – those guys seem to make some sort of big disk drives…I’m told it is more complex than that but I’m not so sure. I might check it out at EMC World just in case the idea catches on.

Virtualization of Enterprise Systems - Index

Earlier this year I started writing a series of articles about virtualization and the cloud. The aim is to demystifying virtualization by describing what it means in terms that someone who works with enterprise-class solutions would understand.

I’ve got enough articles now to warrant an index. If you want to add to the ‘to do’ list just put in a request in the comments section and I’ll see what I can do.

Primer
A high-level comparison of the physical and virtual world plus some brief definitions of key concepts - virtual images, vapps, vcloud manager, virtual appliances, vcenter, vsphere, hypervisor, vfabric, etc.
/2011/03/virtualization-of-enterprise-systems-primer.html

Deployment Topologies
A valiant attempt to draw the relationship between “cloud vs. managed services vs. hosted vs. virtualized vs…”. Includes a hierarchical diagram of the defintions.
/2011/04/cloud-vs-managed-services-vs-hosted-vs-virtualized-vs.html

Virtual Servers
More information about the what, how and why of virtualization of your servers. Read this is you are not sure exactly what a virtual server is or why you would even care.
/2011/04/virtualization-of-enterprise-systems-virtualized-servers.html

vApps
vApps are one of the key building blocks of any virtualized environment, this posting drills down into the content of a vApp and the OVF standard that defines them.
/2011/03/virtualization-of-enterprise-systems-vapps.html

Vblocks
Not only a description of what a Vblock is but detailed instructions on how to build your own and save yourself ~$2 million. (Your milage may vary)
/2011/04/virtualization-of-enterprise-systems-vblocks.html

Blind men and fluffy elephants
On its way: ‘What’ the cloud is depends on where you are standing. This article will consider what is important in the cloud depending on your point of view.



Cloud vs. Managed Services vs. Hosted vs. Virtualized vs…

Back to Virtualization and Cloud Index

It seems like vendors are intentionally blurring the lines between virtualized environments (on/off-premise), managed services, hosting and anything else that vaguely resembles a vaporous environment. I’m not surprised; no one argues that Cloud Computing doesn’t bring a huge amount of value to the enterprise…but  “defining what it is” is confusing, very confusing. So, I set out to try to build a relationship between all the different deployment topologies and then find out what the general consensus is for the name of each node.

In the diagram below the blue boxes describe that element of the topology and the red/green boxes describe what the end result is typically called.

Your job? As you hear news (like Apple’s rumored move to Cloud streaming of video) or hear about a cloud service see where it fits into the diagram. If it doesn’t then work out where the tree splits and send me the new nodes to publish. If you do the work, I’ll take the credit…OK?

My Conclusion? I think that really only the green nodes are real Cloud Computing because I want to believe that the future of the Cloud is about the elasticity not just the virtualization. I want my processes to consume zero resources when I’m not using them but to have access to massive amounts of computer power on demand.

Note: This is an attempt at aggregating other people’s definitions into a single structure not necessarily ‘my opinion’.

[Click diagram to view a version you can zoom in on.]

 
[Updated 15-Apr-2011: Got a feedback on the Private cloud. Added it to the off-premise nodes as the formal definition is a "cloud infrastructure that is operated solely for a single organization" which may be managed by the organization or a third party and may exist on premise or off premise.]

Virtualization of Enterprise Systems – Virtualized Servers

Back to Virtualization and Cloud Index

I got a comment on Facebook from someone saying that they were eager to hear more about virtualization, and specifically why they should care about VM images. Now, the comment came from one of my brothers, so it is hard to know whether he was being sarcastic or not...but it did make me think that a line or two on VM images themselves might be a good idea. Here’s my attempt at explaining a virtual machine.

So, consider your PC at home. Let's assume it is running MS Windows (the operating system). Underneath Windows there are physical things that Windows communicates with - the PC's processor, disk drives, video cards, etc. Above Windows are the applications that you work with - a browser, word processor etc.

In a virtualized environment, the pieces underneath Windows are not really hardware devices, they are specialized software processes pretending to be that same hardware. “Why would this be a good idea”, you ask? Well imagine if you wanted to have three instances of Windows running in the physical world. You'd need to purchase three physical boxes. However, in the virtual world, you could just have three instances of the virtualization environment running, albeit on a more powerful physical machine. Need another instance? No need to head off to Best Buy, just launch a new instance of the virtualization software.

These “virtual machines” fool the operating system into thinking that it is running on its own physical PC. The virtual machines behave just like physical ones. For example, you can turn each one of them on and off independently, you can install any operating system on each of them and you can install applications on the operating system for you to use.

So, hopefully you can see how we could have a single big server that has multiple virtual machines running on it. Each one of these virtual machines runs independently, in fact one could be running Windows XP, one running Windows 7 and one running Linux.

Cool trick for sure, but the question that I was asked was "why should I care?" The Microsoft and VMware marketing bods could list tons of reasons I'm sure but here are a few that I find most compelling...

Utilization efficiency

The best analogy that I've heard to describe why a virtualized environment is more efficient is to compare it to having an individual generator to power your house vs. plugging into the grid.

- If you have a generator powering your house, it is on and running most of the time but not actually supplying much power. Occasionally it maxes out when the AC, stove and sump pump all turn on at the same time. You have to size the generator to cope with that peak loading, even though 99% of the time it doesn't need to be that powerful. If you need more capacity then you'll have to buy an entire new generator.

- If you plug into the power grid instead, you are taking power “on demand” i.e. if you don't need anything you don't take anything but if you need a huge amount for a few minutes then the grid can provide it on demand.  The grid is efficient because when you are not demanding any power, someone else probably is so the overall usage curve is relatively flat.

The same goes for running Physical vs. Virtual servers. If you have a physical machine, you have to size it for the peak demands on the system, even though at times it might be almost completely idle. If you buy a big server and run, say, 35 virtual machines on it then the chances are that you will always have some virtual systems demanding resources and some sitting idle. This means that instead of having your machine running at 20% capacity, it might run at 80% - much more efficient.

Efficiency - turbo boosting

Along the lines above, bear in mind that now your piddling little VM image is actually running on a very powerful server along with a lot of other images. Now imagine that you have a process that does 3D rendering of engineering drawings – a very CPU-intensive process. When you ask for your line drawing to be rendered to 3D it will be running on that mega server, not some measly little PC...instead of taking hours, it could take just a few minutes if the server happens to be fairly quiet. In some cases, processes will be scheduled to run at times when the server is likely to be quiet.

Transportability

If I wanted to send you an entire enterprise solution stack to run a PoC without virtualization, then I'd have to raise a PO, buy some hardware, install the software, configure the applications and then have FedEx ship them over to you. With virtualized systems, I can simply send you the images of the systems and you load them into your existing VM system and get them up and running. 

Predictability

If I create a new VM image, install the OS and the applications and then do some configuration and load some sample data I can take a snapshot of that image at that point in time. Any time in the future I can start a new instance of that snapshot and it will be an exact copy of the original. This is useful in Q&A where I want to run tests on an environment repeatedly but need to remove any environmental interference from the results. It's great for PoCs, demos and for virtualizing end user desktops (a topic for another day).

Conclusion

Hopefully these all make sense. Whether you are interested in power/cost savings, flexibility, predictability, or just using the coolest fad then this should be of interest…