So the cloud hype train rolls on and we’re all constantly being told how the cloud can help cut costs, increase agility and reduce time to market. The cloud certainly has its advantages and for SMB’s and start ups with little or no ‘IT baggage’ the cloud is an attractive proposition. However, for most enterprises a transition to cloud computing is not something that should be undertaken lightly. Today, a large number of cloud solutions exist in the market place, providing great choice; but this leads to a complex decision making process. Broadly, three core deployment models exist – Infrastructure as a Service (IaaS), Platform as a Service (Paas) and Software as a Service SaaS. These models are typically provided from an internal (private) cloud, external (public) cloud or both. For more on cloud definitions and deployment models, I recommend reading this article by the National Institute of Standards and Technology (NIST).

Whichever cloud deployment model route an organisation decides to take, it needs to decide whether it wants to use a private or a public cloud, or even a combination of both. For this decision, there are lots of factors to take into account. Focussing predominantly on IaaS, below I highlight some of the factors that are likely to prohibit enterprises from taking advantage of the two main cloud types and a potential solution to those challenges.

The Public Cloud
In the IaaS space, the public cloud lends itself heavily to the SMB and start-up market because of smaller user numbers, fewer SLA’s, off the shelf applications and only basic security compliance needs. However, for medium to large enterprises, apart from SaaS, the public ‘multi-tenant’ cloud is seen as too high a risk for the majority of their systems for the following reasons:

· Security and regulatory compliance
· Lack of enterprise grade features such as DR and backup
· Lack of performance based SLAs
· Complex transitions and migration paths
· Lack of standards (portability)
· Data versus server locations
· Reliability.

Although the public cloud is generally unsuitable for enterprise production systems, there is no doubt it can be an appealing proposition for test and development environments. This is where provisioning can be achieved in seconds, security compliance is often less of an issue and the ability to scale down as well as up is commercially very attractive.

The Private Cloud
So if enterprises aren’t moving their production systems into the public cloud, how can they take advantage of the commercial and operational benefits that cloud computing promises to deliver? There has been a lot of talk over the last 12 months about the ‘private cloud’ where enterprises essentially look to introduce cloud methodologies into their own IT organisation. Unfortunately more often than not, virtualisation is being confused with cloud computing when actually virtualisation should only be seen as one of enablers for cloud.

At the recent International Cloud Computing Conference And Expo in Santa Clara, US, a number of large enterprises including the CIA presented on their approach to creating a private cloud and the challenges they faced along the way. The same underlying message came from all speakers – developing a private cloud takes time, significant investment and requires high levels of automation in order to achieve the required ROI. Some of the other challenges that can be expected are listed below:

· Initial CAPEX and ongoing infrastructure refresh
· Buy in at all levels
· Extensive planning
· High levels of automation
· Significant operational investment
· Complex tool and platform selection
· Limited in-house skills and time.

In the case of the CIA, it has the size of IT infrastructure that enables them to provide the economies of scale associated with cloud computing, whilst its strict security requirements meant its only option was to develop a private cloud.

The Virtual Private Cloud……..or why not Federate!
It would seem for most enterprises the IaaS Public cloud is still too immature and the initial capital/operational expenditure and time required to develop a true Private cloud potentially outweighs the required ROI. It’s not all bad news however, many hosting providers and Telco’s are bringing enterprise grade Virtual Private Cloud offerings to market. These offerings place the burden of Capex and Opex onto the service provider but provide the end user with utility computing aligned to needs of the enterprise.

In reality there is no one solution that fits all. Over the next few years more and more organisations will adopt a federated model, taking advantage of SaaS out of the Public cloud and IaaS from virtual private clouds

-Tom Brand, GlassHouse Technologies (UK) Virtualisation Practice Lead

With tightened budgets, businesses are constantly looking for way to see a rapid return on investment (ROI). This has increased interest in the adoption of pay-as-you-go cloud services and virtualisation technologies where the ROI can be very attractive. In recent months, Tom Brand, virtualisation practice lead at GlassHouse Technologies has found himself frequently answering the question: “What is the difference between cloud computing and virtualisation?” In Tom’s latest blog post he gives his view…

In order to answer this question it is first important to clarify what the two terms, cloud computing and virtualisation, actually mean: According to the National Institute of Standards and Technology (NIST), cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

Virtualisation is a technique used to abstract the physical characteristics of computing resources from the systems, applications or end users that interact with those resources. Virtualisation technologies typically let a single resource (such as a server, an operating system, an application, or storage device) appear as multiple logical resources; or makes multiple physical resources (such as storage devices or servers) appear as a single logical resource.

In analysing the definitions above, trying to compare cloud computing and virtualisation is similar to comparing a car to an engine respectively. A car is a complex system including parts, interfaces, inputs and an engine that function as one to provide the best and most efficient drive for the owner. Like the car, cloud computing (public or private) is essentially the coming together of technologies, operational processes and financial models to provide organisational flexibility with optimum cost-efficiency. Continuing with the automotive analogy, the engine of a car is a core component because without the engine, the car won’t move, regardless of whether there are any seats in it. With cloud computing, virtualisation is the core component enabling the majority of characteristics required to make any cloud computing model work.

Going one stage further, you can compare the cloud to a cost-effective metered taxi service, always at your disposal. You now have a range of highly efficient vehicles that can be requested whenever you need to travel. They are operated and maintained by someone else and you only pay for the length of the journey (paying-as-you-go) with the ability to get out whenever you like. Although cloud computing encompasses a large range of compute services, typically labelled as either infrastructure (IaaS) or applications (SaaS and PaaS), they all fit within the taxi model. End users only pay for the services or resources they use, the service and ability to provision is always available. Users have the flexibility to request different services however the underlying infrastructure is not their concern and cannot be modified. In summary, virtualisation improves IT efficiency - enabling traditional computing with fewer resources; whereas cloud computing improves IT effectiveness - empowering more people to build services with more flexibility and fewer experts. When implemented accurately, both technologies can provide attractive an ROI for the IT department.

One of the lingering concerns about cloud computing is determining when it does or doesn’t make economic sense. There is certainly a crossover point at which either the requirements of scale or level of service are such that the cost of the cloud exceeds that of a more traditional approach. However, determining where that point lies and the specific drivers that influence it, has been a subject of much debate.

Earlier this year, McKinsey and Company published a widely reported and much debated discussion document “Clearing the air on cloud computing” (see http://uptimeinstitute.org/content/view/353/319/ - registration required) that included an analysis suggesting that the costs for many of Amazon’s EC2 and S3 services rather quickly exceeded those of a traditional IT infrastructure when scaled to mid- to large-sized environments.

Recently, my old friend Steve Duplessie of the Enterprise Strategy Group generated a lively discussion in the blogosphere when he re-visited the cloud economics issue in two very interesting posts (see http://www.thebiggertruth.com/2009/09/reverse-cloud-economics/ and http://www.thebiggertruth.com/2009/09/cloud-economics-continued/). He points out that while a terabyte of cloud storage at $150 GB/month seems pretty reasonable, when you get to 20TB at the same rate the cost comes to $36,000/year, representing a point beyond which buying storage outright may make more sense.

Beyond quantity, the crucial factor to consider in comparing any cloud (or non-cloud) option is to understand exactly what you are getting for a given price. Most cloud infrastructure vendors currently position their services in the range of three 9’s or so (99.9 to 99.95%) of availability. For most enterprises, availability expectations for production platforms are more likely to land in the five-9’s realm, which would make the cloud a non-starter in these situations. Can this level of availability be addressed by the cloud, and if so, at what cost?

A recent Network World article (http://www.networkworld.com/news/2009/100509-pentagon-cloud-computing.html?page=2) provides a somewhat startling answer. Detailing the Pentagon’s Rapid Access Computing Environment (RACE) cloud services, production servers offering 99.999% can be had at the seemingly not so bargain price of $1200/month! Now, to be fair, the article does not provide details about what specifically is included, and I would expect that a system providing that level of availability would be highly redundant, and considering the targeted user base, incorporate a high level of security, as well.

Determining whether this price is reasonable or excessive requires an understanding of what it would cost to deliver a comparable set of services in a traditional environment – price without context is meaningless. I have no doubt that cloud providers will continue to evolve services levels and improve efficiencies, but the reality is that making a smart cloud decision depends first and foremost on a strong understanding your own costs and delivery capabilities.

-Jim Damoulakis, GlassHouse CTO

Identity and Security Management

One of the big challenges sharing data between companies—for example, from your enterprise to an external cloud provider—is security management (authorization, access, and identity management).

In a traditional, campus-wide IT network, security rules and roles are relatively straightforward when tied to a directory service such as Active Directory or LDAP. In a single domain model (what Microsoft now calls an Active Directory Forest), the directory service provides semantics and tools to authorize and delegate access to remote sites and sub-domains; location semantics for managing remote sites and remote access are also provided. Albeit, some companies employ a custom, public key-enabled remote access system for managing network access, VPNs, and user access.

For example, if my local enterprise defines security rules and roles using Active Directory (AD), ideally our remote site would be managed the same way, and map those identities. Most large companies struggle mapping identities across AD and UNIX (LDAP) security domains, not to mention 3 rd-party companies.

However, the tools provided with Active Directory and other directories are really designed for use within a company; sure some firms have extended directory services to reach across companies, through extranets and internal-to-external trust relationships, in support of acquisitions, mergers, and large company extranets. But it ain’t easy.

In a private cloud model, you may want to use a single domain (built on a common directory service) or integrate two (ideally similar) security models together. In Active Directory, this could be as basic as establishing trust relationships across domains. Or it could be as complicated as mapping identities from Active Directory to LDAP, or vice versa, through tools like Microsoft’s Services for UNIX.

The most challenging and risky scenario: integrating a large enterprise with a public external cloud, through a directory services scheme. Unless your enterprise owns both ends of the cloud, there will likely be a different delegation scheme on the external cloud.

When using a public, external cloud provider, you will likely want to keep the security domains completely separate (unless you know something I don’t). That means treating the public cloud provider either like (a) a remote web ecommerce or banking site (it provides its own security mechanisms, which you either trust or do not) or (b) as an extranet partner site. In this case, you may have some flexibility about the security management systems used remotely.

But does that mean you’re enterprise should approve of any user downloading and running applications locally instead of remotely?

For a use case example, let’s take file transfers. Do you provide all users with a file transfer account? Managing user accounts and permissions separately for FTP or another file transfer scheme, through an ad hoc security manager or directory, becomes a logistical and security nightmare at scale. But guess what: a lot of companies do this anyhow!

Most enterprises likely do not want all users to be able to transfer sensitive application data to and from various cloud providers. In these cases, your company may be able to use tools and technologies either built into your directory service or identity management system to delegate roles and rules concerning file transfers.

Instead, you might define a group or role in Active Directory that permits some users or groups to transfer files. The file transfer solution will then need to support integrating with LDAP, Active Directory, or another directory service you might be using.

On the provider side, the accounts also need to be created/enabled for FTP or another mechanism. This could be as basic as mapping individual user accounts to a group or as complicated as deploying a separate directory system. Each cloud provider will likely have some best practices on how to enable this, or use an out-of-the-box approach.

Thus, starting out, most companies will want to ensure users transferring files do so using minimal security privileges, and transfer the files into locked-down, demilitarized zones through VPNs or other means, where files can be scanned, quarantined, or staged in such a way that fits the security requirements of the end-customer’s business.

Internal IT organizations, consulting firms like GlassHouse, and service providers offering managed clouds are a great resource for offering security management techniques around this type of remote access for the enterprise.

– Jason Goodman

Transport Challenges—to WAN or not to WAN

How do you reliably upload gigabytes or terabytes of files (for example, application data or virtual machines) from your internal IT network to your cloud provider at a reasonable cost, in a reasonable time-frame? Use FTP? Possibly, but not likely.

You have a few options:

1. Create and pack backup copies of your data, rent a U-Haul, and drive your mock-portable storage servers to your friendly, global cloud provider. Hopefully they’re not too far away, but in a warm place on a beach serving Mai Tai’s. (If I had the time, money, and friendly co-pilot, I would seriously consider this.)
2. Spend hours procuring, handling, and burning data sets onto prescribed storage devices; ensure the file permissions are set correctly (since someone else will be accessing them); take the devices to the post office—and ship them off. When they arrive, your storage will be unpacked and magically (I’m waving a wand like Conan O’Brien) staged into your hosting environment by the sysop. Poof.
3. Deploy an online wide-area file transfer solution. This might require upgrading your bandwidth to a prescribed rate to meet your data transfer needs, and using a fast, secure transport to replace FTP at both ends of the network. Or using FTP.

Realize that for C, it will depend largely on how much data you’ve got to move—and how much bandwidth you can dedicate to transfers. Also, traditional hardware-based WAFS won’t help with the initial transfer or entire file uploads; hardware-WAFS keeps unnecessary traffic off the network, and was not designed to move bulk files across it. Another point against hardware WAFS: the dedicated appliance model doesn’t fit well with large-scale, shared clouds—where many customers need to share the pipe and underlying gear. But hey, this might suit some limited use cases.

For bulk data transfers to shared external cloud providers, software is likely a better option. For example, there are now UDP- , software-based WAFS solutions positioned as an alternative to FTP and HTTP (Aspera, FileCatalyst, and Signient, are examples).

Historically, companies needing to move very large data sets relied mainly on option B. Movie studios and broadcasters (remember when movies were stored on this stuff called “film” and “video” and backups stored on “tape”?) relied heavily on UPS or the mail system. The media held up well in the mail. Then FedEx created an entire business around logistics guarantees, When it absolutely, positively has to be there overnight.

Data-swamped IT shops lived by FedEx, and many still do.

But today, customers have BIGGER data sets, online more often (or they’d like to have them online), being accessed, updated, and cross-referenced, and shared publicly more often. And the data is usually stored on fragile hard-drives that don’t travel well.

What about sending files online? Bandwidth prices have dropped, network quality has improved, and new innovate high-speed wide-area file services are now becoming available as an alternative to FTP. Small businesses can grab a 20Mbps WAN pipe for about $100 per-month. GigE WAN prices are dropping; 10GigE is available in some places, but still cost-prohibitive for most WANs.

But it still may not be practical. Using snail mail or the grunt truck today is often faster then FTP. Why?

First, the bandwidth issue: bandwidth is not keeping up with data growth. Data and bandwidth growth rates track separately. There’s no formula that says, hey, in five years we’ll have the raw bandwidth to move these mega-files or petabytes; we’re likely going to rely on software innovations to move the data faster and in more predictable ways, kind of like FedEx did for the physical world using logistics management and streamlined transportation systems.

Second, the TCP and FTP issue. FTP (built on TCP) is fussy over distance, becoming inefficient and unreliable. Many of us have experienced an FTP transfer of a large file that takes forever. You come back from coffee and IF the transfer actually completed, the file may be corrupt. Increasing bandwidth helps, as long as latency is minimized.

Reality: improving bandwidth speed and quality on both ends of the WAN helps. But so does the file transfer transport.

Today, movie studios, broadcasters, government agencies, life sciences researchers, and a number of other data-intensive workflows—not only require moving massively large data sets long distances—but also require remote, inter-company collaboration and exchange. This sets a precedent for many businesses to set up online ingest and delivery systems.

A researcher at The Broad at MIT may have to share findings with Johns Hopkins. A content provider needs to deliver high-def files to a broadcaster. A musician needs an easy way to upload to iTunes or movies. More niche longtail content needs to be randomly accessed remotely. Online is much easier for remote collaboration.

These workflows dovetail nicely with cloud computing as a deport for remote access: especially for companies focused on R&D, discovery, content creation or delivery, and (I’ll say it again), collaboration.

I think this is where Amazon EC2 is heading. They have built a service around option B called “Import/Export” (what an awful name!) where users—someone on your IT team—burns data sets onto portable storage devices (as defined on Amazon) and ships them to Amazon—where your storage is unpacked, copied onto Amazon’s network, plugged in, and all the data is copied/staged for use in your account.

Case in point for option C: Aspera Inc. recently developed an embedded solution for Amazon EC2, replacing FTP at both ends of the WAN. The solution is location- and latency-agnostic, designed for moving files across the network in predictable ways at prescribed speeds. Unlike Amazon, they charge based on bandwidth and usage.

When should you use option B (such as Amazon Import/Export) versus an online system? You can check out the AWS Import/Export calculator to compare the costs. But that just tells you how much AMAZON charges to transfer files. It doesn’t tell you how long it will take or if moving the data set online if even feasible.

Here’s a sample of online transfer times using Aspera based on certain WAN speeds:

One solution: if the data set is really, really big (as in the terabytes), move the initial baseline data set via snail mail, and then provide updates online—depending on your bandwidth, amount of data to move, and workflow.

Prediction: innovative cloud vendors will offer open, cross-platform, software-based WAN acceleration solutions in support of uploading/downloading large data sets, online—to compliment their physical import/export solutions.

Or at least they should.

– Jason Goodman

Compatibility, Portability, Interoperability

Imagine you’re a dock worker at the Port of Seattle in the 1950s having to handle hundreds of bushels of beans, halibut filets, and pallets of paint cans, all individually, and load them onto ships. It was costly and time-consuming labor.

Malcolm McLean of North Carolina is known as the innovator behind shipping containers. McLean’s work streamlined and standardized all aspects of global transportation—shipping, receiving, loading, unloading. Instead of dock workers handling (or stevedoring) cumbersome bulk freight, crane operators load containers onto containerships. An entire ecosystem for reliable, cost-competitive, and predictable delivery of goods was created, using established systems (trains, trucks, and ships).

In cloud computing, no such standard or ecosystem yet exists. An external cloud provider may have a very different application hosting infrastructure than your local IT organization. Thus, relocating applications and associated data sets from your local facility to a cloud provider (or vice versa) may be costly, or not worth the effort.

Um, so I need to rewrite my app to deploy in your data center?

One aspect of this problem is platform-related. If your app is written in one language for one platform, chances are it won’t easily “just run” on another. Most applications have been carefully designed for local operating systems (variations of SMP), file systems, databases, and custom configurations.

Virtual machines—and a standard virtual machine format—can provide a standard virtual container for storing and freighting bulk data sets from one location to another, at the virtualization level. Once a P2V (physical to virtual) migration has been performed, an application and associated data is now virtualized and relatively portable, at least within an operating environment such as VMware vCloud.

Unfortunately, a virtual machine from one vendor won’t easily run on the hypervisor of another. Unless I migrate each virtual machine, I need both sites to be running software from the same vendor. Another issue is remapping virtual storage underneath the hypervisor: while the file format can be migrated, the storage settings and configuration may not easily be transferred. A VM or set of VMs include numerous files and metadata about the VM.

On the positive, virtualization vendors such as Citrix, Microsoft, and VMware are working out common virtual machine file formats through the DMTF’s Virtualization Management (VMAN) Initiative, based on Open Virtualization Format (OVF) and other technologies.

Citrix has a cool cross-hypervisor migration tool and import/export utility. According to Simon Crosby, CTO of Citrix, Kensho will support all major virtual disk file formats, including VMware, Microsoft Hyper-v (supported in XenServer), and the Amazon Machine Image (AMI) format used in Amazon’s Elastic Compute Cloud (EC2). Of course, this requires using the tool and deploying XenServer.

Great, but if I create a virtual machine locally, I should be able to upload that virtual machine and run it remotely in an external cloud. Conversely, if I create and run a virtual machine externally, I should be able to download it—and run it locally.

Prediction: virtualization file and metadata formats will standardize such that I can run instances across heterogeneous hypervisors, as customized by various cloud providers.

Our next blog will deal more specifically with the longhaul transport issues related to cloud computing, virtualization, and importing/exporting bulk data sets.

- Jason Goodman, LW2 Solutions

http://community.citrix.com/display/ocb/2008/08/08/Kensho+-+Portability,+Ubiquity…+Now+with+Extra+Freedom!

One of my favorite security books is Cliff Stoll’s the Cuckcoo’s Egg, where he tracks a spy impersonating a well-known computer scientist at the Lawrence Berkeley Lab. Once inside, the culprit hacks into a shared server to stage a series of attacks into other remote systems, located on remote networks such as MILNET. Although he was logged onto the Berkeley system as a local superuser, Stoll works with authorities tracking him across federal and international networks to a hotel room in Hanover, Germany.

It took six months to find this guy—not including all the legal time to prosecute him in Germany. Most people don’t have the time, persistence, nor ability.

Does your cloud provider?

Stoll’s story raises an age-old concern: with a computing environment accessible to the public, across a public network, security threats become location-independent. Worse, it’s often what’s happening on the inside of the building that alerts operators of an attack.

There’s an old saying from Bob Blakely (now with the Burton Group) that there’s nobody here on this network but us chickens. He meant that it’s naïve to assume your environment is secure simply because the perimeter network is “secure”; it’s often the fox hiding in the henhouse, behind the firewall, that wreaks the most damage.

Sure, properly configured networks and authentication systems improves security. But in cloud computing, where many users access and run applications side-by-side with other users—on the same infrastructure—the possibility of lateral breaches inside the data center theoretically increases. Some of these users (or their malware) could be hunting for back doors into other users’ virtual henhouses.

Stoll recommends gaining deeper visibility into the IT infrastructure through ad hoc security systems, constant auditing, monitoring, log sifting, and reporting. Stoll setup offline alarms (a phone paged him when the hacker logged on) and offline monitors.

In a cloud model, you’re relying on the security knowledge, methods, infrastructure, and tools setup by the provider. But users also need to be aware of common threats (malware, data theft, session or tunnel hijacking, impersonation, man-in-the-middle attacks) and should receive guidance from providers on combating them.

According to Gartner, the best way to assess the security capabilities of your provider is to have a third-party audit them. Determining an “appropriate level” of security, according to Gartner, depends largely on your enterprise’s compliance and confidentiality requirements, and how the provider meets (or doesn’t meet) those requirements.

Another option for re-locating applications requiring higher security: private clouds. Understanding how the provider designs and manages private clouds—through virtualization software and other partitioning and delegation schemes—will give you insight into the security level of their environment. How much of the “private” infrastructure is shared with other customers? How much is dedicated just to your company? How is security managed and delegated to users?

In summary, the security of your provider’s environment will depend largely on:

• The cloud implementation (no two providers are alike) and architecture (shared vs. dedicated; public vs. private; internal vs. external).
• In-house security expertise—and the methodologies in place. Are the Cliff Stoll’s of the world working for your provider with modern tools and understanding?
• Security tools or services available for encryption, antivirus, monitoring, intrusion detection systems, or other security capabilities.
• Auditing: tools and processes for demonstrating security capabilities to 3 rd-parties through APIs, logs, reports, visual aids, and other means.

–Jason Goodman

Everyone seems to have a definition and opinion on cloud computing—and every technology vendor seems to have a solution. There’s a reason many of us did not sign up for cloud computing 102 at [enter any recent industry event you’ve attended] and avoid vendor headlines related to C and C. Filter, delete. Dehumidify.

But the reality is—looming clouds, storm approaching—enterprises have to get ready. Business executives of some companies are already asking for an IT plan.

CEO: Hey Bill, What’s up with cloud computing? Are we ready?

Bill: We’re looking at it. There’s some hype. Let me get back to you.

The good news: the shift to cloud computing doesn’t have to be painful or costly. But it does require work and know-how—either from external cloud providers, expertise in IT, or through an outside consulting firm working with your internal IT team.

A few forward-thinking enterprises have been working on utility computing (read internal clouds) for years. In the process of consolidating data centers, reducing servers and storage n-fold, and squeezing every dollar out of purchased IT infrastructure, these companies have invested time and money developing sophisticated cost analysis, tracking, and service delivery and support techniques. In effect, they have transformed from traditional IT shops—to becoming more like service providers.

But where does that leave the CIO of nearly every other enterprise? How should a CIO begin building a cloud computing strategy and implementation plan?

Likely, many will start with a private cloud strategy—providing the hub to current and future cloud computing initiatives. A private cloud is simply a secure cloud and associated set of security services (authentication, administration, identity management), among others, available to a user-base, usually within an organization.

In general, private clouds:

• Increase time-to-innovation: on-demand resource provisioning means users work on projects instead of waiting on IT resources
• Shift the cost model from up-front capitol acquisition to pay-per-use. While some up-front cost may be required for integration, application redevelopment, etc., the cost model should become pay-as-you-go—once the cloud is ready for use.

There are three basic deployment models for private clouds:

• Internal private cloud: a private cloud can be internal, deployed and managed on local IT infrastructure, usually owned or leased within an organization.
• External private cloud: a private cloud can also be external, deployed and managed on remote IT infrastructure. In some cases, a 3 rd-party provider may own and manage the remote site for IT, offering specific private cloud services.
• Hybrid: some combo of the two above, often “federated”.

An internal private cloud provides a good starting point when:

• Your company has higher data confidentiality and / or higher security requirements. If your applications can be virtualized, or are targeted for cloud computing, but there are concerns around security—i.e., moving them offsite—an internal cloud may be the way to go.
• Applications or workloads are targeted for higher service levels. An internal cloud gives IT the most control over delivering SLAs in support of workloads and applications.
• Costs can or must be assessed to effectively select and compare to external offerings. Understanding the costs of delivering internal service utilities provides the ground work for RFPs and assessing 3 rd-party offerings. Cost analysis provides the basis for defining service offerings and SLAs.
• Infrastructure can or should be leveraged. Much of the infrastructure required to deploy private clouds may be in place. Companies that have deployed sophisticated networks, servers and storage, and considering virtualization software, have the building blocks in place for private clouds.
• The project, for any number of reasons, requires an on-premise solution.

An external private cloud makes sense when:

• You have low to moderately confidential information. If security or confidentiality is high, but the external provider is trusted—either as an IT division, subsidiary customer, or known partner company—external private clouds may make sense.
• Applications or workloads (such as test, development, and training) are met by the SLA published by the provider. An external cloud provider should publish specific SLAs in support of general computing environments.
• Increase time-to-market. If the external provider is also a specialist in delivering private clouds, they may have a rapid deployment offering or package designed specifically for delivering private clouds, remotely.
• Current IT cost information is limited or irrelevant. Some companies may not need to assess their own internal costs of delivering the same IT functions as hosted services. For example, startups, SMBs, or medium-size businesses with little IT expertise, may choose to deploy externally to outsource all IT functions.
• Temporary project infrastructure is required—but no capitol may be obtained. For example, many rapid prototyping or testing projects may not be funded to obtain to IT infrastructure locally, or need to be rapidly acquired and decommissioned.

Other companies will utilize hybrid (or federated) private clouds, where a portion of the service utility is run internally and federated to external sites as needed, or vice versa.

Examples where hybrid internal/external clouds could be used include:

• Disaster recovery. Applications and/or virtual machines may be created and run locally, but need to be replicated to remote sites. The primary site may be an internal cloud, run by IT, and the target DR site could be external, hosted by IT or 3 rd-party provider.
• Collaborative workflows: if many remote users need to collaborate on an application or data set within or between sites, aspects of the data set may be replicated; conversely, virtual private access may be provided remotely to the data set, through a VPN or other means.
• Mixing and matching some combination of internal and external cloud capabilities to address many IT-related requirements in any number of use cases.

Vendors such as VMware claim that hybrid, federated clouds are the way forward. They want enterprises to be using their virtualization platform as a building block to clouds.

However, being locked into a single virtualization platform—through VMware, Microsoft, or [name your cloud provider]—creates compatibility and data portability issues across hypervisors which could limit the interoperability of a hybrid model.

Data portability: that’s a good topic for another blog.

–Jason Goodman

VMWorld 2009

All this week at VMworld 2009 we have been discussing the cloud. Since VMworld is mostly about infrastructure we have been discussing the internal, external and private cloud concepts from an infrastructure point of view. Of course the real value I see coming from the cloud paradigm is for application and application service levels.

Eventually, the economies of scale behind cloud computing will allow cloud vendors to provide powerful services for the development of robust solutions. Standards will be created for API’s to facilitate many important IT service levels including:

• High Availability/Fault Tolerance
• True Dynamic Scalability through Automation
• Quick Recovery
• Disaster Recovery
• Content Delivery
• Storage on Demand
• Certified Security

Some of these solutions will be developed into the service technology, some will be provided by service process. The great beneficiary will be IT organizations that now find it very hard to, for example, provide higher availability and decent disaster recovery. I have always preached that recovery and disaster recovery should be developed into applications not bolted on at the infrastructure layer. The shift in development to the cloud is a perfect time to make this a standard practice based on industry standard mechanisms.

The scale associated with cloud providers will also enable creation of top quality facilities with incredible amounts of available bandwidth which will fuel better SLA’s for recovery and performance. As long as the hurdles of security and multi-tenancy can be overcome which seems extremely likely with the amount of development going on within the vendor community.

I am not building cloud infrastructure but I hope that those that are like Google, Amazon and VMware’s many cloud partners are building these types of solutions into their products. The concept has me extremely excited about the future from someone who has had to worry about system recovery as an architect my whole career.

We’ll this is my last VMworld 2009 blog. I enjoyed writing them I hope that you enjoyed reading them and that they offered some food for thought.

- Rob Zylowski Director, Services and Director, IP GlassHouse Technologies

VMWorld 2009

In our video blog with Ron Oglesby yesterday, one of his thoughts was that our customers could really use a “Roadmap” for how to approach getting to the cloud. I agreed that this would certainly help cut through the confusion. I think one of the main problems is that vendors have jumped on the hype. Even if their product has really nothing to do with the cloud somehow it does in their marketing. This situation leads to incredible confusion in the marketplace.

Going back to my blogs from earlier this week, the “Cloud” in the end should be about providing access to applications independent of device and location. So, why do the majority of vendor offerings being provided today not fit this definition. The answer is that to support this a paradigm shift in development is required. New ways to support development always take a very long time to implement but vendors want to take advantage of the hype now. It is much easier though to provide Hardware as a Service (HaaS) so these are the services that are being offered and used now while SaaS offerings are much slower to hit the market.

So, if you are an IT strategist what should you be doing and thinking about to be ready to benefit from “Cloud Computing” as the technologies and services mature. I think all of the following will be important:

1. In the long run the IT organization will have to function as a service provider. This is normally a major shift in IT governance changing a significant number of policies, processes and technologies within the organization. There are normally many maturity levels associated with the path to become a service provider. In terms of infrastructure it’s a great start to first be able to allocate and track costs at a very granular level. You don’t need to start immediately with charging directly for services but you can provide significant cost transparency back to management and the user community. The costs should be associated with defined services and service levels so that the clients understand what they are getting and where the costs come from. As your organization matures in this you can change to actually define and offer services to your internal clients. These services can mostly be provisioned internally but you could also offer some external services if it makes sense. All the time you will be maturing in terms of policy, process and culture to eventually provide IT as a service.
2. Instrument to track SLA metrics. If in the future you will charge for services and service levels you must learn how to track and report on them. This takes a significant amount of time to learn and implement but it is well worth the effort.
3. Stay up to date with VMware software. Migrate to vSphere for all the major benefits but also to stay current and enable the future benefit of portability between the public and private clouds.
4. Look for software that will enable you to build service catalog with automation and self service, integrated problem and incident management, log management, capacity management and forecasting and of course financial management. All required to effectively run a services organization.
5. Be open minded with regards to what is out there now. It might be possible that using one of the existing “Cloud” vendors to supply HaaS for Test/QA environments could save you money and using these services now will provide experience that will help as the model matures. It may also make sense to start to use some of the SaaS based services. This will also provide experience for moving to a service centric model in the future.
6. Discuss a strategy of developing for the cloud. I think it might be best to start with internal clouds for this moving to external as they mature. I kind of like the VMware strategy with Spring because it does not tie you in to a particular vendor even though it may be optimized on vClouds. It also supports several popular languages including java and Rails. This is probably one of the most important aspects of the plan because it takes a long time to have software that will take advantage of the new paradigm.

I am sure there are other prep steps I haven’t mentioned. A good take-away from this blog would be that Cloud Technologies are in very early stages of development. Its great for the Industry that so much innovation is being driven because VMware and others are hyping up Cloud Computing. I think its not just marketing hype and its also not just another try as ASP. I think the vision is driven by real issues and complexities within IT caused by the development of complex client server technologies that are hard to manage especially with regards to recovery, disaster recovery, performance and cost containment. But it will take some time to realize the benefits associated with “Cloud Computing” which is a good thing because it gives you and your organization time to prepare.

- Rob Zylowski Director, Services and Director, IP GlassHouse Technologies