My Night at Camp

Its late, so I'll keep this brief. I just got home from CloudCamp Silicon Valley on the Sun Microsystems campus in Menlo Park. What a great event. I am completely sold on the unconference format, and very much appreciate the contributions of the organizers and sponsors. If you get a chance to attend a CloudCamp at a city near you, do it. You can't help but broaden your understanding of this loosely defined monstrosity we call cloud computing.

I attended two sessions, and organized a third. The first discussed technologies that could be used to stitch together processes and transactions in the clouds. I think I need to process the ideas there a little more before I write about them, but workflow/ESB concepts are certainly alive and well in the cloud according to this session.

The second session covered the need for common APIs and architectures in the cloud, and what can be done to make J2EE/.NET/whatever applications more "cloud friendly". We discussed the concept of software fluidity, the different needs of IaaS and PaaS based architectures, and ways to address certain traits of distributed systems that force tradeoffs between consistency, availability and partitioning. It was an amazingly cool discussion, and I learned a lot from everyone involved.

The final session was one I organized, targeting the US legal climate for the cloud, and the constitutional issues I've written about here before. Needless to say it was lightly attended, but each participant lent significantly to a far ranging conversation about the Stored Communications Act, the Patriot Act and the Warshak vs. USA case, and what--if anything--can be done about it. I think I'll blog about the outcome of this conversation a little later as well.

I also enjoyed meeting with Sam Charrington, Lew Tucker, Franco Travostino, Paul Lancaster, Luis Sala, and all the others I shared thoughts with throughout the evening. I go to bed tonight inspired and hopeful about the cloud for perhaps the first time in several weeks. Thanks again to those that made it happen.

See You at Camp! CloudCamp, That Is!

For those of you lucky enough to make the CloudCamp Silicon Valley cut (registration is full, except for a few lucky souls who attend SDForum's Cloud Computing and Beyond conference on Wednesday), I look forward to meeting you. I am especially excited about connecting with folks like Geva Perry, Lew Tucker and Franco Travostino, but the entire field looks amazing. (Take a look at Franco's latest paper to see why he's on my list.) It should be a heck of an evening.

I'm hoping to present briefly about what the Stored Communications Act, the Patriot Act and Steven Warshak vs. United States of America are going to do to undercut any technical innovation in the cloud by U.S. companies.

Regardless, stay tuned for my report on the event soon afterward. My schedule has been packed lately, with my work at Alfresco combining with increased responsibilities at home to create a perfect vacuum of blogging time. However I have a couple of what I hope are really good posts in the works, and may have time to get caught up later in the week. In the meantime, I'll continue to send links on my feed.

By the way, I am trying Diigo now for bookmarking, and they are supposed to have the best support for posting links to Blogger. However, while I can get manual posts to work, the automated daily feeds are failing without error (much as they do with the Del.icio.us experimental daily blog post). If anyone can help me figure this out, it would be greatly appreciated. I'll check the comments on Discus (see below) and FriendFeed, so feel free to post either place. Or, contact me directly at jurquhart at yahoo dot com.

Oracle Joins The Cloud--But Does It Their Way

Interesting news this morning from both the Oracle and Amazon camps: Oracle has made available licensing for a broad swath of their infrastructure products to run in the cloud. More importantly, they have made Amazon EC2 AMI's available for Oracle 11g, Oracle Enterprise Manager and Oracle Fusion Middleware are available for free on EC2 right now. Amazon's Jeff Barr also hints at another interesting announcement:

"And if that's not enough, Oracle has also unveiled a new Cloud Management Portal. This is a free, web-based way to manage Oracle software running in the cloud. "

I can't find any more details about the portal at the time of this writing, however.

It is interesting that Oracle is trying to create the impression that it is entering the cloud computing business from their press release ("Oracle Joins Cloud Computing")--seeing that NONE of the products listed are cloud products, per se. They are all traditional infrastructure products than can be used to enhance applications that happen to run in the cloud, but they do not provide a cloud, or even "cloud enable" applications. (The portal *may* run in the cloud, but it is not cloud infrastructure in and of itself.)

Then again, it's not surprising to me that Oracle chose to go this route. Remember their reaction to SaaS? Oracle maintains that traditional perpetual licensing and enterprise sales is the foundation of their business, and that the economics of SaaS just aren't compelling enough to change. (Of course, the Cloud Management Portal would be an interesting exception...but it turns out to be free.) Thus, the logic route for Oracle is not to become a Cloud OS provider or some such thing, but rather to sell their software into the cloud...which is exactly what they have done.

The cost of Oracle in the cloud may be purely support based, if I read Jeff's post correctly, but I'd stay tuned for more on that. My gut feel tells me there is more to the licensing story than is available at this early stage.

9 Sources of Cloud Computing News You May Not Know About

I'm a cloud junkie, as most of you know, and I spend way too much of my time perusing feeds and lists for content that sheds light on cloud trends and challenges. However, I have a secret; I streamline my looking somewhat by leveraging sites that aggregate amazing information into regular lists of stories. Below is a rundown of several of these lists, including a few that you may not have been aware of.

Please note that this is not a list of all of my favorite cloud computing blogs; I have scads of favorites that are not listed here because they are not "news feeds", but rather pure commentary/analysis, vendor blogs, or technical errata. (The problem with categorizing blogs, however, is that many "news feeds" are filled with commentary and analysis as well...*sigh*.)

Without further ado:

• Google Alerts: "Cloud Computing" | "Utility Computing": Actually, I run these two terms in two different alerts, but the two of them are more than I can read most days. "Utility Computing" is rather light, but "Cloud Computing" often runs in the tens of posts/stories a day now.

• cloudfeed.net: Jian Zhen and Michael Mucha run this automated feed of cloud computing and SaaS related stories. The list is dense every single day, and is the quickest way I know of right now to catch on to the more subtle conversations going on about these subjects. It is also lightly (or even not) moderated, so be prepared for tons of "its all been said before" posts.

• On-Demand Enterprise's Cloud Computing Topic: The former Grid Today folks at Tabor Communications have really become a go to resource when it comes to vendor coverage, especially in the traditional enterprise data center software and virtualization space. Good analysis, complete coverage of announcements, and posting of entire press releases (which is very handy, believe me). Not quite as good for the theory stuff, though.

• Avastu Blog: Sustainable Global Clouds: I just discovered Tarry Singhs' excellent blog a few weeks ago. He somehow finds companies and stories that I absolutely do not find elsewhere. Tarry appears to be very well connected in the Indian venture capital world (and, I assume, the EU equivalent, as he states he is from the Netherlands). He also "gets" cloud computing.
  

• GigaOm - Infrastructure: Of the "big" tech bloggers, Om Malik and his team get my vote as the most informed and connected in the cloud computing space. Yeah, they are largely telecom/Web 2.0 happy, but they clearly understand that there is less and less distinction between those markets and the cloud, and they regularly produce news items that make you think. Oh, and you can subscribe to just the Infrastructure feed, which is where most of the good PaaS and IaaS stuff is.

• ZDNet - Software as Services: For the SaaS game, there is no one like Phil Wainewright for a combination of scoops and analysis. In fact, his analysis is so deep I thought of leaving him off this list, but in the end this blog makes me aware of too many new SaaS vendors, applications and services.
  

• TechCrunchIT: Steve Gillmore's new collaboration with Michael Arrington's red-hot TechCrunch isn't a "pure" cloud computing news source, but it scoops just enough that I thought I'd include it. Be prepared to wade through tons of politics and "Social Software" to look for the cloud computing gems, however.

• Data Center Knowledge: Rich Miller's blog is (for me) the source of two key pieces of intelligence in the cloud computing game: data center build-outs, and outages. Rich seems to find every single announcement about new or growing data centers, the companies planning to enter the cloud provider game, and the infrastructure challenges of the cloud. This is one of my favorites for sure.

• The Wisdom of Clouds (RSS/Atom Feed): OK, a bit of shameless self-promotion, but for those of you who have arrived at this site via HTTP, and are not subscribed to my feed, it is important to note that I use Feedburner to publish my daily Del.icio.us bookmarks. In addition, I currently use del.icio.us as my "quick blog" tool, and I comment on every bookmark I record there. Several readers have highlighted this as a favorite aspect of my feed. I am trying to get the del.icio.us "Blog Posting" feature working, so the same lists appear in the HTML pages (so they can be commented on, etc.), but so far no luck.

What are your favorite sources of cloud computing news?

Cloud Computing on Google Groups is Dead to Me

Update: OK, I got a little emotional here. I am upset at the way this played out, but the title and some of the sentiment expressed are a little harsh. Perhaps, "Cloud Computing on Google Groups, I'm moving on" would have been more appropriate. Also, while I will be moving on (unless invited back), the group will no doubt remain active and interesting. Just be aware of how it is moderated--and be aware that there other venues in which to discuss cloud computing.

Unbelievable.

A couple of days ago, I reacted to a post by Sam Johnston outlining a scary exchange with the moderator of the Google Groups Cloud Computing group, Khazret Sapenov, in which Sam found himself locked out of the group with no public or private explanation. I wrote the post because I wanted Khazret and Reuven Cohen (also implicated) to have an opportunity to respond to Sam's charges, and for the community to work this out fairly and openly. I considered the post a "reconciliation post", nothing more, nothing less. (I will admit that I should have rethought the title, though.)

This morning, my first attempt to view the group home page resulted in this:

Now, here's the kicker: I absolutely did not post a thing to the group between the time of the reconciliation post and when I was locked out, so I couldn't have been locked out for a violating the group's rules, whatever they may have been, unless there was a problem well before I posted. This reaction is almost certainly to the reconciliation post itself, which did not at all take place in the group threads.

Google Groups Cloud Computing is dead to me. It's not even worth fighting this. I loved the insights of the group, but there are other viable communities to turn to that are open and transparent, and that can be considered credible. This group is none of those things, apparently.

To have two leading cloud computing bloggers locked out of a supposedly open community--without any public or private explanation--signals bias and dangerous politics.

Here is a little more detail:

• Since I posted the reconciliation post, I've had three other emails confirming Sam's claim that moderation has been strange, arbitrary and at times very slow. Not an overwhelming response, but significant enough to note that Sam is not alone in his thinking.
  

• At the same time, I've had no emails or comments explaining what happened to Sam.

• This morning, I received a comment from Reuven claiming that neither he nor Enomaly have had anything to do with the controversy, despite his founding of the group and (I would imagine) subsequent assignment of moderating duties to Khazret--his Director of R&D, according to LinkedIn. He even offered to join any new open community that might be formed. I will accept that at face value. If I were him, however, I'd have a chat with Kharzet about the costs of his actions. He is killing, or at least maiming, the Google group, and will taint Enomaly's name.

• I remain convinced that this could all be worked out easily by the community if an open conversation was allowed. Since that is not happening, I welcome others concerned about an open, fair exchange of ideas to follow me to greener pastures.

If you are a member of the group, and would like some of the facts in detail, please send me an email at jurquhart at yahoo dot com, and I'll take the time to fill you in.

Here is where I will be hanging out:

• Twitter, user ID "jamesurquhart"

• FriendFeed, user ID "jamesurquhart", and the Cloud Computing room. This is the place I have the highest hopes for, as FriendFeed's features combine streams with discussion to create a truly dynamic community, and the Room helps narrow the discussion to keep it on target.

• Sam has a WIKI started at http://wiki.cloudcommunity.org and I will likely be putting some of my more permanent content there for the community to hack (e.g. the Principles of a Cloud Oriented Architecture series)

• One other intriguing option is Hug The Cloud (an unfortunate name), a Ning community that adds some excellent social networking features to the general discussion. Check it out, let me know what you think.

• Update: I should also say, if anyone out there knows of a good alternative, open cloud computing forum, list, or network, please, please plug it in the comments below! I'll only moderate off topic spam for this one post. :-)
  

This is really a sad day for me. I wish cooler heads had prevailed. See you on the streams!

Cisco's Nexus 1000v and the Cloud: Is it really a big deal?

Yesterday, the big announcements at VMWorld 2008 were about Cloud OSes. Today, the big news seemed to be Maritz's keynote (where he apparently laid out an amazing vision of what VMWare thinks they can achieve in the coming year), and the long rumored Cisco virtual switch.

The latter looks to be better than I had hoped for functionally, though perhaps a little more locked in to VMWare than I'd like. There is an explanation for the latter, however, so it may not be so bad...see below.

I've already explained why I love the Nexus concept so much. Today, Cisco and VMWare jointly announced the Nexus 1000v virtual machine access switch, a fully VI compatible software switch that...well, I'll let Cisco's data sheet explain it:

"The Cisco Nexus™ 1000V virtual machine access switch is an intelligent software switch implementation for VMware ESX environments. Running inside of the VMware ESX hypervisor, the Cisco Nexus 1000V supports Cisco® VN-Link server virtualization technology, providing

• Policy-based virtual machine (VM) connectivity
• Mobile VM security and network policy, and
• Non-disruptive operational model for your server virtualization, and networking teams.

When server virtualization is deployed in the data center, virtual servers typically are not managed the same way as physical servers. Server virtualization is treated as a special deployment, leading to longer deployment time with a greater degree of coordination among server, network, storage, and security administrators. But with the Cisco Nexus 1000V you can have a consistent networking feature set and provisioning process all the way from the VM to the access, aggregation, and core switches. Your virtual servers can use the same network configuration, security policy, tools, and operational models as physical servers. Virtualization administrators can leverage predefined network policy that follows the nomadic VM and focus on virtual machine administration. This comprehensive set of capabilities helps you to deploy server virtualization faster and realize its benefits sooner."

In other words, the 1000v is a completely equal player in a Cisco fabric, and can completely leverage all of the skill sets and policy management available in its other switches. Think "my sys admins can do what they do best, and my network admins can do what they do best". Further more, it supports VN-Link, which allows VMWare systems running on Cisco fabric to VMotion without losing any network or security configuration. Read that last sentence again.

(I wrote some time about about network administrators facing the most change by this whole pooled-resource thing--this feature seals the deal. Those static network maps they used to hang on your wall, showing them exactly what system was connected to what switch port with what IP address are now almost entirely obsolete.)

I love that feature. I will love it even more if it functions in its entirety in the vCloud concept that VMWare is pitching, and all indications are that it will. So, to tell the story here as simply as possible:

• You create a group of VMs for a distributed application in VConsole
• You assign network security and policy via Cisco tools, using the same interface as on the physical switches
• You configure VMWare to allow VMs for the application to get capacity from an external vendor--one of dozens supporting vCloud
• When an unexpected peak hits, your VM cluster grabs additional capacity as required in the external cloud, without losing network policy and security configurations.

Cloud computing nirvana.

Now, there are some disappointments, as I hinted above. First, the switch is not stackable, as originally hoped, though the interconnectivity of VN-Link probably overrides that. (Is VN-Link just another way to "stack" switches? Networking is not my strong point.)

Update: In the comments below, Omar Sultan of Cisco notes that the switches are, in fact, "virtually stackable", meaning they can be distributed across multiple physical systems, creating a single network domain for a cluster of machines. I understand that just enough to be dangerous, so I'll stop there."

More importantly, I was initially kind of ticked off that Cisco partnered so closely with VMWare without being careful to note that they would be releasing similar technologies with Citrix and Red Hat at a minimum. But, as I thought about it, Citrix hitched its wagon to 3TERA, and 3TERA owns every aspect of the logical infrastructure an application runs on. In AppLogic, you have to use their network representation, load balancers, and so on as a part of your application infrastructure definition, and 3TERA maps those to real resources as it sees fit. For network connections, it relies on a "Logical Connection Manager (LCM)":

"The logical connection manager implements a key service that abstracts intercomponent communications. It enables AppLogic to define all interactions between components of an application in terms of point-to-point logical connections between virtual appliances. The interactions are controlled and tunneled across physical networks, allowing AppLogic to enforce interaction protocols, detect security breaches and migrate live TCP connections from one IP network to another transparently."

(from the AppLogic Grid Operating System Technical Overview: System Services)

Thus, there is no concept of a virtual switch, per se, in AppLogic. A quick look at their site shows no other partners in the virtual networking or load balancing space (though Nirvanix is a virtual storage partner), so perhaps Cisco simply hasn't been given the opportunity or the hooks to participate in the Xen/3TERA Cloud OS.

(If anyone at 3TERA would like to clarify, I would be extremely grateful. If Cisco should be partnering here, I would be happy to add some pressure to them to do so.)

As for Red Hat, I honestly don't know anything about their VMM, so I can't guess at why Cisco didn't do anything there...although my gut tells me that I won't be waiting long to hear about a partnership between those two.

This switch makes VMWare VMs equal players in the data center network, and that alone is going to disrupt a lot of traditional IT practices. While I was at Cassatt, I remember a colleague predicting that absolutely everything would run in a VM by the end of this decade. That still seems a little aggressive to me, but a lot less so than it did yesterday.

What the hell is going on with the Cloud Computing group on Google?

Update: There is some counter evidence to Sam's claim that he is the number 3 poster on the Google Groups Cloud Computing group, so I edited this post to reflect what is actually confirmed at this point.

Update 2: Sam points out below that he measured his ranking based on the last month, not all time. I'll leave the text the way it is, as I can't verify that (though I have no reason to doubt it), and the text is still accurate. If anyone in the group can verify Sam's claim, I'll change the text back and qualify it better.

One of the great resources for cloud computing fans and foes alike has been the Google Groups Cloud Computing online community. Started by Reuven Cohen at Enomaly in Toronto, and promoted by many of us participating in its discussions, it has quickly grown from 0 to over 3500 members. It is generally pretty active (though it ranks as "low activity" according to Google), but the sweet spot has been the frank and open discussions on threads that were incredibly informative and civil.

Normally one would praise moderation for keeping the riff raff out, but yesterday Sam Johnston told a story that has me very, very concerned. In the midst of a rant about the Enomalism as "vaporware" (which I won't discuss here), Sam describes an exchange that, if true, indicates abuse and self-serving censorship of the kind that undermines the credibility of the group as an open forum.

Here is what Sam had to say:

"It's worth mentioning that I had good reason to do some background research. My recent post (cached copy) to one of the larger cloud computing Google Groups announcing Cloud User Shell (cush) (a free, open source prototype and the first cloud computing shell) made it through the invisible moderation net but information about its mailing lists was silently redacted and an off-list invitation for "Moderator " (later found to be Khazret Sapenov, Director of R&D at Enomaly) to participate in the list management rudely rejected. When I requested that he "please add a few of the other active community members to [help] administer it" citing that "long blackouts are extremely disruptive" he childishly and silently evicted me from the group, deleted me from the member list, updated the FAQ to read 'This group is moderated...at moderators personal discretion', and worst of all, silently and inexplicably deleted the announcement from the archives. Furthermore, in a stunning display of hubris they have hidden the member list even from members and infringed copyright by retrospectively relicensed the group posts under a Creative Commons license with neither notification nor permission!

Repeated requests to rejoin were denied and as the #3 poster at the time I reached out to Reuven, calling for "an unfettered communications channel which is open for anyone to join and post, and which is not dependent on (nor able to be held hostage by) any one person". Reuven conceded that Khazret was his employee and that this "rather fascist approach to its moderation" was a "recurring theme", adding that he "would love to have [me] involved in [his!?!] cloud book". He promised to take care of it the following week (but didn't) and repeated calls for them to open up the community have gone unanswered. Of course they claim this is an extracurricular activity but it's hardly a basket weaving group, rather a massive conflict of interest directly related to their core [in]competency. Did this heated debate about the private cloud oxymoron really end here for example?"

Reuven and Khazret need the opportunity to respond, and I offer this post as a neutral venue to do so. Assuming they respond with a family friendly response, I will update this post to reflect it. Reuven took the initiative to found the group, as well as CloudCamp, and has an excellent blog, so I'd like to think this is all a big misunderstanding. I find it likely that Sam said something controversial about Enomalism or something, but unlikely that he did anything that justified being expelled.

I also think, however, that the Google Groups group needs to ask the Enomaly guys what their moderation policy is. The group's home page says, "[M]oderation of comments is necessary to prevent spam, personal attacks, profanity, or off-topic commentary." However, it is very hard to see how the Cust post could be seen as clearly falling in any of these categories. Is Reuven looking for independent moderators? If so, he should ask for them via a post in the group, and perhaps cite this controversy as a driving need for someone to step up. Out of 3500+ members, I am sure he would find two or three qualified people to help out.

In fact, perhaps moderation needs to move to a balanced team of, say, 3 people--no two of which work at the same company.

At the very least, transparency MUST be better than it has been in this case; having the number 3 poster a top 2% poster--one with that often forced you to think hard about your positions--cut without announcement or explanation is not acceptable. I, for one, am going to lose trust in the openness of the forum unless transparency and accountability improve.

Let the Cloud Computing OS wars begin!

Today is a big day in the cloud computing world. VMWorld is turning out to be a core cloud industry conference, where many of the biggest announcements of the year are taking place. Take,for instance, the announcement that VMWare has created the vCloud initiative, an interesting looking program that aims to build a partner community around cloud computing with VMWare. (Thanks to the every increasingly cloud news leader, On-Demand Enterprise, for this link and most others in this post.) This is huge, in that it signals a commitment by VMWare to standardize cloud computing with VI3, and provide an ecosystem for anyone looking to build a public, private or hybrid cloud.

The biggest news, however, is the bevy of press releases signaling that three of the bigger names in virtualization are each delivering a "cloud OS" platform using their technology at the core. Here are the three announcements:

• VMWare is announcing a comprehensive roadmap for a Virtual Datacenter Operating System (VDC-OS), consisting of technologies to allow enterprise data centers to virtualize and pool storage, network and servers to create a platform "where applications are automatically guaranteed the right quality of service at the lowest TCO by harnessing internal and external computing capacity."

• Citrix announces C3, "its strategy for cloud computing", which appears to be a collection of products aimed at cloud providers and enterprises wishing to build their own clouds. Specific focus is on the virtualization platform, the deployment and management systems, orchestration, and--interestingly enough--wide area network (WAN) optimization. In the end, this looks very "Cloud OS"-like to me.

• Virtual Iron and vmSight announce a partnership in which they plan to deliver "cloud infrastructure" to managed hosting providers and cloud providers. Included in this vision are Virtual Iron's virtualization platform, virtualization management tools, and vmSight's "end user experience assurance solution" technology to allow for "operating system independence, high-availability, resource optimization and power conservation, along with the ability to monitor and manage application performance and end user experience." Again, sounds vaguely Cloud OS to me.

Three established vendors, three similar approaches to solving some real issues in the cloud, and three attacks on any entrenched interests in this space. All three focus on providing comprehensive management and infrastructure tools, including automated scaling and failover; and consistent execution to allow for image portability. The VMWare and Citrix announcements go further, however, in announcing technologies to support "cloudbursting" in which overflow processing needs in the data center are met by cloud providers on demand. VMWare specifically calls out OVF as the standard that enables this in their release; OVF is not mentioned by Citrix, but they have done significant work in this space as well.

Overall, VMWare has made the most comprehensive announcement, and have a lot of existing products to back up their feature list. However, much of what needs to be done to tightly integrate these products appears yet to be done. I base this on the fact that they highlight the need for a "comprehensive roadmap"--I could be wrong about this. They have also introduced a virtual distributed switch, which is a key component for migration between and within the cloud. Citrix doesn't mention such a thing, but of course the rumor is that Cisco will quite likely provide that. Whether such a switch will enable migration across networks, as VMWare's does (er, will?) is yet to be seen, however (see VMWare's VDC-OS press release). Citrix does, however, have a decent stable of existing applications to support their current vision.

By the way, Sun is working feverishly on their own Cloud OS. No sign of Microsoft, yet...

The long and the short of it is that we have entered into a new era, in which data centers will no longer simply be collections of servers, but will actually be computing units in and of themselves--often made up of similar computing units (e.g. containers) in a sort of fractal arrangement. Virtualization is key to make this happen (though server virtualization itself is not technically absolutely necessary). So are powerful management tools, policy and workflow automation, data and compute load portability, and utility-type monitoring and metering systems.

I worry now about my alma mater, Cassatt, who has chosen to go it largely alone until today. Its a very mature, very applicable technology, that would form the basis of a hell of a cloud OS management platform. Here's hoping there are some big announcements waiting in the wings, as the war begins to rage around them.

Update: No sooner do I express this concern, than Ken posts an excellent analysis of the VMWare announcement with Cassatt in mind. I think he misses the boat on the importance of OVF, but he is right that Cassatt has been doing this a lot longer than VMWare has.

Is the Future of Global Services "Work From Home"?

Software consulting is a heck of a fun gig. However, one of the downsides to this...well...lifestyle, really, is that the big money jobs almost always require a willingness to travel--a lot. There is good reason for this; consultants are expected to be deep experts on specific technologies or processes, and the market for each of those specifics is limited in any one city. However, nation-wide there is plenty of business in most mature markets.

I always loved the job of consulting, but the lifestyle beat me up pretty bad. Truth be told, I probably wouldn't be married with two lovely kids today if I had stayed on the road. I'm just not good at maintaining distance relationships, and I had to get off the road to meet and spend time with the perfect woman before she would agree to marry me. (OK, enough of that schmaltz.)

Something intriguing occurred to me while researching cloud vendors for Alfresco, however. What if the "network centric" nature of the cloud actually creates an opportunity to change the lifestyle of software consulting? What if consultants didn't have to travel for every billable hour, but could do a significant portion--if not all--of their work from a local office, or even from home?

First, think about the possibility. How should, for instance, vendor services be handled when the software is delivered in the cloud?

• If most of the work of the consultant is assisting in planning and reviews, does every engagement need to be face to face, even if neither the hardware nor the network is owned by the client?
• For longer term engagements, given the collaboration tools that are now (and will soon be showing up) on the Web, do teams really need to sit in the same building to be effective?
• If the cost of travel (air and lodging) can be eliminated from the overall cost of using vendor services, would clients be more likely to use the service or less?

I honestly don't know the answers to these questions. But I think the requirements for consulting services are significantly different in the cloud, especially when it comes to what you can do for your client when and from where. I'd be interested in what others think about that.

I do know that there are certain services that will always be face-to-face; workshop facilitation, for instance; or certain kinds of project reviews. However, open source has taught us a lot about how "network organized" teams can work, and I think more and more consulting will look like open source contribution and less "on-site guru". Then, maybe..just maybe...I can be a big time consultant and still tuck my kids into bed every night...

Cloud Computing and the Constitution

A few weeks ago, Mark Rasch of SecurityFocus wrote an article for The Register in which he described in detail the deterioration of legal protections that individuals and enterprises have come to expect from online services that house their data. I'll let you read the article to get the whole story of Stephen Warshak vs. United States of America, but suffice to say the case opened Rasch's eyes (and mine) to a series of laws and court decisions that I believe seriously weaken the case for storing your data in the cloud in the United States:

• The Stored Communications Act, which was used to allow the FBI to access Warshak's email communications without a warrant, his consent, or any form of notification.

• The appeals court decisions in the case that argue:

  1. Even if the Stored Communications Act is unconstitutional, Warshak cannot block introduction of the evidence as "the cops reasonably relied on it"
  2. Regardless of that outcome, the court could not determine if "emails potentially seized by the government without a warrant would be subject to any expectation of privacy"

• The Supreme Court decision in Smith v. Maryland, in which the court argued that people generally gave up an expectation of privacy with regards to their phone records simply through the act of dialing their phone--which potentially translates to removing privacy expectation on any data sent to and accessible by a third party.

Rasch notes that in cloud computing, because most terms of service and license agreements are written to give the providers some right of access in various circumstances, all data stored at a provider is subject to the same legal treatment.

This is a serious flaw in the constitutional protections against illegal search and seizure, in my opinion, and may be a reason why US data centers will lose out completely on the cloud computing opportunity. Think about it. Why the heck would I commit my sensitive corporate data to the cloud if the government can argue that a) doing so removes my protections against search and seizure, and b) all expectations of privacy are further removed should my terms of service allow anyone other than myself or my organization to access the data? Especially when I can maintain both privileges simply by storing and processing my data on my own premises?

Couple this with the fact that the Patriot Act is keeping many foreign organizations from even considering US-based cloud storage or processing, and you see how it becomes nearly impossible to guarantee to the world market the same security for data outside the firewall as can be guaranteed inside.

It is my belief that this is the number one issue that darkens the otherwise bright future of cloud computing in the United States. Simple technical security of data, communications and facilities is a solvable problem. Portability of data, processing and services across applications, organizations or geographies is also technically solvable. But, if the US government chooses to destroy all sense of constitutional protection of assets in the cloud, there will be no technology that can save US-based clouds for critical security sensitive applications.

It may be too late to do the right thing here; to declare a cloud storage or processing facility the equivalent of a rented office space or an apartment building--leased spaces where all constitutional protection against illegal search and seizure remain in full strength. When I was younger and rented an apartment, I had every right to expect law enforcement wishing to access my personal spaces would be required to obtain a warrant and present it to me as they began their search. The same, in my opinion, should apply to data I store in the cloud. I should rest assured that the data will not be accessed without the same stringent requirements for a search warrant and notification.

Still, there are a few things individuals and companies can do today that appear OK to thwart attempts to secretly access private data.

1. Encrypt your data before sending it to your cloud provider, and under no circumstances provide your provider with the keys to that encryption. This means that the worse a provider can be required to do is to hand over the encrypted files. You may even be able to argue that your expectations of privacy were maintained, as you handed over no accessible information to the provider, simply ones and zeros.

2. Require that your provider modify their EULA/ToS to disavow ANY right to directly access your data or associated metadata for any reason. The exception might be file lengths, etc., required to run the hardware and management software, but certainly no core content or metadata that might reveal the relevant details about that content. This would also weaken the government's case that you gave up privacy expectations when you handed your data to that particular cloud provider.

3. Store your data and do your processing outside of the United States. It kills me to say that, but you may be forced into that corner.

If there are others that have looked at this issue and see other approaches (both political and technical) towards solving this (IMHO) crisis, I'd love to hear it. I have to admit I'm a little down on the cloud right now (at least US-based cloud services) because of the legal and constitutional issues that have yet to be worked out in a cloud consumer's favor.

Oh, and this issue isn't even close to being on the radar screen of either of the major presidential candidates at this point. I'm beginning to consider what it would take to get it into their faces. Anyone have Lawrence Lessig's number handy?

Elements of a Cloud Oriented Architecture

In my post, The Principles of Cloud Oriented Architectures, I introduced you to the concept of a software system architecture designed with "the cloud" in mind:

"...I offer you a series of posts...describing in depth my research into what it takes to deliver a systems architecture with the following traits:

1. It partially or entirely incorporates the clouds for at least one layer of the Infrastructure/Platform/Application stack.
2. Is focused on consumers of cloud technologies, not the requirements of those delivering cloud infrastructures, either public or private (or even dark).
3. Takes into account a variety of technical, economic and even political factors that systems running in the "cloud" must take into account.
4. Is focused at least as much on the operational aspects of the system as the design and development aspects

The idea here is not to introduce an entirely new paradigm--that's the last thing we need given the complexity of the task ahead of us. Nor is it to replace the basic principles of SOA or any other software architecture. Rather, the focus of this series is on how to best prepare for the new set of requirements before us."

I followed that up with a post (well, two really) that set out to define what our expectations of "the cloud" ought to be. The idea behind the Cloud Computing Bill of Rights was not to lay out a policy platform--though I am flattered that some would like to use it as the basis of one-- but rather to set out some guidelines about what cloud computing customers should anticipate in their architectures. In this continuing "COA principles" series, I intend to lay out what can be done to leverage what vendors deliver, and design around what they fail to deliver.

With that basic framework laid out, the next step is to break down what technology elements need to be considered when engineering for the cloud. This post will cover only the list of some such elements as I understand them today (and feel free to use the comments below to add your own insights), and future posts will provide a more thorough analysis of individual elements and/or related groups of elements. The series is really very "stream of consciousness", so don't expect too much structure or continuity.

When considering what elements matter in a Cloud Oriented Architecture, we consider first that we are talking about distributed systems. Simply utilizing Salesforce.com to do your Customer Relationship Management doesn't require an architecture; integrating it with your SAP billing systems does. As your SAP systems most likely don't run in Salesforce.com data centers, the latter is a distributed systems problem.

Most distributed systems problems have just a few basic elements. For example:

• Distribution of responsibilities among component parts

• Dependency management between those component parts

• Scalability and reliability

  • Of the system as a whole
  • Of each component

• Data Access and Management

• Communication and Networking

• Monitoring and Systems Management

However, because cloud computing involves leveraging services and systems entirely outside of the architect's control, several additional issues must be considered. Again, for example:

• How are the responsibilities of a complex distributed system best managed when the services being consumed are relatively fixed in the tasks they can perform?

• How are the cloud customer's own SLA commitments best addressed when the ability to monitor and manage components of the system may be below the standards required for the task?

• How are the economics of the cloud best leveraged?

  • How can a company gain the most work for the least amount of money?
  • How can a company leverage the cloud marketplace for not just cost savings, but also increased availability and system performance?

In an attempt to address the more cloud-specific distributed systems architecture issues, I've come up with the following list of elements to be addressed in a typical Cloud Oriented Architecture:

• Service Fluidity - How does the system best allow for static redeployment and/or "live motion" of component pieces within and across hardware, facility and network boundaries? Specific issues to consider here include:

  • Distributed application architecture, or how is the system designed to manage component dependencies while allowing the system to dynamically find each component as required? (Hint: this problem has been studied thoroughly by such practices as SOA, EDA, etc.)
  • Network resiliency, or how does the system respond to changes in network location, including changes in IP addressing, routing and security?

• Monitoring - How is the behavior and effectiveness of the system measured and tracked both to meet existing SLAs, as well as to allow developers to improve the overall system in the future? Issues to be considered here include:

  • Load monitoring, or how do you measure system load when system components are managed by multiple vendors with little or know formal agreements of how to share such data with the customer or each other?
  • Cost monitoring, or how does the customer get a accurate accounting of the costs associated with running the system from their point of view?

• Management - How does the customer configure and maintain the overall system based on current and ongoing technical and business requirements? Examples of what needs to be considered here includes:

  • Cost, or what adjustments can be made to the system capacity or deployment to provide the required amount of service capacity at the lowest cost possible? This includes ways to manage the efficiency of computation, networking and storage.
  • Scalability, or how does the system itself allow changes to capacity to meet required workloads? These changes can happen:
    • vertically (e.g. get a bigger box for existing components--physically or virtually)
    • horizontally (e.g. add or remove additional instances of one or more components as required)
    • from a network latency perspective (adjust the ways in which the system accesses the network in order to increase overall system performance)
  • Availability, or how does the system react to failure or any one component, or any group of components (e.g. when an entire vendor cloud goes offline)?

• Compliance - How does the overall system meet organizational, industry and legislative regulatory requirements--again, despite being made up of components from a variety of vendors who may themselves provide computing in a variety of legal jurisdictions?

Now comes the fun of breaking these down a bit, and talking about specific technologies and practices that can address them. Please, give me your feedback (or write up your criticism on your own blog, but link here so I can find you). Point me towards references to other ways to think about the problem. I look forward to the conversation.

Off Topic: Love DCK's New Look!!!

Congratulations to Rich Miller and the team at Data Center Knowledge for their brilliant new look. I hate to say it, but the old design was clunky and behaved in strange ways for me. So far, the new look is easier on the eyes, better organized and has a few more features. Oh, sure, it also has many more ads, but a guy's got to pay for a site redesign somehow! :-)

Well done, DCK, now get back to reporting the data center market!

Update: The Cloud Computing Bill of Rights

Thanks to all that provided input on the first revision of the Cloud Computing Bill of Rights. The feedback has been incredible, including several eye opening references, and some basic concepts that were missed the first time through. An updated "CCBOR" is below, but I first want to directly outline the changes, and credit those that provided input.

1. Abhishek Kumar points out that government interference in data privacy and security rights needs to be explicitly acknowledged. I hear him loud and clear, though I think the customer can expect only that laws will remain within the constitutional (or doctrinal) bounds of their particular government, and that government retains the right to create law as it deems necessary within those parameters.

   What must also be acknowledged, however, is that customers have the right to know exactly what laws are in force for the cloud systems they choose to use. Does this mean that vendors should hire civil rights lawyers, or that the customer is on their own to figure that out? I honestly don't know.

2. Peter Laird's "The Good, Bad, and the Ugly of SaaS Terms of Service, Licenses, and Contracts" is a must read when it comes to data rights. It finds for enterprises what was observed by NPR the other night for individuals; that you have very few data privacy rights right now, that your provider probably has explicit provisions protecting them and exposing you or your organization, and the cloud exposes risks that enterprises avoid by owning their own clouds.

   This reinforces the notion that we must understand that privacy is not guaranteed in the cloud, no matter what your provider says. As Laird puts it:

   "...[A] customer should have an explicit and absolute right to data ownership regardless of how a contract is terminated."

3. Ian Osbourne asks "should there be a right to know where the data will be stored, and potentially a service level requirement to limit host countries?" I say absolutely! It will be impossible for customers to obey laws globally unless data is maintained in known jurisdictions. This was the catalyst for the "Follow the Law Computing" post. Good catch!

4. John Marsh of GeekPAC links to his own emerging attempt at a Bill of Rights. In it, he points out a critical concept that I missed:

   "[Vendors] may not terminate [customer] account[s] for political statements, inappropriate language, statements of sexual nature, religious commentary, or statements critical of [the vendor's] service, with exceptions for specific laws, eg. hate speech, where they apply."

   Bravo, and noted.

5. Unfortunately, the federal courts have handed down a series of rulings that challenge the ability of global citizens and businesses to do business securely and privately in the cloud. This Bill of Rights is already under grave attack.

Below is the complete text of the second revision of the Cloud Computing Bill of Rights. Let's call the first "CCBOR 0.1" and this one "CCBOR 0.2". I'll update the original post to reflect the versioning.

One last note. My intention in presenting this post was not to become the authority on cloud computing consumer rights. It is, rather, the cornerstone of my Cloud Computing Architecture discussion, in which I need to move on to the next point. I'm working on setting up a WIKI for this "document". Is there anyone out there in particular that would like to host it?

The Cloud Computing Bill of Rights (0.2)

In the course of technical history, there exist few critical innovations that forever change the way technical economies operate; forever changing the expectations that customers and vendors have of each other, and the architectures on which both rely for commerce. We, the parties entering into a new era driven by one such innovation--that of network based services, platforms and applications, known at the writing of this document as "cloud computing"--do hereby avow the following (mostly) inalienable rights:

• Article I: Customers Own Their Data

1. No vendor shall, in the course of its relationship with any customer, claim ownership of any data uploaded, created, generated, modified, hosted or in any other way associated with the customer's intellectual property, engineering effort or media creativity. This also includes account configuration data, customer generated tags and categories, usage and traffic metrics, and any other form of analytics or meta data collection.

   Customer data is understood to include all data directly maintained by the customer, as well as that of the customer's own customers. It is also understood to include all source code and data related to configuring and operating software directly developed by the customer, except for data expressly owned by the underlying infrastructure or platform provided by the vendor.
   

2. Vendors shall always provide, at a minimum, API level access to all customer data as described above. This API level access will allow the customer to write software which, when executed against the API, allows access to any customer maintained data, either in bulk or record-by-record as needed. As standards and protocols are defined that allow for bulk or real-time movement of data between cloud vendors, each vendor will endeavor to implement such technologies, and will not attempt to stall such implementation in an attempt to lock in its customers.

3. Customers own their data, which in turn means they own responsibility for the data's security and adherence to privacy laws and agreements. As with monitoring and data access APIs, vendors will endeavor to provide customers with the tools and services they need to meet their own customers' expectations. However, customers are responsible for determining a vendor's relevancy to specific requirements, and to provide backstops, auditing and even indemnification as required by agreements with their own customers.

   Ultimately, however, governments are responsible for the regulatory environments that define the limits of security and privacy laws. As governments can choose any legal requirement that works within the constraints of their own constitutions or doctrines, customers must be aware of what may or may not happen to their data in the jurisdictions in which data resides, is processed or is referenced. As constitutions vary from country to country, it may not even be required for governments to inform customers what specific actions are taken with or against their data. That laws exist that could put their data in jeopardy, however, is the minimum that governments convey to the market.

   Customers (and their customers) must leverage the legislative mechanisms of any jurisdiction of concern to change those parameters.

   In order for enough trust to be built into the online cloud economy, however, governments should endeavor to build a legal framework that respects corporate and individual privacy, and overall data security. While national security is important, governments must be careful not to create an atmosphere in which the customers and vendors of the cloud distrust their ability to securely conduct business within the jurisdiction, either directly or indirectly.

4. Because regulatory effects weigh so heavily on data usage, security and privacy, vendors shall, at a minimum, inform customers specifically where their data is housed. A better option would be to provide mechanisms by which users can choose where their data will be stored. Either way, vendors should also endeavor to work with customers to assure that their systems designs do not conflict with known legal or regulatory obstacles. This is assumed to apply to primary, backup and archived data instances.
   

• Article II: Vendors and Customers Jointly Own System Service Levels
  

1. Vendors own, and shall do everything in their power to meet, service level targets committed to with any given customer. All required effort and expense necessary to meet those explicit service levels will be spent freely and without additional expense to the customer. While the specific legally binding contracts or business agreements will spell out these requirements, it is noted here that these service level agreements are entered into expressly to protect both the customer's and vendor's business interests, and all decisions by the vendor will take both parties equally into account.
   

   Where no explicit service level agreement exists with a customer, the vendor will endeavor to meet any expressed service level targets provided in marketing literature or the like. At no time will it be acceptable for a vendor to declare a high level of service at a base price, only to later indicate that that level of service is only available at a higher premium price.
   

   It is perfectly acceptable, however, for a vendor to expressly sell a higher level of service at a higher price, as long as they make that clear at all points where a customer may evaluate or purchase the service.

2. Ultimately, though, customers own their service level commitments to their own internal or external customers, and the customer understands that it is their responsibility to take into account possible failures by each vendor that they do business with.

   Customers relying on a single vendor to meet their own service level commitments enter into an implicit agreement to tie their own service level commitments to the vendor's, and to live and die by the vendor's own infrastructure reliability. Those customers who take their own commitments seriously will seek to build or obtain independent monitoring, failure recovery and disaster recovery systems.

3. Where customer/vendor system integration is necessary, the vendor's must offer options for monitoring the viability of that integration at as many architectural levels as required to allow the customer to meet their own service level commitments. Where standards exist for such monitoring, the vendor will implement those standards in a timely and complete fashion. The vendor should not underestimate the importance of this monitoring to the customer's own business commitments.

4. Under no circumstances will vendors terminate customer accounts for political statements, inappropriate language, statements of sexual nature, religious commentary, or statements critical of the vendor's service, with exceptions for specific laws, e.g. hate speech, where they apply.

• Article III: Vendors Own Their Interfaces
  

1. Vendors are under no obligation to provide "open" or "standard" interfaces, other than as described above for data access and monitoring. APIs for modifying user experience, frameworks for building extensions or even complete applications for the vendor platform, or such technologies can be developed however the vendor sees fit. If a vendor chooses to require developers to write applications in a custom programming language with esoteric data storage algorithms and heavily piracy protected execution systems, so be it.
   

   If it seems that this completely abdicates the customer's power in the business relationship, this is not so. As the "cloud" is a marketplace of technology infrastructures, platforms and applications, the customer exercises their power by choosing where to spend their hard earned money. A decision to select a platform vendor that locks you into proprietary Python libraries, for instance, is a choice to support such programming lock-in. On the other hand, insistence on portable virtual machine formats will drive the market towards a true commodity compute capacity model.

   The key reason for giving vendors such power is to maximize innovation. By restricting how technology gets developed or released, the market risks restricting the ways in which technologists can innovate. History shows that eventually the "open" market catches up to most innovations (or bypasses them altogether), and the pace at which this happens is greatly accelerated by open source. Nonetheless, forcing innovation through open source or any other single method runs the risk of weakening capitalist entrepreneurial risk taking.
   

2. The customer, however, has the right to use any method legally possible to extend, replicate, leverage or better any given vendor technology. If a vendor provides a proprietary API for virtual machine management in their cloud, customers (aka "the community", in this case) have every right to experiment with "home grown" implementations of alternative technologies using that same API. This is also true for replicating cloud platform functionality, or even complete applications--though, again, the right only extends to legal means.

   Possibly the best thing a cloud vendor can do to extend their community, and encourage innovation on their platform from community members is to open their platform as much as possible. By making themselves the "reference platform" for their respective market space, an open vendor creates a petrie dish of sorts for cultivating differentiating features and successes on their platform. Protective proprietary vendors are on their own.

These three articles serve as the baseline for customer, vendor and, as necessary, government relationships in the new network-based computing marketplace. No claim is made that this document is complete, or final. These articles may be changed or extended at any time, and additional articles can be declared, whether in response to new technologies or business models, or simply to reflect the business reality of the marketplace. It is also a community document, and others are encouraged to bend and shape it in their own venues.

Why Every Linux Application Known To Man Will Be SaaS Soon

With its big (and well covered) announcement yesterday that it will now provide fixed storage for EC2 instances, Amazon has opened the door for just about anybody with Linux-friendly applications to build a cloud-oriented business. Amazon's Elastic Block Store (EBS) isn't revolutionary in itself--lots of cloud vendors have had block storage for some time (see GoGrid, for instance). However, because its Amazon, and because they understand online commerce better than most, it's just became incredibly simple for an application to be offered in the cloud.

So sit back and enjoy the flood of press releases that are sure to appear over the next 3-6 months.

The core reasons for this go beyond just EBS. A combination of one or more Amazon Machine Images (AMIs), DevPay, EBS, S3 and Premium Support creates a "stack" every bit as important to the cloud as LAMP is to web applications. Create a standard image, deploy it in one or more standard EC2 instances, back it up to S3 and charge for it using DevPay. Support your customer SLAs in partnership through your Premium Services account, and you are every bit as solid a SaaS player as anyone else. Oh, and you likely did it without multitenancy.

Unfortunately its a wholly proprietary stack (built largely on open source), but its a stack nonetheless.

Why would any small or medium sized business with software they want to provide by subscription over the web choose any other option (especially given the success rate of start ups on EC2, as reported by Amazon in a recent post)?

There is, of course, another audience that should care about EBS and its effect on the market place: data center operators.

More resources on EBS:

• Tools and libraries that support EBS
• Detailed overview of EBS architecture and use from Rightscale
• InfoWorld coverage
  

Was "Cloud Computing" Common Before Dell Made A Grab For It?

Cameron Christoffers sympathizes with Dell regarding their argument that the term "cloud computing" was not in wide use when they made their trademark application in March, 2007. That may be so; my own first use of the word "cloud" was in August of that year, but I had referenced an article in ZDNet from August, 2006, that directly quoted Eric Schmidt of Google:

"It starts with the premise that the data services and architecture should be on servers. We call it cloud computing – they should be in a ‘cloud’ somewhere. And that if you have the right kind of browser or the right kind of access, it doesn’t matter whether you have a PC or a Mac or a mobile phone or a BlackBerry or what have you – or new devices still to be developed – you can get access to the cloud…"

Clearly this is evidence that Google used the term widely within their ranks and with their customers, and that a solid argument could be make that the term was in "wide use" among the core techies that cared about the technology elsewhere. The rest of the market didn't care, but it was certainly not a term or slogan that was uniquely invented by Dell.

Still. No wonder the USPTO missed the "commonality" of the term initially.

The Cloud Computing Bill of Rights

Update: Title and version number added before Cloud Computing Bill of Rights text below.

Before you architect your application systems for the cloud, you have to set some ground rules on what to expect from the cloud vendors you either directly or indirectly leverage. It is important that you walk into these relationships with certain expectations, in both the short and long term, and both those that protect you and those that protect the vendor.

This post is an attempt to capture many of the core rights that both customers and vendors of the cloud should come to expect, with the goal of setting that baseline for future Cloud Oriented Architecture discussions.

This is but a first pass, presented to the community for feedback, discussion, argument and--if deserved--derision. Your comments below will be greatly appreciated in any case.

The Cloud Computing Bill of Rights (0.1)

In the course of technical history, there exist few critical innovations that forever change the way technical economies operate; forever changing the expectations that customers and vendors have of each other, and the architectures on which both rely for commerce. We, the parties entering into a new era driven by one such innovation--that of network based services, platforms and applications, known at the writing of this document as "cloud computing"--do hereby avow the following (mostly) inalienable rights:

• Article I: Customers Own Their Data

1. No vendor shall, in the course of its relationship with any customer, claim ownership of any data uploaded, created, generated, modified, hosted or in any other way associated with the customer's intellectual property, engineering effort or media creativity. This also includes account configuration data, customer generated tags and categories, usage and traffic metrics, and any other form of analytics or meta data collection.

   Customer data is understood to include all data directly maintained by the customer, as well as that of the customer's own customers. It is also understood to include all source code and data related to configuring and operating software directly developed by the customer, except for data expressly owned by the underlying infrastructure or platform provided by the vendor.
   

2. Vendors shall always provide, at a minimum, API level access to all customer data as described above. This API level access will allow the customer to write software which, when executed against the API, allows access to any customer maintained data, either in bulk or record-by-record as needed. As standards and protocols are defined that allow for bulk or real-time movement of data between cloud vendors, each vendor will endeavor to implement such technologies, and will not attempt to stall such implementation in an attempt to lock in its customers.

• Article II: Vendors and Customers Jointly Own System Service Levels
  

1. Vendors own, and shall do everything in their power to meet, service level targets committed to with any given customer. All required effort and expense necessary to meet those explicit service levels will be spent freely and without additional expense to the customer. While the specific legally binding contracts or business agreements will spell out these requirements, it is noted here that these service level agreements are entered into expressly to protect the customer's business interests, and all decisions by the vendor will take this into account.
   

   Where no explicit service level agreement exists with a customer, the vendor will endeavor to meet any expressed service level targets provided in marketing literature or the like. At no time will it be acceptable for a vendor to declare a high level of service at a base price, only to later indicate that that level of service is only available at a higher premium price.
   

   It is perfectly acceptable, however, for a vendor to expressly sell a higher level of service at a higher price, as long as they make that clear at all points where a customer may evaluate or purchase the service.

2. Ultimately, though, customers own their service level commitments to their own internal or external customers, and the customer understands that it is their responsibility to take into account possible failures by each vendor that they do business with.

   Customers relying on a single vendor to meet their own service level commitments enter into an implicit agreement to tie their own service level commitments to the vendor's, and to live and die by the vendor's own infrastructure reliability. Those customers who take their own commitments seriously will seek to build or obtain independent monitoring, failure recovery and disaster recovery systems.

3. Where customer/vendor system integration is necessary, the vendor's must offer options for monitoring the viability of that integration at as many architectural levels as required to allow the customer to meet their own service level commitments. Where standards exist for such monitoring, the vendor will implement those standards in a timely and complete fashion. The vendor should not underestimate the importance of this monitoring to the customer's own business commitments.
   

• Article III: Vendors Own Their Interfaces
  

1. Vendors are under no obligation to provide "open" or "standard" interfaces, other than as described above for data access and monitoring. APIs for modifying user experience, frameworks for building extensions or even complete applications for the vendor platform, or such technologies can be developed however the vendor sees fit. If a vendor chooses to require developers to write applications in a custom programming language with esoteric data storage algorithms and heavily piracy protected execution systems, so be it.
   

   If it seems that this completely abdicates the customer's power in the business relationship, this is not so. As the "cloud" is a marketplace of technology infrastructures, platforms and applications, the customer exercises their power by choosing where to spend their hard earned money. A decision to select a platform vendor that locks you into proprietary Python libraries, for instance, is a choice to support such programming lock-in. On the other hand, insistence on portable virtual machine formats will drive the market towards a true commodity compute capacity model.

   The key reason for giving vendors such power is to maximize innovation. By restricting how technology gets developed or released, the market risks restricting the ways in which technologists can innovate. History shows that eventually the "open" market catches up to most innovations (or bypasses them altogether), and the pace at which this happens is greatly accelerated by open source. Nonetheless, forcing innovation through open source or any other single method runs the risk of weakening capitalist entrepreneurial risk taking.
   

2. The customer, however, has the right to use any method legally possible to extend, replicate, leverage or better any given vendor technology. If a vendor provides a proprietary API for virtual machine management in their cloud, customers (aka "the community", in this case) have every right to experiment with "home grown" implementations of alternative technologies using that same API. This is also true for replicating cloud platform functionality, or even complete applications--though, again, the right only extends to legal means.

   Possibly the best thing a cloud vendor can do to extend their community, and encourage innovation on their platform from community members is to open their platform as much as possible. By making themselves the "reference platform" for their respective market space, an open vendor creates a petrie dish of sorts for cultivating differentiating features and successes on their platform. Protective proprietary vendors are on their own.

These three articles serve as the baseline for customer/vendor relationships in the new network-based computing marketplace. No claim is made that this document is complete, or final. These articles may be changed or extended at any time, and additional articles can be declared, whether in response to new technologies or business models, or simply to reflect the business reality of the marketplace. It is also a community document, and others are encouraged to bend and shape it in their own venues.

Comments, complaints or questions can be directed to the author through the comments section below.

"Cloud Computing" Set Free: Dell Application Denied

Sam Johnston--who gets all the credit for breaking the Dell "Cloud Computing" trademark application story, in my opinion--is reporting that the USPTO has sent a "non-final action" to Dell, according to their web site. This is great news. Perhaps the safeguards built into these application processes aren't as bad as some suspected as this story unfolded.

By the way, I may not agree with Sam regarding the pure definition of cloud computing, but I he continues to impress as a blogger. Between Sam, Markus Klems, Kevin Jackson and the Google Groups: Cloud Computing list--not to mention my Google Alerts on "cloud computing"--I find myself constantly reading "dang, I wish I wrote that" posts from new voices these days. These are interesting times, indeed.

Are We Overselling the Cloud to Ourselves?

I was doing some casual reading tonight (which is all I have time to do lately, it seems), when I came across this post from Thomas Wailgum of CIO.com on InfoWorld. (Ain't syndication grand?) The majority of the post is commentary from Gartner about the relative infancy of SaaS ERP solutions relative to their on-premises bretheren. Interesting in and of itself, but not normally worthy of a post here.

However, on the second page, I came across the following quote:

Other inhibitors to more widespread SaaS ERP adoption, Ganly contends, relate to total cost of ownership (TCO). TCO of "SaaS ERP suites likely will be significant and may not compare favorably with on-premises solutions," she adds. This problem applies to vendors as well. SaaS vendors "often have unrealistic expectations of their operating costs," she writes. "The multitenant architecture needed for SaaS ERP suites results in high internal efforts and costs for the initial setup and the ongoing maintenance and upgrade of the system."

Security has also been an issue with SaaS ERP offerings, "especially with regard to financial data and privacy concerns," Ganly writes. "Vendors must prove to organizations that are considering SaaS ERP adoption that their security and privacy concerns are unfounded through super low-cost or no-cost, proof-of-concept trials, encouraging early adoption through value pricing and getting early adopters to share their success stories."

[Emphasis mine.]

It occurs to me that this is a really good point to consider when looking at the economics of the cloud computing market. For SaaS vendors, cost-of-sales is still high, as the sale is (and always will be) a hybrid of the traditional enterprise sales model: high investment in building customer relationships, proving technical and business feasibility, and navigating corporate politics, though likely with fewer of the "big meeting" costs found in traditional relationship sales.

Thus, the "economies of scale" from data center operations may be vastly overshadowed by cost of acquiring customers.

However, a "pure infrastructure" play (such as poster child Amazon), eliminates most of the cost-of-sales if they can prove low barrier to entry and significant flexibility of use. Most customers discover Amazon, get set up for free, then pay nominal charges to figure out for themselves how to use the platform. There is no real data lockin, as the storage services are essentially device storage (as opposed to specific data schemas), so the cost of choosing not to move forward with a pure IaaS vendor is relatively low.

There are few CxO level relationships between AWS and their customers (though I don't doubt there are several with, say, financial services megoliths with deep pockets and an interest in influencing AWS).

The point is, when most technologists think of the cloud, they think of something like Amazon, not something like DemandERP. But much of the value of the cloud comes from getting the resources you need in (usually) an on demand model. If price and experience can't be both superior to on-premises ERP for the customer, and profitable for the vendor...well, as the kids say these days, "fail".

I worry that many of the boutique IaaS vendors are also going to fall into the same trap--not understanding how the cost of acquiring customers to a specialized platform or service will wipe out the economies of scale savings of multitennancy. There will be a lot of churn out there in the coming years, and a lot of wispy corpses floating in the clouds. Caveat emptor.

Oh, and to the point of the efficiency of Amazon's model: Jeff Barr notes that he can't find a failed startup that used EC2/S3 as its core infrastructure:

"One of the major value propositions of Amazon Web Services is the utility pricing plan. That is, you only pay for what you use, and the cost is very low. Sometimes it feels like I am just saying that: not because there is any doubt that it’s true; rather because it’s difficult to produce metrics to back up assertions that “low cost utility pricing” is truly a game changer.

Then it hit me… Looking at the list of Start-Up Project presentations on Slideshare’s site, I realized that not a single one of these companies is “off the air”; that is, they all are still in business. In the Startup world that is nothing short of amazing—especially in this economy. (Some of the decks on Slideshare's site are not from last year’s startup events; however even those other companies appear to be alive and well.) Amazon can’t take all the credit for this track record; however it does seem to be a solid data point that validates the value proposition."

That is amazing, if it holds true.

Is a Grid a Cloud? Probably not, but...

Sam Johnston has recently been writing some very provocative posts (provocative as in "thought producing" as well as, at times, "controversial"). One of his latest is his missive on cloud computing, and the confusion created by vendors pushing their grid platforms as defining cloud computing.

He has some good points, and I recommend reading the post. However, very early on he makes a statement that I think clearly demonstrates his own flawed logic when it comes to the term "private cloud". In the first paragraph, he says:

"Some of this confusion is understandable given issues get complex quickly when you start peeling off the layers, however much of it comes from the very same opportunistic hardware & software vendors who somehow convinced us years ago that clusters had become grids. These same people are now trying to convince us that grids have become clouds in order to sell us their version of a 'private cloud' (which is apparently any large, intelligent and/or reliable cluster)."

[Emphasis mine.]

There's the root problem, right there. By equating a "private cloud" with "any large, intelligent and/or reliable cluster", he misses much of what the private cloud is--and biases his definition from the point of view of traditional job based grid computing (which does act very much like a cluster).

Let's use my alma mater as an example of a private cloud infrastructure vendor that does not sell a clustering platform--at least not in the traditional sense of the word, as it relates to software. Cassatt does not tie a bunch of servers into a single, interconnected unit for a workload run on top of it. In fact, that remains the job of the software platform deployed into Cassatt, if it is indeed desired. There is no software coordination intelligence in Cassatt today (other than some dependency management to control startup and shutdown).

Cassat works purely at the server and OS level. No, it doesn't create an OS cluster, because the OS isn't aware that it is being managed. All that Cassatt does is pool server resources into a general pool that can be assigned as needed to meet capacity (and reliability) demands as defined by the service levels applied to the software payloads. If Cassatt sees that application A needs more capacity, it grabs another server. If an instance of server B goes down, Cassatt creates a new instance with the same IP address and hostname (if safe) as the original.

Cassatt is not job based. Any running server payload, including web applications, enterprise applications or "always on" monitoring and feed reading processes can be hosted in exactly the same manner as batch jobs. Cassatt doesn't do queueing of jobs, it just provisions servers as needed to meet the service levels defined for business workloads.

Read Cassatt's web site for more. They say it much better than I am expressing it now.

The point is, though, that Cassatt is not a cluster, it is a resource pool, and as such acts much more like a cloud than a grid. Sam may say "well, that's just autonomic computing" and he's right, but the cloud is autonomic. So calling an autonomic system running behind an enterprise firewall a "private cloud" is not much of a stretch at all.

By the way, ksankar of http://doubleclix.wordpress.com notes nine great differences between a grid and a cloud. I think he captured more of my own thinking about this subject in that one post than I've been able to express in the last three years. Worth a read as well.

Finally, subscribe to Sam's blog. He's asking some important questions, and deserves your attention.