What is the value of IT convenience?

RPath's Billy Marshall wrote a post that is closely related to a topic I have been thinking about a lot lately. Namely, Billy points out that the effect of server virtualization hasn't been to satisfy the demand on IT resources, but simply to accelerate that demand through simplifying resource allocation. Billy gives a very clear example of what he means:

"Over the past 2 weeks, I have had a number of very interesting conversations with partners, prospects, customers, and analysts that lead me to believe that a virtual machine tsunami is building which might soon swamp the legacy, horizontal system management approaches. Here is what I have heard:

Two separate prospects told me that they have quickly consumed every available bit of capacity on their VMware server farms. As soon as they add more capacity, it disappears under the weight of an ever pressing demand of new VMs. They are scrambling to figure out how they manage the pending VM sprawl. They are also scrambling to understand how they are going to lower their VMware bill via an Amazon EC2 capability for some portion of the runtime instances.

Two prominent analysts proclaimed to me that the percentage of new servers running a hypervisor as the primary boot option will quickly approach 90% by 2012. With all of these systems sporting a hypervisor as the on-ramp for applications built as virtual machines, the number of virtual machines is going to explode. The hypervisor takes the friction out of the deployment process, which in turn escalates the number of VMs to be managed."

The world of Infrastructure as a Service isn't really any different:

"Amazon EC2 demand continues to skyrocket. It seems that business units are quickly sidestepping those IT departments that have not yet found a way to say “yes” to requests for new capacity due to capital spending constraints and high friction processes for getting applications into production (i.e. the legacy approach of provisioning servers with a general purpose OS and then attempting to install/configure the app to work on the production implementation which is no doubt different than the development environment). I heard a rumor that a new datacenter in Oregon was underway to support this burgeoning EC2 demand. I also saw our most recent EC2 bill, and I nearly hit the roof. Turns out when you provide frictionless capacity via the hypervisor, virtual machine deployment, and variable cost payment, demand explodes. Trust me."

Billy isn't the only person I've heard comment about their EC2 bill lately. Justin Mason commented on my post, "Do Your Cloud Applications Need to be Elastic?":

"[W]e also have inelastic parts of the infrastructure that could be hosted elsewhere at a colo for less cost, and personally, I would probably have done this given the choice; but mgmt were happier just to use EC2 as widely as possible, despite the additional costs, since it keeps things simpler."

In each case, management chooses to pay more for convenience.

I think these examples demonstrate an important decision point for IT organizations, especially during these times of financial strife. What is the value of IT convenience? When is it wise to choose to pay more dollars (or euros, or yen, or whatever) to gain some level of simplicity or focus or comfort? In the case of virtualization, is it always wise to leverage positive economic changes to expand service coverage? In the case of cloud computing, is it always wise to accept relatively high price points per CPU hour over managing your own cheaper compute loads?

I think there are no simple answers, but there are some elements that I would consider if the choice was mine:

• Do I already have the infrastructure and labor skills I need to do it just as well or better than the cloud? If I were to simply apply some automation to what I already have, would it deliver the elasticity/reliability/agility I want without committing a monthly portion of my corporate revenues to an outside entity?

• Is virtualization and/or the cloud the only way to get the agility I need to meet my objectives? The answer here is often "yes" for virtualization, but is it as frequently for cloud computing?

• Do I have the luxury of cash flow that allows for me to spend up a little for someone else to worry about problems that I would have to handle otherwise? Of course, this is the same question that applies to outsourcing, managed hosting, etc.

One of the reasons you've seen a backlash against some aspects of cloud computing, or even a rising voice to the "its the same thing we tried before" argument, is that much of the marketing hype out there is staring to ignore the fact that cloud computing costs money; costs enough to provide a profit to the vendor. Yes, it is true that many (most?) IT organizations have lacked the ability to deliver the same efficiencies as the best cloud players, but that can change and change quickly if those same organizations were to look to automation software and infrastructure to provide that efficiency.

My advice to you: if you already own data centers, and if you want convenience on a budget, balance the cost of Amazon/GoGrid/Mosso/whoever with the value delivered by Arjuna/3TERA/Cassatt/Enomaly/etc./etc./etc., including controlling your virtualization sprawl and preparing you for using the cloud in innovative ways. Consider making your storage and networking virtualization friendly.

Sometimes convenience starts at home.

Two! Two! Two! Two great Overcast podcasts for your enjoyment

It's been a busy week or so for Geva Perry and I, as we took Overcast to a joint podcast with John Willis's CloudCafe podcast, and had a fabulous discussion with Greg Ness of Archimedius.net. Both podcasts are available from the Overcast blog.

The discussion with John focused on definitions in the cloud computing space, and some of the misconceptions that people have about the cloud, what it can and can't do for you, and what all that crazy terminology refers to. John is an exceptionally comfortable host, and his questions drove a deep conversation about what the cloud is, various components of cloud computing, and adjunct terms like "cloudbursting". It was a lot of fun to do, and I am grateful for John's invitation to do this.

Greg Ness demonstrated his uniquely deep understanding of what network security entails in a virtualized data center, and how automation is the lynch pin of protecting that infrastructure. Topics ranged from this year's DNS exploit and the pace at which systems are getting patched to address it, to the reasons why the static network we all knew and loved is DOA in a cloud (or even just a virtualized) world. I really admire Greg, and find his ability to articulate difficult concepts with the help of historical insight very appealing. I very much appreciate his taking time out of his busy day to join us.

We are busy lining up more great guests for future podcasts, so stay tuned--or better yet, subscribe to Overcast at the Overcast blog.

Is IBM the utlimate authority on cloud computing?

There was an interesting announcement today from IBM regarding their new "Resiliant Cloud" seal of approval--a marketing program targeted at cloud providers, and at customers of the cloud. The idea is simple, if I am reading this right:

• IBM gets all of the world's cloud vendors to pay them a services fee to submit their services to a series of tests that validate (or not) whether the cloud is resiliant, secure and scalable. Should the vendor's offering pass, they get to put a "Resiliant Cloud" logo on their web pages, etc.

• Customers looking for resiliant, secure and scalable cloud infrastructure then can select from the pool of "Resiliant Cloud" offerings to build their specific cloud-based solutions. Oh, and they can hire IBM services to help them distinguish when to go outside for their cloud infrastructure, and when to convert their existing infrastructure. I'm sure IBM will give a balanced analysis as to the technology options here...

I'm sorry, but I'm a bit disappointed with this. IBM has been facing a very stiff "innovator's dilemma" when it comes to cloud computing, as noted by GigaOm's Stacy Higgenbotham:

"IBM has been pretty quiet about its cloud efforts. In part because it didn’t want to hack off large customers buying a ton of IBM servers by competing with them. The computing giant hasn’t been pushing its own cloud business until a half-hearted announcement at the end of July, about a month and half after a company exec had told me IBM didn’t really want to advertise its cloud services."

She goes on to note, however, that IBM has some great things in the works, including a research project in China that shows great promise. That's welcome news, and I look forward to IBM being a major player on the cloud computing stage again. However, this announcement is just an attempt at making IBM the "godfather" of the cloud market, and that's not interesting in the least.

Still, I bet if you want to be an IBM strategic partner, you'd better get on board with the program. Amazon, are you going to pay the fee? Microsoft? Google? Salesforce.com? Anyone?

Do Your Cloud Applications Need To Be Elastic?

I got to spend a few hours at Sys-Con's Cloud Computing Expo yesterday, and I have to say it was most certainly an intellectually stimulating day. Not only was just about every US cloud startup represented in one way or another, but included were an unusual conference session, and a meetup of fans of CloudCamp.

While listening in on a session, I overheard one participant ask how the cloud would scale their application if they couldn't replicate it. This triggered a strong response in me, as I really feel for those that confuse autonomic infrastructures with magic applied to scaling unscalable applications. Let me be clear, the cloud can't scale your application (much, at least) if you didn't design it to be scaled. Period.

However, that caused me to ask myself whether or not an application had to be horizontally scalable in order to gain economically while running in an Infrastructure as a Service (IaaS) cloud. The answer, I think, is that it depends.

Chris FlexFleck of Citrix wrote up a pretty decent two part explanation of this on his blog a few weeks ago. He starts out with some basic costs of acquiring and running 5 Quad-core servers--either on-premises (amortized over 3 years at 5%) or in a colocation data center--against the cost of running equivalent "high CPU" servers 24X7 on Amazon's EC2. The short short of his initial post is that it is much more expensive to run full time on EC2 than it is to run on premises or in the colo facility.

How much more expensive?

• On-premises: $7800/year
• Colocation: $13,800/year
• Amazon EC2: $35,040/year
  

I tend to believe this reflects the truth, even if its not 100% accurate. First, while you may think "ah, Amazon...that's 10¢ a CPU hour", in point of fact most production applications that you read about in the cloud-o-sphere are using the larger instances. Chris is right to use high CPU instances in his comparison at 80¢/CPU hour. Second, while its tempting to think in terms of upfront costs, your accounting department will in fact spread the capital costs out over several years, usually 3 years for a server.

In the second part of his analysis, however, Chris notes that the cost of the same Amazon instances vary based on the amount of time they are actually used, as opposed to the physical infrastructure that must be paid for whether it is used or not (with the possible exception of power and AC costs). This comes into play in a big way if the same instances are used judiciously for varying workloads, such as the hybrid fixed/cloud approach he uses as an example.

In other words, if you have an elastic load, plan for "standard" variances on-premises, but allow "excessive" spikes in load to trigger instances on EC2, you suddenly have a very compelling case relative to buying enough physical infrastructure to handle excessive peaks yourself. As Chris notes:

"To put some simple numbers to it based on the original example, let's assume that the constant workload is roughly equal to 5 Quadcore server capacity. The variable workload on the other hand peaks at 160% of the base requirement, however it is required only about 400 hours per year, which could translate to 12 hours a day for the month of December or 33 hours per month for peak loads such as test or batch loads. The cost for a premise only solution for this situation comes to roughly 2X or $ 15,600 per year assuming existing space and a 20% factor of safety above peak load. If on the other hand you were able to utilize a Cloud for only the peak loads the incremental cost would be only $1,000. ( Based on Amazon EC2 )

Premise Only
$ 15,600	Annual cost ( 2 x 7,800 from Part 1 )
Premise Plus Cloud
$ 7,800	Annual cost from Part 1
$ 1,000	Cloud EC2 - ( 400 x .8 x 3 )
$ 8,800	Annual Cost Premise Plus Cloud "

The lesson of our story? Using the cloud makes the most sense when you have an elastic load. I would postulate that another option would be a load that is not powered on at full strength 100% of the time. Some examples might include:

• Dev/test lab server instances
• Scale-out applications, especially web application architectures
• Seasonal load applications, such as personal income tax processing systems or retail accounting systems

On the other hand, you probably would not use Infrastructure as a Service today for:

• That little accounting application that has to run at all times, but has at most 20 concurrent users
• The MS Exchange server for your 10 person company. (Microsoft's multi-tenant Exchange online offering is different--I'm talking hosting your own instance in EC2)
• Your network monitoring infrastructure

Now, the managed hosting guys are going to probably jump down my throat with counter arguments about the level of service provided by (at least their) hosting clouds, but my experience is that all of these clouds actually treat self-service as self-service, and that there really is very little difference between do-it-yourself on-premises and do-it-yourself in cloud.

What would change these economics to the point that it would make sense to run any or all of your applications in an IaaS cloud? Well, I personally think you need to see a real commodity market for compute and storage capacity before you see the pricing that reflects economies in favor of running fixed loads in the cloud. There have been a wide variety of posts about what it would take [pdf] to establish a cloud market in the past, so I won't go back over that subject here. However, if you are considering "moving my data center to the cloud", please keep these simple economics in mind.

Reuven Cohen Invents The "Unsession"

Gotta luv the Ruv. One of the highlights of this week's Sys-Con Cloud Computing Expo was Reuven's session on World-Wide Cloud Computing, "presented" to a packed room filled with some of the most knowledgeable cloud computing fans you'll ever see--from vendors, SIs, customers, you name it.

Reuven got up front, showed a total of two slides (to introduce himself, because if you're Ruv, it takes two slides to properly introduce yourself. :-) ), then kicked off a totally "unconference" like hour long session. The best way I can think of to describe it was it was that he a) went straight to the question and answer period, and b) asked questions of the audience, not the other way around. Now, he may just have been lazy, but I think he took advantage of the right sized room with the right subject matter interest and expertise at the right time to shake things up.

The result was an absolutely fascinating and wide ranging discussion about what it would take to deliver a "world wide cloud", a dream that many of us have had for a while, but that has been a particular focus of Reuven's. I can't recount all aspects of the discussion here, quite obviously, but I thought I would share the list of subjects covered that I noted during the talk:

• federation
• firewall configuration
• data encryption
• Wide Area Network optimization
• latency
• trust
• transparency
• the community's role in driving cloud specifications
• interoperability
• data portability
• data ownership
• metadata/policy/configuration/schema ownership
• cloud brokerages
• compliance
• Payment Card Industry
• Physical to Virtual and Physical to Cloud
• reliability
• SLA metadata
• data integrity
• identity
• revocable certificates (see Nirvanix)
• content delivery networks (and Amazon's announcement)
  
• storage

Now, I'm not sure that we solved anything in the discussion, but everyone walked away learning something new that afternoon.

Got a session to present to a room of 100 or less? Not sure how to capture attention in a set of slides? The heck with it, pull a "Reuven" and turn the tables. If you have an audience eager to give as well as take, you could end up enlightening yourself as much as you enlighten everyone else.

Thanks, Ruv, and keep stirring things up.

Amazon launches CloudFront Content Delivery Service

Quick note before I go to bed. Amazon just announced their previously discussed content delivery network service, CloudFront, tonight. Jeff Barr lays it out for you on the AWS blog, and Werner Vogels adds his vision for the service. To their credit, they are pushing the concept that the way the service is designed, it can do much more than traditional content delivery services; potentially acting as a cacheing and routing mechanism for applications distributed across EC2 "availability zones".

I think Thorsten von Eiken of RightScale gives the most honest assessment of the service tonight. He praises the simplicity of use, noting that his product supports all CloudFront functionality today. Noting that CloudFront is a "'minimum viable product' offering" at this time, he also notes that there are several restrictions, and that there are some features that leave a lot to be desired. That being said, both Amazon and RightScale are clear that this is a necessary service for Amazon to offer, and that it is indeed useful today.

More when I've had a chance to evaluate it, but congrats again to the Amazon team for staying a few steps ahead.

Update: Stacy Higginbotham adds some excellent insight from the GigaOm crew on CloudFront's effect on the overall CDN market. The short short is that Amazon's "pay-as-you-go" pricing severely undercuts the major CDN vendors for small and medium businesses.

Why the Choice of Cloud Computing Type May Depend On Who's Buying

Thanks to Ron K. Jeffries' Cloudy Thinking blog, I was directed to Redmonk's Stephen O'Grady (who I now subscribe to directly) and his excellent post titled Cloud Types: Fabric vs Instance. Stephen makes an excellent observation about the nature of Infrastructure as a Service (called increasingly "Utility Computing" by Tim O'Reilly followers) and Platform as a Service (that one remains consistent). His observation is this:

"...Tim seems to feel that they are aspects of the types, while I’m of the opinion that they instead define the type. For example, by Tim’s definition, one characteristic of Utility Computing style clouds is virtual machine instances, where my definitions rather centers on that.

Here’s how I typically break down cloud computing styles:

Fabric

Description: A problematic term, perhaps, because a few of the vendors employ it towards different ends, but I use it because it’s descriptive. Rather than deploy to virtualized instances, developers building on this style cloud platform write instead to a fabric. The fabric’s role is to abstract the underlying physical and logical architecture from the developer, and - typically - to assume the burden of scaling.
Example: Google App Engine

Instance

Description: Instance style clouds are characterized by, well, instances. Unlike the fabric cloud, there is little to no abstraction present within instance based clouds: they generally recreate - virtually - a typical physical infrastructure composed of instances that include memory, processing cycles, and so on. The lack of abstraction can offer developers more control, but this control is typically offered at the cost of transparent scaling.
Example: Amazon EC2"

I love that distinction. First, for those struggling to see how Amazon/GoGrid/Flexiscale/etc. relates to Google/Microsoft/Salesforce.com/Intuit/etc., it delineates a very clear difference. If you are reserving servers on which to run applications, it is IaaS. If you are running your application free of care about which and how many resources are consumed, then it is PaaS. Easy.

However, I am even more excited by a thought that occurred to me as I read the post. One of the things that this particular distinction points out is the likelihood that the buyers of each type would be different classes of enterprise IT professionals.

Its not black and white, but I would be willing to bet heavily that :

• The preponderance of interest in IaaS is from those whose primary concern is system administration; those with complex application profiles, who want to tweak scalability themselves, and who want the freedom to determine how data and code get stored, accessed and acted upon.

• The preponderance of interest in PaaS is from those whose primary concerns is application development; those with a functional orientation, who want to be more concerned about creating application experiences than worrying about how to architect for deployment in a web environment (or whatever the framework provides).

In other words, server jockeys chose instances, while code jockeys choose fabric.

Now, the question quickly becomes, if developers can get the functionality and scalability/reliability/availability required from PaaS, without hiring the system administrators, why would any enterprise choose IaaS unless they were innovating at the architecture level? On the other hand, if all you want to do is add capacity to existing functionality, or you require an unusual or even innovative architecture, or you need to guarantee that certain security and continuity precautions are in place, why would you ever choose PaaS?

This, in turn, boils right back down to the PaaS spectrum I spoke of recently. Choose your cloud type based on your true need, but also take into account the skill set you will require. Don't focus on a single brand just because it's cool to your peers. Pick IaaS if you want to tweak infrastructure, otherwise by all means find the PaaS platform that best suits you. You'll probably save in the long run.

Now, I've clearly suppressed the fact that developers probably still want some portability...though I must note that choosing a programming language alone limits function portability. (Perhaps that's OK if the productivity values out weigh the likelihood of having to port.) Also, the things that system administrators are doing in the enterprise are extremely important, like managing security, data integrity and continuity. There are no guarantees that any of the existing PaaS platforms can help you with any of that.

Something to think about, anyway. What do you think? Will developers lean towards PaaS, while system administrators lean towards IaaS? Who will win the right to choose within the enterprise?

In Cloud Computing, a Good Network Gives You Control...

There is a simple little truth that is often looked over when people discuss "moving to the cloud". It is a truth that is so obvious, it is obscure; so basic, it gets lost in the noise. That truth is simply this: you may move all of your servers to the cloud, you may even move all of your storage to the cloud, but an enterprise will always have a network presence in its own facilities. The network is ubiquitous, not only in the commodity sense, but also in the physical sense.

To date, most IT folks have had a relatively static view of networks. They've relied on networking equipment, software and related services to secure the reliability of TCP/IP and UDP packets moving from physical place to physical place. Yeah, there has been a fair measure of security features thrown in, and some pretty cool management to monitor that reliability, but the core effort of networks to date was to reduce the risk of lost or undeliverable network packets--and "static" was very "in".

However, the cloud introduces a factor that scares the bejeezus out of most IT administrators: a dynamic world that gives the appearance of a complete lack of control. How does IT control the security of their data and communications between their own facilities, the Internet and third party cloud providers? How do they secure the performance of systems running over the Internet? Is it possible to have any view into the health and stability of a cloud vendor's own infrastructure in a way meaningful to the Network Operations Centers we all know and love?

When it comes to infrastructure, I have been arguing that the network must take more of a role in the automation and administration of public, private and hybrid clouds. However, let me add that I now think enterprises should look at the network as a point of control over the cloud. Not necessarily to own all of that control--services such as RightScale and CohesiveFT, or cloud infrastructures such as Cassatt or 3TERA have a critical role to play in orchestration and delivery of application services.

However, their control of your resources relies entirely on the network as well, and you will likely have federated and/or siloed sets of those infrastructure management systems scattered across your disparate "cloud" environment. The network remains the single point of entry into your "cloud", and as such should play a key role in coordinating the monitoring and management activities of the various components that make up that "cloud".

Greg Ness outlined some of this in his excellent post on Infrastructure 2.0, (and this recent one on cloud computing in the recession), a theme picked up by Chris Hoff and others. All of these bloggers are sounding a clarion call to the network vendors, both large and small, that have a stake in the future of enterprise IT. Support dynamic infrastructures--securely--or die. I only add that I don't believe that its enough to make dynamic work, I think it is critical to make sure the enterprise feels they are in control of "their own" cloud environment, whether or not it contains third party services, runs in dozens of data centers, or changes at a rate to quick for human decision makers to manage.

What are some of the ways that the network can give you control over a dynamic infrastructure? Here's my "off the top of my head" list of some of the ways:

• There needs to be a consistent way to discover and evaluate new VMs, bare metal deployments, storage allocations, etc. and the network can play a key role here.

• There also needs to be consistent monitoring and auditing capabilities that work across disparate cloud providers. This doesn't necessarily have to be provided by the network infrastructure, but network-aware system management tools seem as logical a place to start as any.
  

• Networks should take an active role in virtualization, providing services and features to enable things like over WAN VM migration, IP address portability and discovery of required services and infrastructure during and after VM migration. Where your servers run should be dependent on your needs, not your network's abilities.

• At times the network should act like the human nervous system and take action before the "brain" of the cloud is even aware something is wrong. This can take the form of agreed upon delegation of responsibility in failure and over-utilization situations, with likely advancement to an automated predictive modelling approach once some comfort is reached with the symbiotic relationship between the network and management infrastructures.

Believe me, I know I have much to learn here. I can tell you that my soon-to-be employer, Cisco, is all over it, and has some brilliant ideas. Aristra Networks is a startup with a pretty good pedigree that is also aggressively looking at cloud enabled networks. I can only assume that F5, Nortel, Extreme and others are also seriously evaluating how they can remain competitive in such a rapidly changing architecture. What exactly this will look like is fuzzy at this point, but the next few months are going to be monster.

In the meantime, ask yourself not what you can do to advance your network, but what your network can do to advance you...

Two Announcements to Pay Attention To This Week

I know I promised a post on how the network fits into cloud computing, but after a wonderful first part of my week spending time first catching up on reading, then one-on-one with my 4-year old son, I'm finally digging into what's happened in the last two days in the cloud-o-sphere. While the network post remains important to me, there were several announcements that caught my eye, and I thought I'd run through two of them quickly and give you a sense of why they matter

The first announcement came from Replicate Technologies, Rich Miller's young company, which is focusing initially on virtualization configuration analysis. The Replicate Datacenter Analyzer (RDA) is a powerful analysis and management tool for evaluating the configuration and deployment of virtual machines in an enterprise data center environment. But it goes beyond just evaluating the VMs itself, to evaluating the server, network and storage configuration required to support things like vMotion.

Sound boring, and perhaps not cloud related? Well, if you read Rich's blog in depth, you may find that he has a very interesting longer term objective. Building on the success of RDA, Replicate aims to become a core element of a virtualized data center operations platform, eventually including hybrid cloud configurations, etc. While initially focused on individual servers, one excellent vision that Rich has is to manage the relationships between VMs in such a tool, so that operations taken on one server will take into account the dependencies on other servers. Very cool.

Watch the introductory video for the fastest impression of what Replicate has here. If you manage virtual machines, sit up and take notice.

The other announcement that caught my eye was the new positioning and features introduced by my alma mater, Cassatt Corporation this week. I've often argued that Cassatt is an excellent example of a private cloud infrastructure, and now they are actively promoting themselves as such (although they use the term "internal cloud").

It's about freaking time. With a mature, "burned in", relatively technology agnostic platform that has perhaps the easiest policy management user experience ever (though not necessarily the prettiest), Cassatt has always been one of my favorite infrastructure plays (though I admit some bias). They support an incredible array of hardware, virtualization and OS platforms, and provide the rare ability to manage not only virtual machines, but also bare metal systems. You get automated power management, resource optimization, image management, and dynamic provisioning. For the latter, not only is server provisioning automated, but also network provisioning--such that deploying an image on a server triggers Cassatt to reprogram the ports that the target server is connected to so that they sit on the correct VLAN for the software about to be booted.

The announcement talks a lot about Cassatt's monitoring capabilities, and a service they provide around application profiling. I haven't been briefed about these, but given their experience with server power management (a very "profiling focused" activity) I believe they could probably have some unique value-add there. What I remember from six months ago was that they introduced improved dynamic load allocation capabilities that could use just about any digital metric (technical or business oriented) to set upper and lower performance thresholds for scaling. Thus, you could use CPU utilization, transaction rates, user sessions or even market activity to determine the need for more or less servers for an application. Not too many others break away from the easy CPU/memory utilization stats to drive scale.

Now, having said all those nice things, I have to take Cassatt to task for one thing. Throughout the press release, Cassatt talks about Amazon and Google like infrastructure. However, Cassatt is doing nothing to replicate the APIs of either Amazon (which would be logical) or Google (which would make no sense at all). In other words, as announced, Cassatt is building on their own proprietary protocols and interfaces, with no ties to any external clouds or alternative cloud platforms. This is not a very "commodity cloud computing" friendly approach, and obviously I would like to see that changed. And, the truth is, none of their direct competitors are doing so, either (with the possible exception of the academic research project, EUCALYPTUS).

The short short of it is if you are looking at building a private cloud, don't overlook Cassatt.

There was another announcement from Hyperic that I want to comment on, but I'm due to chat with a Hyperic executive soon, so I'll reserve that post for later. The fall of 2008 remains a heady time for cloud computing, so expect many more of these types of posts in the coming weeks.

Change, Take Two

As those of you that follow me on Twitter already know, last Friday (11/7) was my last day at Alfresco. Although my time there was very short, it was one of the most valuable experiences of my almost 20 year career. I learned more about the state of enterprise Java applications, the importance of ECM to almost every business, and the great advantage that open source has in the enterprise software market. Not bad for just short of six months. The company and its product are both incredible, and I owe a lot to the amazing field team at Alfresco, especially Matt Asay, Scott Davis, Luis Sala and Peter Monks.

Why am I moving on so soon, then? Well, I'm happy to say that I'm taking on the role of Marketing Manager/Technology Evangelist for Data Center Virtualization at Cisco Systems, Inc. (including Cloud Computing and Cisco's Data Center 3.0 strategy, at least as it relates to virtualization). This is a dream job in many ways, as Cisco is still in the formative stages of its cloud computing strategy (for both service providers and end users), and I have the chance to be part of what will most likely be the most important producer of cloud and virtualization enabled networking software, services and equipment.

This is also an opportunity in which both my passion for blogging and my passion for cloud computing come directly into play. I am excited to work with both Doug Gourlay and Peter Linkin, who are incredibly smart people with a vision I can really get my head around.

Lest you fret that I'm going to go "all Cisco" here on The Wisdom of Clouds, let me assure you that this was pretty much the first point of negotiation when they approached me about the position. The Wisdom of Clouds (or whatever it morphs into--more on that later in the week) will remain my independent blog, in which I will endeavor to provide the same humble insight into the state of the cloud market and technology that I always have. Cisco specific posts will largely be confined to the Data Center group's excellent blog, where I will become a regular contributor.

In the end, what sold me on joining Cisco was the excellent opportunity to explore the "uncharted territory" that is the network's role in cloud computing. More on that in my next post.

A Quick Guide To The "Big Four" Cloud Offerings

We live in interesting times--in fact, historic times. From the highs of seeing the election of a presidential candidate inspire millions to see opportunity where they saw none before, to the lows of experiencing first hand financial pressures that we previously only glimpsed when our parents or grandparents told us tales of hardship and conservation.

For me, in the context of this blog, the explosion of the cloud into mainstream information technology has been undeniably exciting and overwhelming. In the last several weeks, we have seen key announcements and rumors revealing the goals and aspirations of current cloud superstars, as well as the well executed introduction of a new major player. As the dust settles from this frenzy, it becomes clear that the near term cloud mindshare will be dominated by four major players.

(There are, of course, many smaller companies addressing various aspects of cloud computing, and at times competing directly against one or more of these four. However, these are the one's that have the most mindshare right now, and are backed by some of the most trusted names in web and enterprise computing.)

Below is a table that lists these key players, and compares their offerings from the perspective of four core defining aspects of clouds. As this is a comparison of apples to oranges to grapefruit to perhaps pastrami, it is not meant to be a ranking of the participants, nor a judgement of when to choose one over the other. Instead, what I hope to do here is to give a working sysadmin's glimpse into what these four clouds are about, and why they are each unique approaches to enterprise cloud computing in their own right. Details about each comment can be found in the text below the table.

Without further ado:

Provider	"On-Premises" Option	Development Technology	Portability	Reliability
Amazon AWS	Bring Your Own	Whatever you can get to run in an AMI	Code is easy to move. The rest...?	Reliability by Spreading The Wealth
Google App Engine	Sure...for your dev environment	* Hip coders love Python, right?	Are you kidding?	Trust the Magic
Microsoft Azure	Absolutely! The future is hybrid.	* If you love MSFT, you already know it. (.NET)	You mean between Microsoft products, right?	Promises, promises
Salesforce.com (force.com)	Absolutely not! The future is pure cloud	It's new, it's improved, it's APEX!	Heh. That's funny...	We Got Magic, Too.

Amazon AWS

• Amazon does not now provide, nor do they show any interest in the the future of providing, an "on-premises" option for their cloud. However, the EUCALYPTUS research project is an example of an open source private cloud being built to Amazon's API specifications for EC2 and S3. Whether this will ever see commercial success (or support from Amazon), is yet to be determined.
• Amazon pretty much provides servers and storage, with a few integration and data services thrown in for good measure. The servers are standard OSes, with full root/Administrator access, etc. In theory, you should be able to get any code running on an Amazon machine image (AMI) that you could run on a physical server with the same OS, bar certain hardware and security requirements.
• As the AMIs are standard OS images, moving applications off of Amazon should be easy. However, moving data or messaging off of S3/SimpleDB and SQS will probably take a little more work. Still simple, but there is no standard packaging of data for migration between cloud providers today.
• Reliability in AWS is primarily provided by replicating AMIs and data across geographically distributed "availability zones". The idea there is to isolate outages to a zone, so by cloning services and data between zones, one should always have at least one instance handy should others go down.

Google App Engine

• Google provides an open source development kit that allows developers to create App Engine apps and test them on local systems before deploying them into Google's cloud. There is no true replicate of App Engine itself that can be used in a private cloud, not are their plans for one that I know of. To be frank, I'm not sure why you would want one.
• Google's SDK has started with open sourced, but Google specific, APIs in the Python scripting language. Other languages have been promised, but this is what you need to know today.
• Given the unique nature of the Python APIs, the Big Table-based data architecture and the lack of partners exploring clones of the environment, portability is not an option at this point. Nor, it seems, are Google encouraging it, though they are always quick to point out that data itself can be retrieved from Google at will, via APIs. Mapping to a new infrastructure, though, is on the customer's dime.
• For high scale-dependent web applications, Google App Engine is the winner hands down. They know how to replicate services, provide redundant architecture under the covers and secure their perimeter. All the customer has to do is deploy their software and trust Google to do their thing.

Microsoft Azure

• Microsoft makes a point of defining their cloud platform in terms of a hybrid public/private infrastructure. Their mantra of "Software-plus-Service" is an homage to having parts of your enterprise systems run in house, and other parts running in Azure. In many ways, Microsoft is letting the market decide for them how much of the future is "pure cloud", and how much isn't.
• The first platform that Microsoft supports is understandably their own, .NET. If you already use .NET, you've hit the cloud computing jackpot with Azure. If not, you can learn it, or wait for the additional languages/platforms promised in the coming months and years.
• Microsoft wants to make portability extremely simple...within its own product line. Like the others, there are ways to get your data via APIs, but there is no simple mechanism to port between Azure and other cloud platforms.
• At this point, we can only guess at the reliability of the Microsoft cloud. Will it match the relatively solid record of the current Live properties, or will it run like a Microsoft operating system...

Salesforce.com (force.com and Sites)

• Mark Benioff was adamant at their Dreamforce conference this week that SF is going to kill the idea of on-premises software. It is an ambitious goal; one that smart people like Geva Perry think is going to happen anyway. However, I'm not so sure. The long and the short off it, however, is you can forget any "on-premises" version of Force.com or Sites in the foreseeable future.
• Force.com operates with a custom data model, a custom user interface framework, and a custom domain-specific programming language. While new to most developers, it appears to be extremely easy to learn, and cuts out a lot of the "down and dirty" stuff when it comes to programming against the SF applications and data model.
• Again, while you can go and get you data programatically at will, there are no simple mechanisms for doing so, nor is there anywhere to move APEX code. Portability is not really an option here.
• As in the Google case, SF hides so much of the underlying infrastructure that you just have to trust they can handle your application for you. In SF's case, however, they reportedly rely on vertical scaling, so there may be limits to how high they can scale.
  

Overcast: Conversations on Cloud Computing #2

Geva and I completed the second of our series of podcasts on Tuesday. This is a shortened conversation, as we only had a few days between recording numbers 1 and 2, but it covers some key announcements that were made in that time. Specifically, the show covers:

• Salesforce.com's Force.com Sites and the new relationship between Salesforce and Amazon Web Services. I wrote about this earlier.
• The announcement of cooperation between RightScale and the open source EUCALYPTUS project from the University of California Santa Barbara. You can read more about this on Geva's blog here and here.
• Also mentions of CohesiveFT, Elastra, Google App Engine, Microsoft and more...

Salesforce.com Announces They Mean Business

I had some business to take care of in downtown San Francisco this morning, and on my way to my destination, I strolled past Moscone Center, the site of this year's Dreamforce conference. The news coming out of that conference had peaked my interest a day earlier--I'll get to that in a minute--but when I saw the graphics and catch phrase of the conference, I had to laugh. Not in mockery, mind you; it was just ironic.

There, spanning the vast entrances of both Moscone North and South was nothing but blue skies and fluffy white...wait for it...clouds. In other words, the single theme of the conference visuals was, I can only assume, cloud computing. Not CRM, not "making your business better", but an implementation mechanism; a way of doing IT. That's the irony, in my mind; that in this amazing month or so of cloud computing history, one of the companies most aggressively associating themselves with cloud computing was a CRM company, not a compute capacity or storage provider.

Except, Salesforce.com was already blurring the lines between PaaS and SaaS, even as they open the door to their partners and customers taking advantage of IaaS where it makes sense. Even before Marc Benioff's keynote yesterday, it was clear that force.com was far more than a way to simply customize the core CRM offering. Granted, most applications launched there took advantage of Salesforce.com data or services in one way or another, but there was clear evidence that the SF gang were targeting a PaaS platform that stood alone, even as it provided the easiest way to draw customers into the CRM application.

The core of the new announcement, Sites, appears to simply be an extension of this. The idea behind Sites is to provide a web site framework that allows customers to address both Intranet and Internet applications without needing to run any infrastructure on-premises. Of course, if you find the built in SF integration makes adopting the CRM platform easier, then SF would be happy to help. Their goal, you see, is summed up in the conference catch phrase: "The End of Software". (Of course, let's just ignore the fact that force.com is a software development platform, any way you cut it.)

Skeptical that you can get what you need from a single PaaS offering? Here's where the genius part of the day's announcements come in; simply utilize Amazon for the computing and storage needs that force.com was unable to provide. Heck, yeah.

Allow me to observe something important, here. First, note that Salesforce does not have an existing packages software model; thus, there is no incentive whatsoever to offer an on-premesis alternative. Touche, Microsoft. Second, note that Salesforce.com has no problem whatsoever with partnering with someone who does something better than them. En guarde, Google. Finally, pay attention to the fact Salesforce.com is expanding its business offerings in a way that both serves existing customers in increasingly powerful ways, while inviting new, non CRM customers to use productive tools that just happen to include integration with the core offering. PaaS as a marketing hook, not necessarily a business model in and of itself. (If it succeeds on its own, that's icing on the cake.)

In a three week period that has seen some of the most revolutionary cloud computing announcements, Salesforce.com managed to not only keep themselves relevant, but further managed to make a grab for significant cloud mindshare. Fluffy, white, cloud mindshare.

Overcast: Conversations on Cloud Computing

I'm happy to announce that Geva Perry and I have started a new podcast, titled "Overcast: Conversations on Cloud Computing". The show covers cloud computing, virtualization, application infrastructures and related topics, and we will be inviting a number of prominent guests in coming weeks to inform us and our listeners about both the truly revolutionary and the simply evolutionary aspects of the cloud. We are also both skeptical enough to ask some tough questions about the reality of the cloud from time to time. We hope you'll enjoy the discussion, and provide plenty of feedback.

Geva has some additional details and insights on his blog. Visit the podcast blog at http://overcast.typepad.com, which provides a synopsis of the discussion, and links to relative sites, etc. Subscribe, either via RSS or in iTunes, and if you want to participate in a future show, contact me at james dot urquhart at yahoo dot com.

Here is the summary of Show #1:

We discuss recent news in cloud computing including:

• New features from Amazon Web Services, such as auto-scaling and load-balancing, and how it affects Amazon's eco-system of partners such as RightScale, GigaSpaces and others; as well as AWS coming out of beta and offering SLAs
• Microsoft Azure and whether or not it will help Microsoft attract non .Net developers to it
• CohesiveFT's new VPN-Cubed product
• IBM's announcement that they are offering Lotus Notes as software-as-a-service

We also discuss:

• The potential roles of IBM, HP and Sun in cloud computing
• The recent debate between Tim O'Reilly and Nick Carr on the Network Effect in cloud computing
• The notion of vendor "vision lock-in" -- announcements aimed at making potential customers take pause before selecting a cloud vendor
• and much more...