For those organizations on the journey of transforming their datacenters to meet the demand of a modern IT consumption model, it’s easy to envision what cloud euphoria could/should look like.  That’s mostly because vision is quite cheap – all it takes is a little imagination (maybe), a few Google queries, several visits by your favorite vendor(s), and perhaps a top-down mandate or two.  The problem is execution can break the bank if the vision is not in line with the organization’s core objectives.  It’s easy to get carried away in the planning stages with all the options, gizmos and cloudy widgets out there – often delaying the project and creating budget shortfalls.  Cloud:Fail.  But this journey doesn’t have to be difficult (or horrendously expensive).  Finding the right solution is half the battle…just don’t go gluing several disparate products together that were never intended to comingle and burn time and money trying to integrate them.  Sure you might eventually achieve something that resembles a cloud, but you’re guaranteed to hit several unnecessary pain points on the way.

Of course I’m not suggesting putting all your eggs in one vendor’s basket guarantees success.  Nor am I suggesting that VMware’s basket is the only one that provides everything you’ll ever need for a successful cloud deployment.  In fact, VMware prides itself with an enormous (and growing) partner ecosystem that provides unique approaches and technologies to cloudy problems and beyond.  What I am suggesting, however, is the need to pick and choose wisely.  Well integrated clouds = well functioning clouds = happy clouds and happy customers.  Integration means common frameworks and interfaces, extensible API’s, automation via orchestration, app portability across clouds, and technologies that are purpose-built for the job(s) at hand.  And as a bonus, integration can mean leveraging what you already have – an infrastructure awaiting the transformation of a lifetime.  That’s right, the cloud journey should not be a rip-and-replace proposition.

There’s another major component to this – while I spend the majority of my time helping organizations and federal agencies adopt the cloud and transform their infrastructures, there’s often something else on the customer’s mind that can’t be ignored.  It’s a long-term strategy delivered in nine datacenter-shattering words: “I want to get out of the infrastructure business”.   I’m hearing this more often than not and it cannot be ignored.  What they are referring to is the need to eventually shift workloads to public clouds rather than continue to invest in their own infrastructures.  This strategy makes perfect sense.  As the adoption of public cloud services increases, more and more CIO’s are finding new comfort levels in handing over their apps and workloads to trusted cloud providers, albeit slowly.  But this also introduces new challenges.  How does an organization well on its way to delivering an enterprise/private cloud to the business ensure that future adoption of public clouds does not mean starting from scratch?  What about managing and securing those workloads just as you would in the private cloud?  Public cloud providers need to be an extension of your private cloud, giving you the freedom of application placement, the ability to migrate workloads back and forth, and providing single-pane-of-glass visibility into all workloads and all clouds.  This endeavor requires the right planning, tools, and frameworks to be successful.

Here are the top “asks” from customers currently on, or getting ready to start, this journey (in no particular order):

• Private cloud now…public cloud later (or both…now)
• Workload portability (across clouds / cloud providers)
• A holistic management approach
• End-to-end visibility
• Dynamic security
• Cloud-worthy scalability

If any of this is resonating, then you’re probably in a similar situation.  CIO’s are pushing the deployment of private clouds while simultaneously considering public cloud options.  Therefor the solution needs to deliver everything we know and love of the private cloud while laying down the framework for public cloud expansion.  Problem is not many solutions out there can do this.  Public cloud providers often run proprietary frameworks and management tools to keep costs low and private cloud solutions are generally focused on just that (being private).

Enter VMware.

VMware has put a lot of effort in leveraging the success of vSphere – the cloud’s critical foundation – to help take a controlling lead up the software stack and deliver a cloud solution for both private and public (i.e. hybrid) clouds.  And through the VMware Service Provider Program (VSPP), they have also enabled a new generation of cloud service providers that build their offerings using the same vCloud frameworks available to enterprises.  As a result, each and every one of these vCloud-powered service providers instantly becomes a possible extension of your private cloud, placing the power of the hybrid cloud – and all the “asks” above – at your fingertips.

Here’s what that looks like from a 1,00ft view…

Let’s review this diagram:

1 – Physical Infrastructure: commodity compute, storage, and network infrastructure.

2 – vSphere Virtualization: hardware abstraction layer and cloud foundation.  Delivers physical compute, storage, and networks as resource pools, datastores, and portgroups (or dvPortgroups).

3 – Provider Virtual Datacenter (PvDC) and Organizational Virtual Datacenter (OvDC): delivered by vCloud Director as the first layer of cloud abstraction. resources are simply consumed as capacity and delivered on demand.

4 – vCenter Orchestrator: key technology for cloud integration, automation, and orchestration across native and 3^rd-party solutions.

5 – vCenter Operations: holistic management framework for visibility into performance, capacity, compliance, and overall health.

6 – Security & Compliance: dynamic, policy-based security and compliance tools across clouds using vShield Edge and vCenter Configuration Manager (vCM)

7 – VMware Service Manager for Cloud Provisioning (VSM-CP): self-service web portal and business process engine tying it all together.  Integrates with vCO for mega automation.

8 –vCloud Connector (vCC): single pane of glass control of clouds and workloads.  enables workload portability to/from private and public vClouds and traditional vSphere environments.

Last but not least is the very important question of “openness” in the cloud (don’t get me started on heterogeneous hypervisors!).  VMware spearheaded the OVF standard several years ago, which has been adopted by the industry as a whole as a means of migrating vSphere-based workloads to non-vSphere hypervisors (and the clouds above them) with metadata in tact.  In fact, OVF remains a key technology in the Hybrid cloud scenarios and is an integral part of workload portability across clouds.  OVF gives customers the ability to move workloads in/out of vSphere and vCloud environments and into other solutions that support the standard.  Just beware of solutions that will happily accept OVF workloads but not so happily give them back (warning: the majority won’t).

The end result: cloud goodness, happy CIO’s, and streamlined IT.  How’s that for a differentiator?

++++

@virtualjad

I recently had an opportunity to record a Podcast with one of VMware's valued channel partners, GovConnection.com.  During the Podcast I addressed several questions regarding the adoption of cloud infrastructures in the Federal Government.

Topics included:

• cloud adoption rates across federal organizations
• cloud technology drivers (why cloud?)
• the advantages of building out a cloud infrastructure vs. traditional IT
• recommended steps for getting started (how cloud?)
• how VMware solutions align themselves with this IT evolution

Take a listen @ GovConnection's Cloud Computing Technical Library (http://www.govconnection.com/IPA/PM/Solutions/TechnologyLibrary/Cloud.htm)

(go to "Transform IT With Cloud" and select "Listen Now")

or DOWNLOAD THE MP3

Enjoy! -- feedback welcome

++++

@virtualjad

The Challenge: You are providing cloud services for a tenant using vCloud Director (obviously!) and want to provide a dedicated [routed] subnet and firewall services that are managed by the tenant admins.  Apps deployed in this cloud will be utilizing shared infrastructure services – LDAP, patching, scanning, etc – outside the cloud, so you’re trying to avoid NAT due to possible complications introduced by masking/translating source IPs.  Sound familiar?  Read on…

The release of vCloud Director (vCD) v1.5 along with vShield Edge (VSE) v5.0 provided a significant number of in-cloud networking enhancements that put a smirk on the faces of socially awkward cloud geeks everywhere.  Okay, I’ll admit it – the networking capabilities VMware has baked into vCloud Director have been one of the most intriguing components of the solution.  The combination of vCD 1.5 and VSE 5.0, riding on top of vSphere’s native networking capabilities, provide the framework for enhanced (and industry-leading) networking options for your cloud.  Check out the vCD 1.5 Technical Whitepaper for more info on these and other enhancements.

Here are the cliff notes for those who don’t care to read the marketing stuff:

• improved network isolation at several levels within the cloud,
• enhanced firewall capabilities,
• baked-in VPN tunnels and the ability to securely stretch tenant networks across clouds,
• enhanced NAT’ing flexibility,
• the addition of static routes and layer-3 routing
  
  

Speaking of static routes and layer-3 routing (yep, that’s the best transition I can come up with), I have found many of my customers questioning what is actually possible with the use of these features.  My favorite argument of all is, “NAT does not equal routing!”.  This misconception is probably due to the confusing label of “NAT-Routed” when referring to an external org network behind an auto-provisioned VSE appliance.  That may have been the case with previous versions, but not so today.  In fact, a VSE appliance can perform basic L3 routing functions independent of NAT’ing.  I prefer to avoid NAT’ing (when it’s an option) -- and some enterprises have banned it all together across internal networks -- so this capability often comes in handy.

It seems that using VSE as a router and/or firewall in vCloud independent of NAT is poorly documented (so I’ve heard).  The following guide walks you through the use case and setting it up in your cloud...

A snapshot of my lab network:

Config Summary:

Physical (Core) Router: 192.168.1.1

vSphere Network:

• dvSwitch - dvSwitch-Core
• dvPortGroup - dvPG-Prod

Provider Network:

• External (Provider) Network: "EZLAB Prod (EXT)", 192.168.1.0/24
• Gateway: 192.168.1.1
• Static IP Pool: 192.168.1.200 - 192.168.1.249
  

Tenant (Org) Network:

• Network Pool Type: vCD-NI (VLAN 102)
• 1 x External Org Network, Direct-Connect
• 1 x External Org Network, Routed - 10.10.2.0/24
  • vShield Edge Ext IP: 192.168.1.200
  • vShield Edge Int IP: 10.10.2.1
    
• 1 x Internal Org Network - 10.10.1.0/24

So, our objective is to provide control over firewall policy, no NAT, and external routing at the org level.  To do this, we need to:

• Enable Firewall Rules (optional)
• Disable NAT IP Masquerading in the "NAT Mapping" tab
• Add Static Routes (only if needed...more on that later)

Right-click on the External Routed Org network ("Eng-EXT-10.10.2.0/24" in my case) and select "Configure Services".

Firewall: Use the Firewall tab to configure any firewall policies you desire.  This can be done at any time.  I let all the traffic flow in my lab by setting the Default Action to "Allow".

Disable NAT / IP Masquerade: Go to the NAT Mapping Tab and unselect "Enable IP Masquerade".  If checked, all outgoing IP traffic will be NAT'd using the VSE's external IP (192.168.1.200 in this example)...we don't want that.

Static Routes on VSE: You actually don't have to create any static routes unless you want to point to a network that the upstream router (the core) is not aware of.  The VSE's external interface is assigned a next-hop address of my network's physical gateway.  As long as that router knows how to get other networks, I don't have to define those routes at the VSE level.

Static Routes on Physical: Since the External Org network doesn't exist anywhere on the physical side, you will need to create a static route to it (likely at the L3 core) to advertise the route to other networks (cloud or otherwise).  In EZLAB, the physical router is configured with a static route for each External-Routed Org network.  To do this, I added a route to the 10.10.2.0/24 network using the VSE's external IP – 192.168.1.200 in this case.  Remember when a VSE device is deployed for a External Routed Org network, the external interface gets an IP from the Provider network's IP Pool…that's the IP you want to use for creating the 'inbound' static route.

All vApps/VMs deployed in this org and directly connected to this network are assigned a 10.10.2.x address and 10.10.2.1 gateway IP via the VSE's built-in DHCP server.

At this point you will have configured a External Routed Organizational Network that is protected by a Firewall policy, is accessible from external entitites, and contains no NAT.  Give it a shot, share your experiences...

+++++
virtualjad

The value proposition for a "green fields" cloud is reasonably clear — building new environment within vCloud's framework helps enterprises add all the wonderful things above while streamlining:

• Security – Integration and auto-provisioning of vShield Edge and multi-tenant security boundaries
• Governance – Integration with Active Directory at the organizational level for tight security and control
• Resource Allocations – defining resource allowances through the use of virtual data centers (ex: vDCs)
• Agility / On-Demand Resources – utilizing vCloud's allocation models to provide critical resources only as they are needed
• Cost Transparency – Integration with cloud-aware Chargeback
• Automation – using vClouds template libraries to rapidly deploy workloads within and across tenant clouds
• Efficiency – further driving resource utilization using innovative technologies, automation, and governance
• IT-as-a-Service – offering a highly automated, low-maintenance cloud infrastructure to consumers and allow IT to focus on delivering innovations that drive revenue growth

From a marketing perspective, we all know what cloud is expected to deliver — agility, security, control, etc — as well as the key characteristics of cloud computing — pooling of resources, elasticity, self-service, broad access, and automation.   But what does all this cloud talk mean to existing workloads?  I get that a lot, and most recently from a customer that forced me think about a good response (and not a packaged/salesy one).  The question was, "Why should I move my existing/virtualized workloads into the cloud?".

The reality is most of the characteristics listed above can be immediately recognized once a workload is migrated to "live" within the cloud.  The exception is the self-service capability since these workloads already exist and will be migrated vs. provisioned (however, an existing workload can be added to the catalog for future self-service needs).  So, I came up with a few points that go beyond the marketing talk and highlight some of the value that can be immediately realized once a plain-old (virtulized or physical ->P2V) workload is migrated to vCloud...

• Migrating existing enterprise workloads into vCloud's framework means adding security, control, governance, and efficiency right from the start.  These workloads are migrated into virtual datacenter (vDCs), which are defined under an "Organization", immediately adding an additional level of security and accessibility by application owners who need it.  Users are assigned specific roles bases on their responsibilities, relieving VI admins from a lot of the daily tasks associated with managing user workloads.  This also adds a level of organization by containerizing workloads (i.e. vApps) into one or more virtual datacenter and organizations.

• Migrating to vCloud means consumers of these resources don't need to understand the concepts of cloud — they are simply given a URL to access for provisioning, administering, and maintaining their applications.  Additionally, the apps can now be accessed while "on the wire" or totally isolated using vCloud's integrated console access.  Traditionally, if a server is unplugged or otherwise isolated, users lose the ability to remotely administer it.

• Migrating to vCloud increases resource efficiencies by allowing the business to determine which resource allocation model is suitable for the cloud workloads.  Both "Allocation Pool" and "Pay-as-you-go" resource allocation models allow over-commitment of resources across the infrastructure while still guarenteeing service levels at a per-workload level.  The addition of external tools like vCOps helps drive these efficiencies by maximizing resource utilization. Also, building a multi-tiered cloud can further drive costs down by providing varying levels of performance and availability to the appropriate workloads.

• Migrating to vCloud adds much-needed governance from the moment the workload is powered up within the vCloud framework.  vCD gives cloud admins the ability to set quotas and lease/expiration policies to ensure only valid workloads are utilizing resources.  These policies can also be tied into a Chargeback model that allows the consumers to make decisions based on cost and resource availability within their cloud.

• Migrating to vCloud and included vCloud Connector components allows you to take static workloads and transfer them to other clouds in the enterprise — or external/public clouds — with ease.  The ability to transfer workloads from datacenter to datacenter is a capability that will help any enterprise make the most out of its datacenters…shifting workloads to where resources are available, avoiding outages during planned maintenance periods, or providing a one-step migration of workloads.

...enjoy.

++++

@virtualjad

Using dedicated resource accounts to authenticate server and network services has been a best practice for as long as I’ve been in IT. This guideline adds security, interoperability, and governance to your deployed applications, independent of standard user (or admin) accounts. We understand why it’s good to follow these guidelines but if you're anything like me, maintaining all the resource accounts, passwords, and the services they run can become a bit challenging over time. Rather than create an account and unique password per service, some admins use the same one for everything – windows/linux services, logins, UI’s, connectors, you name it. Although this adds a bit of convenience, it's a BAD idea from a security perspective. Here’s the real challenge – keeping track of all those accounts, where they are plugged in, and the password cycle they're on. This can become quite the headache; especially considering an expired or changed password can result in a significant service outage...another reason to avoid a single service account (i.e. single point of failure).

I recently had a customer run into a very similar problem. This customer has 5 independent vCloud implementations across the enterprise, each environment with a single resource account used for the entire stack. All was well until there was a sudden need to change passwords for all resource accounts. Being a new implementation, the customer had no idea 1) what services have account dependencies and 2) where account updates need to be preformed. They had a right to be confused -- neither of us could find a comprehensive reference to this information (sure, we could have documented everything during build-out, but we all know how that goes). And that brings me to the objective of this post...it's not to suggest ways to manage your accounts and passwords, but rather to provide a reference to where passwords edits would need to be made in the vCloud stack.

The VMware vCloud stack is all about interoperability and uses several points of authentication to communicate with various components in the solution. Per best practice, I recommend creating dedicated service accounts for each major component. In an enterprise vCloud deployment this may include vCloud Director, vCloud Request Manager, vShield Manager, vCenter Chargeback, vCenter Operations, vCenter Orchestrator, vCloud Connector, and the core vSphere components. Even if you choose to use a single service account for the entire stack (vs. per component), there are a dozen or so locations that would require an edit once that account's password is changed. I keep a [password-protected] cheat sheet of all my resource accounts, passwords, and expirations...with reminders set appropriately. I've seen others use password lockers, vaults, and even smartphone apps for reference. All good methods...just make sure they are well secured.

The following is a list of vCloud components, their relationship to other services in the stack, and the account/password location(s) that would need to be updated if/when you make resource account changes...

++++

vCloud Director: vCenter

Location: vCD -> Manage & Manager -> vCenters -> vCenter Properties (right-click on vCenter)

++++

vCloud Director: Active Directory / LDAP Connector

Location: vCD -> Administration -> LDAP

++++

vCloud Director: SMTP Settings

Location: vCD -> Administration -> Email

++++

vCloud Request Manager: Active Directory

Location: vRM Admin -> Integration -> Sources -> Cloud Director (this might actually be using the vCD local admin account)

++++

vCloud Request Manager: vCloud Director

Location: vRM Admin -> Integration -> Sources -> Active Directory

++++

vShield Manager: vCenter

Location: vCenter -> Home -> vShield (under "Solutions and Applications") -> Settings & Reports -> Configuration tab

++++

@virtualjad

There's a right way and a wrong way to install VMware's vCloud Director (vCD). Identifying the wrong way is quite simple -- it just won't work. There's actually a lot more to that -- caveats, best practices, redundancy, add-ons -- which I will cover in the next post. For now, we'll focus on what you need before the install. 

Installing vCD can be a daunting task if you don't have all the prerequisites in place prior to rolling out the goods. Below is a quick list of to-do's and links to the associated resources. The actual install of vCD is the quickest part of this entire process assuming all these pieces are in place. Do this right and the rest will be easy as pie...

VM's (OS Requirements):

Getting Started:

I'm not going to detail the installation of vCenter Server and ESXi -- hoping you've got that down prior to tackling vCD. If not, there are several how-to videos and guides out there to walk you through the process. Start with these two videos on YouTube - Installing vSphere 1 of 2, Installing vSphere 2 of 2. A prerequisite for installing vCD really should be a solid understanding of vSphere and a high comfort level of vCenter management. It won't be impossible to continue without that, but it would make things a whole lot easier.

Preparing vSphere:

vCD requires that the hosts being used to provide resources for the Provider vDC (PvDC - the aggregate pool of cloud resources) are in an HA-enabled cluster and a fully-automated DRS policy. As a best practice, build separate clusters for Management and Cloud Resources. The Management cluster will need no more than 2 or 3 hosts to support all the core VMs running this vDC (vCenter included). The Cloud Resource cluster (call it whatever you want) will be dedicated for vDC resource allocations. This cluster (or multiple clusters) becomes the root aggregate of resources that you will make available to cloud tenants. Prior to tying vCD to your vCenter instance, make sure all your clusters and hosts are configured properly, have access to the appropriate networks and storage, and configurations are consistent across all hosts within a cluster. This will also be a good time to build out your dvSwitch(es) and so on.

This is all a good time to license everything. vCD itself is licensed at first login after the install, but vCenter, ESXi hosts, and vShield Edge for vCloud are all licensed via the license management component within vCenter (accessible via the vSphere client). Trust me, get licensing out of the way to prevent head-scratching issues later.

Preparing the RHEL x64 VM for vCD:

Be sure the vCD VM is configured with 2 vNICs -- 1 for HTTPS (web) access and the other for the ConsoleProxy (I'll get into that in more detail in Part 2). Each should have it's own static IP. Be sure to install the VMware Tools prior to moving on to the next step. If you need help doing this, see the YouTube how-to guide.

There are some dependant packages that need to be installed to support vCD. I'd recommend first running an update to make sure you're at the latest patch level. Log in as root and run the following in a Terminal window:

yum install alsa-lib bash chkconfig compat-libcom_err coreutils compat-libstdc++-33-3.2.3 findutils glibc grep initscripts krb5-libs libgcc libICE libSM libstdc libX11 libXau libXdmcp libXext libXi libXt libXtst module-init-tools net-tools pciutils procps sed tar which compat-libcom_err

Note that these packages are also required for Oracle 11g on RHEL if you go down that route.

We're not going to tackle any of the "Optional" components in this post. I will have detailed install instructions for vCloud Connector, vCloud Request Manager, and Chargeback in future posts. Once the prerequisites are in place, you're ready to move on to the vCloud Director install. That process will be highlighted in Post 2 of 2: "Installing vCloud Director".

Prior to moving on to the install, be sure to review the vCloud Director 1.0.1 Installation Guide. The guide will step you through specifict environmental prerequisites (OS/DB permissions, versions, roles, etc.).

Enjoy! And please provide feedback if you get stuck along the way.

Post 4 of 6: xBlock- Designing a Repeatable Architecture

I have lost count of how many pre-integrated infrastructure offerings are now available through the various software, network, storage, and compute partnerships out there – all competing for their stake as your cloud’s foundation (for those who still think ‘the cloud’ is a hardware offering with some antiquated management slapped on top, please reexamine the definition of cloud). A well-designed infrastructure is a great (and required) start, but software is where the magic happens…but I digress. Whether it’s a vBlock (EMC, Cisco, VMware), FlexPod (NetApp, Cisco VMware), Dell’s vStart, or any of the dozens of combinations out there worth mentioning, one thing holds true…all (well, most) are examples of what a robust reference architecture can do for your cloud. Sure each offering will add it’s special sauce as a value proposition – proven, pre-engineered, specialized, best-of-breed, etc. – but, more importantly, these solutions provide the core components for your cloud’s infrastructure – Storage, Compute, Network, and the glorious Hypervisor – and use the Lego approach for scaling the infrastructure out as needed.

Scale Happens.  Cloud infrastructures are meant to be elastic, agile, and designed to scale beyond your wildest imagination. [insert joke about the company that markets the “cloud in a box”]. Hint: rhymes with “poracle”. Using the right tools and technologies, the idea is to build small and scale big – to cloud scale – as the demand for resources grow and without the need to reengineer your infrastructure at each growth iteration.

Block-based architectures give IT departments the ability to seamlessly add the needed resources to the cloud without adding unnecessary complexity or spending more time than necessary on hardware integration. This is a tough task considering the latest and greatest chipset will become yesterday’s technology by the time I publish this post. Fortunately, we can plan ahead to avoid headaches in the future by utilizing vSphere’s ability to turn hardware into a huge aggregate of [compatible] resources and a cozy layer of abstraction between hardware and your workloads. Plan ahead and enable vSphere’s built-in Enhanced vMotion Compatibility technology to allow for smoother inter-cluster scaling. Or, better yet, grow your environment one full block at a time – by simply adding another cluster of compute, network, and storage resources to your cloud infrastructure.

Unless you know exactly what your workloads look like today and have planned for (and prematurely invested in) all the possible growth for the next several years, you will need to scale. The idea of block-based architectures is simply add another block and “bam!” you're in business. Now you just need your software to scale along with the hardware seamlessly with little or no interruption. With vSphere virtualizing your back-end, that’s one less thing you have to worry about. Whether for green-field or growth, block-based architectures can help you reach the levels of scale and efficiency that were once inconceivable.

Take a look at VMware's "Architecting a vCloud" white paper for some more ideas on how the block approach compliments cloud architectures.

In this Series:

1 - [insert definition here] - defining the cloud

2 - Getting Started - defining a success criteria

3 - Hardware!! - choosing your infrastructure

4 - xBlock - Designing a Repeatable Architecture

5 - Delivering IT as a service with vCloud Director

6 - Get a Grip! - managing your cloud

Post 2 of 6: Getting Started - defining a success criteria

Next topic in this series is one that can make or break your journey to the cloud -- defining what you will consider a “great success!” when all is said and done it is essential to keep things on track throughout the journey. You’ll need to set some realistic goals and objectives, get management buy-in, line up some IT/engineering resources, and maybe even get financial commitment (especially if this is usually a challenge) ahead of time. Determining where you are today vs. where you need to be ahead of time can not only accelerate the process, but will set some ground rules for everyone involved. Remember, this is a journey -- it’ll take some time and commitment but you should never lose sight of the objectives.

Virtualize: So, what are your objectives? I’ll assume they are business-driven, a directive of sorts, or perhaps you’re at the starting line and need something to pitch because you know how the business will benefit with a cloud model. We’ll knock out the must have’s: reduce cost and overhead, be ‘green’, take control (of your infrastructure), simplify and centrally manage IT, and improve usability. For some of you the primary objective is to be/stay competitive. There is one word that sums all of this up -- efficiency! At the end of the day it’s all about efficiency and this should be number one on your list of objectives. If your infrastructure is more than 50% virtualized you’ve got the right idea. If you are under 50% or starting from scratch, you’ve got some additional work to do...more on how to get there later in this series (hint: say no to physical provisioning). IT efficiency is key to success and happens to be the number one business driver behind virtualization and cloud computing. It’s also the best way to get management buy-in (the ROI pitch certainly helps accelerate adoption). And, of course, there’s everyone’s favorite initiative - Green IT.  Virtualization and consolidation are key to Green IT. It doesn’t take a lot of math to determine the energy savings you will realize when you go from 1000 servers to 100. The green priority can vary from being a driver of virtualization to simply a nice side effect. In terms of cloud, it falls under the overwhelming need to be efficient. From this point forward any new workloads should be virtualized...and you should have a plan in place by now for any existing physical workloads – we’ll call those “legacy” for the sake of making a point.

Standardize: Next on the list is Standardization -- standardizing reduces overall fragmentation, management burden, complexity, and ensures your workloads will play nice between internal and public clouds or cloud providers. In the context of cloud, the standardization we’re mostly interested in occurs above the host hardware abstraction layer. Virtualizing your infrastructure adds a bit of vendor agnosticity - compute, storage, and network are simply resources up for grabs (a controlled grab, of course). Although it is important to consider deploying a (standardized) repeatable physical architecture for ease of scalability, the focus here is to standardize the services, process, and policies within the cloud. Services will include Infrastructure (IaaS: vCloud API, OVF), Cloud Application Platform (PaaS: vFabric), Desktop(DaaS: View, ThinApp), and Software (SaaS: Zimbra, Directory Services) among others. Process standards include the delivery and provisioning mechanisms and even workloads themselves, such as using a standard set of “master” templates. We’ll touch on the need for these services to be made available through self-service catalogs, be auto-provisioned, and centrally managed later. Standardizing will ensure your cloud will be manageable as it scales and will help you keep control of variations that have to be maintained individually.

Automate: So what's next? What good is an ultra-efficient and standardized virtual architecture if you haven't adopted a modern means of provisioning the workloads running on it? Once built, you want to enable authorized end users to be able to self-provision needed workloads based on a predetermined set of criteria, authority, and service level requirements. The reaction I normally get when I stress the importance of end user enablement is, "Why would I let end users provision their own workloads??". Understand the end user can be anyone from a customer to development engineers to support personnel. Ultimately, the decision of who has access to which resources is up to the business and system administrators. Each use case will require an assessment to determine the proper access controls…but I digress.

Automation is alive and well in your virtualized infrastructure today. With vSphere hypervisor (ESX/ESXi) under vCenter management, chances are you have already taken advantage of automation tools such as DRS, HA, template provisioning, cloning, host profiles, etc. All these tools provide the ability to be more hands-off than ever before. But we're talking Cloud here -- you need to automate as much as possible to increase productivity, reduce time to deployment, and continue to drive down the costs of operations and maintenance. Taking automation to the cloud will include delivering an interactive user interface, providing point-and-click access to pre-built workloads (OS's, applications, vApps), and delivering all these workloads in a service catalog offering. Once built based on the needs of the business, the service catalog provides a one-stop shop for application provisioning and deployment across however many organizations you need to support. Once provisioned these applications will need to find a home and have access to the appropriate compute, network, and storage resources -- perhaps based on a set of predefined SLA's or security requirements. Automating the placement of workloads across varying tiers of resources (resource pools) ensures your customers get the level of service they are paying for. Utilizing vSphere virtualization and cloud-centric tools, such as vCloud Director, will help you achieve new levels of hands-off automation that will continue to drive efficiency up and costs down.

Manage: Management is about taking the business processes that may already be in place in a typical datacenter and adopting them to the cloud. It will be more important than ever before to understand what your workloads are doing, what your capacity trends and needs are, how resources are being consumed, and who is consuming them. Implementing capacity management tools will ensure you stay one step ahead of the resource requirements by providing detailed resource consumption information and trend data. Tools such as VMware CapacityIQ will also help you understand where you may have to make some adjustments, plan next year’s budget (my favorite), or determine what taking on new business means to your infrastructure.

A private cloud may include many different sub organizations (business units), which can be managed as a single enterprise entity or independently based on the needs of the business. This is common in large enterprises with many sub-orgs that haven’t been able to figure out how to function as one. But that’s okay – consolidating IT services doesn’t mean consolidating business functions if that isn’t in the books. The use of virtual organizations and logical segregation of resources will help deliver IT as a service across all BU’s without compromising data integrity. The goal here is to consolidate resources but maintain each sub organization as it’s own entity – with its own SLA’s, access controls, and processes. This is all accomplished by using built-in security capabilities and policies for secure multi-tenancy, resources pools for resource guarantees, SLA definitions, etc. But that’s only half the battle – in order to support multiple organizations, which may have varying SLA and resource requirements, you need to understand the costs associated with each. Take advantage of Chargeback tools, such as VMware’s vCenter Chargeback, to pinpoint the costs associated with resource guarantees or levels of service. As the private cloud provider, you may offer multiple levels of service with different cost structures. You can then charge for those SLA’s or, at the very least, report back to the CIO what each org is consuming at varying levels of granularity. And there’s a side effect -- attaching a dollar amount also helps prevent VM sprawl and unnecessary consumption of resources. Having the right management tools on hand will ensure you have a grasp on what your cloud is doing, will help you determine how and when to scale, and helps provide all the appropriate documentation and trend analysis needed to justify growth.

Optimize: And now for the final success criteria – Optimization. By now it seems you should be optimal, right? Well, you’re close but you may have a little more to do depending on your objectives and scope. We have focused on the success criteria associated with a single cloud delivered from a single datacenter. Optimizing sets you up for delivering services across multiple clouds sourced from beyond the boundaries of a single datacenter as if it is one. If delivering service levels to your customer means you need to take advantage of resources in your Washington datacenter, you should certainly be free to do that while your Miami datacenter is servicing other workloads and customers. You should also be able to move those workloads to another private cloud or even a public cloud provider as you see fit. The end user needs access to workloads and resources – who cares where those workloads are physically located. Optimizing the cloud helps control SLA’s, costs, security, and performance levels. Whether or not you’ll be delivering cloud services from multiple datacenters, optimizing the cloud ensures you can get there when you need to.

In this Series:

1 - insert definition here - defining the cloud

2 - Getting Started - defining a success criteria

3 - Hardware!! - choosing your infrastructure

4 - xBlock - Designing a Repeatable Architecture

5 - Delivering IT as a service with vCloud Director

6 - Get a Grip! - managing your cloud