Monday, February 25, 2008

Comments on Paul Wallis: Cloud Computing

Paul WillisWallis has an excellent post tying the history of prior utility/cloud/grid computing attempts to the current hype. I've been trying to comment for a while, but haven't been able to get comment submission to work until today. This is a reworking of that response, in case it doesn't get through moderation for some reason.

Let me just say that, contrary to Paul's description of my position may sound to others, I am not blindly "pro-cloud". In fact, I firmly recommend that existing enterprise data centers and applications think hard before going "outside" to a commercial capacity-on-demand provider. In most cases, it would actually be better for such enterprises to convert their own infrastructure to a utility computing model first, while the necessary technologies and businesses mature.

I also define the cloud broadly, to include SaaS, PaaS (e.g. force.com) and HaaS (e.g. Amazon, Mosso, etc.). SaaS is in clearly in play today, HaaS is being experimented with, but PaaS may be the most interesting facet of the cloud in the long term.

That being said, Paul provides very valuable information in this post, and I for one very much appreciate the work put onto it. It is very true that bandwidth is something to be nervous about (especially when Amazon charges as much as it does for bandwidth), and I have had some interesting discussions (such as the one Paul references) about how data integration will happen over the cloud. Finally, cloud-lockin is indeed something to be concerned about; as in, what happens if my first choice provider sucks? Can I move my applications, data, etc. to someone else cheaply enough that it doesn't put me out of business? Simon Wardley has a good post on that today.

Update: Er, two seconds and I could have confirmed the spelling of Paul's last name. Sorry, Paul!

HPC in the Cloud

Check out Blue Collar Computing. High Performance Computing is one area that should really benefit from utility computing models. Imagine gaining access to the worlds most powerful computers (with reasonable assistance from experts on programming and deploying on those systems) at a price made reasonable by paying only your "share" of resource usage costs.

Cool to see someone try this business model out for real.

Wednesday, February 20, 2008

Data Goes SLAuto at Oracle

Thanks to Steve Jones, check out this presentation from David Chappell, Oracle VP and CTO of SOA, titled "Next-Generation Grid Enabled SOA". (A shorter written article can be found in at SOA Magazine's site.) Chappell outlines the work that Oracle is doing at turning the traditional model of application scalability on its head; instead of a fixed amount of database resources and scaling the applications/services horizontally, scale the database (using a cool complex adaptive systems approach) and alleviate much of the need to scale apps and services (except for CPU bound services). For someone like me, that's mind blowing.

Add to that the fact that the data management functions are relatively homogenous (though the infrastructure may not be), and aware of its resource utilization, and you can see why they are claiming a certain amount of hardware-metric based SLAuto.

(Hardware metric based SLAuto is based in measurements of hardware components, such as CPU utilization, memory utilization and so on. Software-based SLAuto usually uses business metrics such as transaction rates, active accounts, etc. to make scaling decisions.)

The catch? Well, everything must be written to use the "Data Grid" if its to take advantage of these capabilities. Legacy applications need not apply. (Could be the deal killer for David's "Not your MOM's Bus" concept.)

It seems to me that if Oracle wants this approach to catch on, it should open source a reference implementation as soon as possible. I'm not an expert at the most recent data processing approaches, but it would seem to me that Map-Reduce approaches would be complimentary to the Data Grid. However, Hadoop implementations would generally only be integrated with a data grid if there was an open source alternative. Otherwise, MySQL will continue to be the first choice. Open Source would also speed up integration between the data grid and infrastructure automation such as Cassatt and its competitors.

Dave hints at a URL for more info on the Oracle site, but I can't find it. If anyone tracks it down, I would appreciate any help I can get.

Government Data and the Greater Cloud

These days, so much is being made of cloud computing from the "capacity-on-demand" perspective, that I thought I'd take the time to review an interesting "service" that I consider an element of the "cloud system" in the larger sense. It's not a Web Service as such, but a site that performs a valuable service that can be utilized in business or government applications.

John Udell introduce me to EveryBlock with his discussion of how EveryBlock is exposing the value of free access to government data. This public information site is heavily processing data readily available from public agencies, allowing any user (or other system) to query the data in ways not originally intended by the agency. John has an excellent example of these types of queries, but I played around with the site a little, and I can see that this is an excellent resource. Imagine what this service can do for the legal, construction and journalism industries.

Of course, John notes that the government data isn't nearly as *digitally* available as it needs to be. I hate to "me too" his post, but I have to concurr. These agencies aren't *good* cloud citizens until they expose their public data via a (hopefully simple) API.

(Caveat: I am still trying to determine if EveryBlock has an API, but their site HTML looks parsable enough.)

Many of the "cloud computing" definitions I've seen lately have had to do with how easy it is to move resources around between "capacity-on-demand" vendors. I want to submit that the "cloud system" is everything that is available to support computing via the Internet, including the key services that are ready to be integrated into other applications. Google Maps for instance. Or Flickr. Just as long as they remain decoupled from the clients that use them, any electronically accessible Internet property has a potential to contribute to the cloud system.

Friday, February 15, 2008

A Day of Storage and the Cloud

My reading began this morning with Nick's covereage of the Amazon S3/EC2/AWS outage. Perhaps most interesting to me, though, were the comments. A variety of people responded to note that we perhaps are holding the cloud to impossibly high standards, while others noted that this was supposed to be a distributed service, and an extended downtime like this indicates a certain lack of redundancy. I find this facinating, in light of the recent discussion of cloud lock-in. Not surprising, just facinating.

Let me explain.

While I remain extremely concerned about the proprietary operational approaches taken by most "capacity-on-demand" providers--many based on open source platforms, ironically--I think it is important to acknowledge that:
  1. 100% uptime is unreasonable for any platform in its infancy, including S3
  2. Not everyone will be negatively impacted as much by a three hour outage as some
  3. SLAs should be set if service is extremely critical to a business. Ironically, Amazon has limits on who and what they will provide SLAs for.
  4. Even with a three hour outage, Amazon S3 is probably the best service of its kind...for now.

That last point is critical, as Nick put up another post later in the day highlighting EMC's plans to enter the cloud storage market---in a big way. The competitors to Amazon are coming, and that fact may change the equation for how much leeway Amazon has in the future.

Assuming it is not super onerous to copy data from one provider to another--Storage may in fact be the earliest of the commodity cloud components if this is true--an alternative approach will make it that much simpler for an unsatisfied customer to make a move. This, in turn, will make some who will tolerate an outage now, well, less tolerant.

I anxiously await Amazon's explaination for the glitch.

By the way, Robert Scoble certainly believes Amazon has won the cloud market in its entirety already. He is way off, of course. Do you know how much datacenter capacity there is in corporate America alone? There is no way one company that is spending a fraction of the budget on building new data centers that Microsoft, Google and Yahoo are will create a barrier of entry that high. Amazon is a typical first enterant, ala Netscape. Hopefully the market is different enough, though, that they can build a survivor.

Thursday, February 14, 2008

Latency: Obstacle to cloud computing, or opportunity?

I was challenged in the comments to my Cloud Computing Heats Up post regarding my criticism of pupwhines' post that in turn criticized cloud computing. The anonymous author of the comment thought I was too hard on pupwhines, and wanted to know what my response specifically was to the challenge latency presents to distributed computing. I responded there, but I want to expand a little bit on the topic, as it is indeed important to understand, and backs my contention that there will need to be some software architectural changes made to leverage the cloud system.

(Quick note: I've alluded to this before, but I strongly believe there is no one cloud, but a bunch of siloed clouds today with *some* limited integration between them. More of a frontal system, really.)

Latency is an issue in most IT application environments today. There is no question that "traditional" tiered application design scales well at the processing layer, but has real issues at the data layer. There is simply no easy way to manage a traditional relational database architecture over a widely distributed environment. Pupwhines' contention that joining a table between two SaaS vendor implementations would be disaster is right on. In modern technology terms, it would be insane.

However, this is the disruptive aspect of cloud computing: the architectures you know and love are no longer necessarily best practices in a world where your functionality and capacity is:
  1. not necessarily your own,
  2. not necessarily integrated, and
  3. splayed out across this 5.1×108 km2 rock we live on
There are new technical advances being made today in the companies that already rely on cloud principles (think Google, Amazon, Microsoft, etc.). These advances will change the way you design and deploy software, but they will enable a world where proximity of data means less and less.

In fact, you probably already leverage one of these technical changes: increased bandwidth. Indulge me in some autobiographical narrative to illustrate.

Back in the late '90s, while I was a Senior Principal Consultant with Forte Software, Inc, the legendary(?) distributed application development platform vendor, one of my key roles was advising clients on how to best architect for high performance, high scalability and high availability. Forte was an early service oriented architecture, but it ran on the 10Mb/100Mb networks of the time. Thus, the rule for message passing between components (UI<->service or service<->service) was (in order of priority):
  1. Send as few messages over the network as possible
  2. Send the smallest messages possible

Thus, it was better to send large messages once than many small messages, but you wanted to optimize each message as much as possible.

To this end, best practices was to create data services and to actually deploy these services directly on the database server hardware. It was more important to process the relational mapping of data into the object mapping according to need in a timely fashion--thus avoiding unecessary network traffic--than to divide processing responsibility so that there was no custom application components running on the RDBMS hardware.

Fast forward to the 1G/10G networks of today. From what I am seeing, it is actually considered bad practice to do what I described above. While at Sun, I actually got admonished by a (very competent) manager for suggesting the way around Sun Access Managers horrible performance was to deploy the identity server and database on the same box (with our custom login and registration UIs deployed on separate, horizontally scalable servers). Pure architectural heresy. He was right in many ways: doing so would have put the business logic tier into horizontally locked architecture, but that wasn't his point. "We don't deploy our software on our database servers" was the gist of his argument.

So, faster networks have already changed the so-called "laws of physics" that software architects must design around. Given this, it seems easy to postulate that additional advances in network bandwidth will open additional opportunities for architectural change. In fact, it already has; check out Gigaspaces for a cool (though controversial) alternative to horizontally replicated service architectures.

Will bandwidth really grow at a rate that will make a difference to the current IT generation(s)? Many postulate it has to, even if the core network operators resist. As I noted in my response, Cisco's new Nexus 7000 series is a sign of times to come. Does anyone deny that 40G and 100G networks have the opportunity to change the laws of physics? (Disclaimer: I know just enough about networking to be dangerous, so I may be overstating the case...but change is still clearly on the horizon.)

Even if network bandwidth doesn't change at all, or any additional bandwidth is chewed up by demand at existing rates, there are other software architectural advances that will revolutionize certain kinds of computing. I spoke in my response about MapReduce and its open source implementation, Hadoop. For processing large, distributed data loads, this architecture is eliminating boundaries created by traditional scaleout RDBMS-based approaches. Google has used this approach to tie data from every one of its properties (including acquired properties, such as Blogger) into a single user identity and profile. Talk about a distributed join problem...

(Another quick note: hats off to Google and Yahoo respectively for their work in this space. I know from my past life at Sun what a pain in the whatever this is, and I love the seamlessness I experience on these sites.)

One other major advancement is the increasing sophistication of business integration technologies, from traditional application integration (force.com, boomi.com, BizTalk, Lombardi, etc.) to data integration options (Informatica, Business Objects, etc.) to subscription data propogation techniques. These integration options can allow one to go back to some of the basics I spoke of before: do as much processing as possible on Saas vendor A's infrastructure before sharing the relevant data with vendor B. Not as perfect as a join in many cases, but in a service oriented world, a common, required approach for most.

Perhaps the most important point I want to make today, however, is that today--in the modern IT era--many of these technologies are either future tech or not what was used to build existing applications. Given that, what does an existing datacenter do? Stick to my recommendation; convert your own datacenter into a utility/cloud today, and begin to leverage the maturing compute grid/cloud computing ecosystem as it and your applications mature.

Tuesday, February 12, 2008

Green Aware Programming

monkchips writes about "green aware programming", as coined by Christopher O’Connor, vice-president strategy and market management, Tivoli. I responded and pointed out that "green = cheap" in the utility computing world.

Sunday, February 10, 2008

Analyzing the Green opportunity

I just want to quickly bring Ken Oestreich's analysis of the Green Grid meeting in San Francisco (Day 1 and Day 2), and its aftermath to your attention. Pay special attention to the aftermath post, as it is one of the most well thought out statements of the status and opportunity for the Green Grid organization I have seen.

Ken really knows his stuff with respect to the Green Data Center movement, so if you have any interest in the subject at all, subscribe to his blog. His earlier analysis of DC energy efficiency metrics is an all time classic on the subject.

Friday, February 08, 2008

Off Topic: Blog domain change

With increased interest in Service Level Automation in the Datacenter, I decided to take the advice of many a more successful blogger than me, and register my own domain name for the blog. I debated quite a bit about which name to select, but in the end I wanted a domain that would travel with me regardless of where my career might take me in the future. (No plans to leave Cassatt, but you never know where the future might take you...)

To that end, this blog will now officially reside at http://blog.jamesurquhart.com. The original URL, http://servicelevelautomation.blogspot.com will continue to operate, but will redirect you to the new site. All feeds should also continue to work unchanged.

Please let me know if you have problems by emailing me at james dot urquhart at cassatt dot com.

Thursday, February 07, 2008

The importance of operations to online services customers

I hadn't caught up on Gabriel Morgan's blog in a while, so I'm a week or so late in seeing his interesting post on the importance of operations features in a SaaS product offering. Gabriel works at Microsoft on the team that is looking at the Software plus Services offerings introduced by Ray Ozzie a few months ago. According to Gabriel, being a software product company, Microsoft has occasionally been slow to learn a key lesson in the online services game:

In the traditional packaged software business, product features define what a product is but Customer 2.0 expects to have direct access to operational features within the Service Offering itself.

Take for example Microsoft Word. Product Features such as Import/Export, Mail Merge, Rich Editing, HTML support, Charts and Graphs and Templates are the types of features that Customer 1.0 values most in a product. SaaS Products are much different because Customer 2.0 demands it. Not only must a product include traditional product features, it must also include operational features such as Configure Service, Manage Service SLA, Manage Add-On Features, Monitor Service Usage Statistics, Self-Service Incident Resolution as well. In traditional packaged software products, these features were either supported manually, didn't exist or were change requests to a supporting IT department.

In other words "Service Offering = (Product Features) + (Operational Features)".

Wow. What a simple way to state something I've been concerned about for some time now: as you move your enterprise into the cloud, will your service providers (be it SaaS, HaaS, PaaS or others) provide you with the tools and data you need to successfully operate your business? How will you be able to interact with both the service provider's software and personel to make sure those operations run a) according to your wishes, and b) with no negative impact on your business?

Gabriel goes on:
Guess who builds and supports these Operational Features? Your friendly neighborhood IT department in conjunction with the Operations and Service Offering product group. This raises the quality bar for your traditional IT shop.
Heck, yeah. And guess what? Should a business do something crazy--oh, say, select SaaS products from more than one vendor to integrate into their varied business processes--they will need not only to build solid operational ties with each vendor, but integrate those operational features across vendors. Think about that.

How best to do that? You shouldn't be surprised when I tell you that a key element of the solution is SLAuto under the control of the business. Managing SaaS systems to business-defined service levels will be a critical role of IT in the cloud-scape of tomorrow.

Wednesday, February 06, 2008

Cloud computing heats up

Today's reading has been especially interesting, as it has become clear that a) "cloud computing" is a concept that more and more IT people are beginning to understand and dissect, and b) there is the corresponding denial that comes with any disruptive change. Let me walk you through my reading to demonstrate.

I always start with Nick Carr, and today he did not disappoint. It seems that IBM has posited that a single (distributed) computer could be built that could run the entire Internet, and expand as needed to meet demand. Of course, this would require the use of Blue Gene, an IBM technology, but man does it feed right into Nick's vision of the World Wide Computer. To Nick's credit, he seems skeptical--I know I am. However, it is a worthy thought experiment to think how one would design distributed computing to be more efficient if one had control over the entire architecture from chip to system software. (Er, come to think of it, I could imagine Apple designing a compute cloud...)

I then came across an interesting breakdown of cloud computing by John M Willis, who appears to contribute to redmonk. He breaks down the cloud according to "capacity-on-demand" options, and is one of the few to include a "turn your own capacity into a utility" component. Unfortunately, he needs a little education of these particular options, but I did my best to set him straight. (I appreciate his kind response to my comment.) If you are trying to understand how to break down the "capacity-on-demand" market, this post (along with the comments) is an excellent starting place.

Next on the list was a GigaOm post by Nitin Borwankar stating his concept of "Data Property Rights" and expressing some skepticism about the "data portability" movement. At first I was concerned that he was going to make an argument reinforced certain cloud lock-in principles, but he actually makes a lot of sense. I still want to see Data Portability as an element of his basic rights list, but he is correct when he says if the other elements are handled correctly, data portability will be a largely moot issue (though I would argue it remains a "last resort" property right).

Dana Blankenhorn at ZDNet/open-source covers a concept being put forth by Etelos, a company I find difficult to describe, but that seems to be an "application-on-demand" company (interesting concept). "Opportunity computing", as described by Etelos CEO Danny Kolke describes the complete set of software and infrastructure required to meet a market opportunity on a moments notice. “Opportunity computing is really a superset of utility computing,” Kolke notes. Blankenhorn adds,

"It’s when you look at the tools Kolke is talking about that you begin to get the picture. He’s combining advertising, applications, the cash register, and all the relationships which go into those elements in his model. "

In other words, it seems like prebuilt ecommerce, CRM and other applications that can quickly be customized and deployed as needed, to the hosting solution of your choice. My experience with this kind of thing is that it is impossible to satisfy all of the people, all of the time, but I'm fascinated by the concept. Sort of Platform as a Service with a twist.

Finally, the denial. The blog "pupwhines" remains true to its name as its author whimpers about how Nick "has figured out that companies can write their own code and then run it in an outsourced data center." Those of you that have been following utility/cloud computing know that this misses the point entirely. Its not outsourcing capacity that is new, but its the way it is outsourced--no contracts for labor, no work-order charges for capacity changes, etc. In other words, just pay for the compute time.

With SLAuto, it gets even more interesting as you would just tell the cloud "run this software at these service levels", and the who, what, where and how would be completely hidden from you. To equate that with the old IBM/Accenture/{Insert Indian company here} mode of outsourcing is like comparing your electric utility to renting generators from your neighbors. (OK, not a great analogy, but you get the picture.)

Another interesting data point for measuring the booming interest in utility and cloud computing is the fact that my Google Alerts emails for both terms have grown from one or two links a day, to five or more links each and every day. People are talking about this stuff because the economics are so compelling its impossible not to. Just remember to think before you jump on in.

Sunday, February 03, 2008

Off topic: Hey, my wife is an entrepreneur!!!

This is just too much fun.

Mia has been amazing throughout Emery's pregnancy, birth and early weeks. Her focus and determination has really made the addition of a new "startup" much easier than I anticipated (though its early yet :). She has seen to it that Owen knows he is still her favorite little boy, and I love the time we have been able to spend together between my family leave and the late nights.

She faces the difficult choice of returning to school in the next few weeks, and I just wanted to say publicly that I am so proud of all she is doing. She is the true entrepreneur in our family.

Tuesday, January 29, 2008

One Step To Prepare For Cloud Computing

Some of you may be wondering why I am making such a big stink about software architecture on a blog about service level automation (SLAuto). Well, as Todd Biske points out, "the relationships (and potentially collisions) between the worlds of enterprise system management, business process management, web service management, business activity monitoring, and business intelligence" are easier to resolve if the appropriate access to metrics is provided for a software service. For SLAuto, this means the more feedback you can provide from the service, process, data and infrastructure levels of your software architecture, the easier it is to automate service level compliance.

Let's look at a few examples for each level:
  • Service/Application: From the end user's perspective, this is what service levels are all about. Key metrics such as transaction rates (how many orders/hour, etc.), response times, error rates, and availability are what the end users of a service (e.g. consumers, business stakeholders, etc.) really care about.
  • Business Process: Business process metrics can warn the SLAuto environment about cross-service issues, business rule violations or other extraordinary conditions in the process cycle that would warrant capacity changes at the BPM or service levels.
  • Data Storage/Management: Primarily, this layer can inform the SLAuto system about storage needs and storage provisioning, which in turn is critical to automated deployment of applications into a dynamic environment.
  • Infrastructure: This is the most common form of metric used to make SLAuto decisions today. Such metrics as CPU utilization, memory utilization and I/O rates are commonly used in both virtualized and non-virtualized automated environments.

As noted, digital measurement of these data points can feed an SLAuto policy engine to trigger capacity adjustment, failure recover or other applicable actions as necessary to remain within defined service thresholds. While most of the technology required to support SLAuto is available, the truth is that the monitoring/metrics side of things is the most uncharted territory. As an action item, I ask all of you to take Todd's words of wisdom into account, and design not only for functionality, but also manageability. This will aid you greatly in the quest to build fluid systems that can best take advantage of utility infrastructure today.

Monday, January 28, 2008

It's the labor, baby...

I'm getting ready to go back to work on Wednesday, so I decided today (while Owen is at school and Mia has Emery) to get caught up on some of the blog chatter out there. First, read Nick Carr's interview with GRIDToday. Damn it, I wish this was the sentiment he communicated in "The Big Switch", not the "its all going to hell" tone the book actually conveyed.

Second, Google Alerts, as always, is an excellent source, and I found an interesting contrarian viewpoint about cloud computing from Robin Harris (apparently a storage marketing consultant). Robin argues there are two myths that are propelling "cloud computing" as a buzz phrase, but that private data centers will never go away in any real quantity.

Daniel Lemire responds with a short-but-sweet post that points out the main problem with Robin's thinking: he assumes that hardware is the issue, and ignores the cost of labor required to support that hardware. (Daniel also makes a point about latency being the real issue in making cloud computing work, not bandwidth, but I won't address that argument here, especially with Cisco's announcement today.)

The cost of labor, combined with real economies of scale is the real core of the economics of cloud computing. Take this quote from Nick Carr's GRIDToday interview:
If you look at the big trends in big-company IT right now, you see this move toward a much more consolidated, networked, virtualized infrastructure; a fairly rapid shift of compressing the number of datacenters you run, the number of computers you run. Ultimately … if you can virtualize your own IT infrastructure and make it much more efficient by consolidating it, at some point it becomes natural to start to think about how you can gain even more advantages and more cost savings by beginning to consolidate across companies rather than just within companies.
Where does labor come into play in that quote? Well, consider "compessing of the number of datacenters you run", and add to that to the announcement that the Google datacenter in Lenoir, North Carolina will hire a mere 200 workers (up to 4 times as many as announced Microsoft and Yahoo data centers). This is a datacenter that will handle traffic for millions of people and organizations worldwide. If, as Robin implies, corporations will take advantage of the same clustering, storage and network technologies that the Googles and Microsofts of the world leverage, then certainly the labor required to support those data centers will go down.

The rub here is that, once corporations experience these new economies of scale, they will begin to look for ways to push the savings as far as possible. Now the "consolidat[ion] across companies rather than just within companies" takes hold, and companies begin to shut down their own datacenters and rely on the compute utility grid. Its already happening with small business, as Nick, I and many others have pointed out. Check out Don McAskill's SmugMug blog if you don't believe me. Or GigaOM's coverage of Standout Jobs. It may take decades, as Nick notes, but big business will eventually catch on. (Certainly those startups that turn into big businesses using the cloud will drive some of these economics.)

One more objection to Robin's post. To argue that "Networks are cheap" is a falicy, he notes that networks still lag is speed behind processors, memory, bus speeds, etc. Unfortunately, that misses the point entirely. All that is needed are network speeds that get to the point where functions complete in a time that is acceptible for human users and economically viable for system communications. That function is independent of the network's speed relative to other components. For example, my choice of Google Analytics to monitor blog traffic is solely dependent on my satisfaction with the speed of the conversation. I don't care how fast Google's hardware is, and all evidence seems to point to the fact that their individual systems and storage aren't exceptionally fast at all.

Thursday, January 24, 2008

Data propagation and software fluidity

Jon Udell has an interesting post commenting on Jeff Jonas' explaination of Out-bound Record-level Accountability in Information Sharing Systems. The central thesis of Jeff's post is that tracking who specifically received a given datum is very expensive yet highly necessary in many applications. The example given is that of a user who wishes to no longer receive email from a site they have an account with, or any of the other sites that the original site shared that preference with. How does the original site know who to contact? The high cost is a result of the difficulty in tracking who data has been forwarded to.

John replies very simply that a "publish" model, much like blogging, might be the answer. "Data blogging", coined by fellow blogger Galvin Carr, refers essentially to the problem of syndication, but Udell projects that to a much wider arena of data types. As he notes, there is much evidence out there that "push" models are generally only applicable to edge systems calling "inward". "Publish and Subscribe"-type pull models are far easier to implement when running "outward" from the cloud to edge systems (as well as, generally, within the cloud--aka event-driven architectures).

There are two valuable results of this approach:
  1. The originating system can require users of data to subscribe with a unique identity, and each "pull" of published data could be tracked (if necessary) to identify who is up to date and who isn't.
  2. For software fluidity purposes, it further decouples the originating system from its subscribers, meaning both the subscribers and the originating system can be "moved" from physical environment to physical environment with no loss of communication. The most negative action that could take place here is if the originating publisher's DNS name changed in the course of the move, but redirects and other techniques could even mitigate that issue.

I am commenting on this, of course, largely for the second item. Access to data, services and even edge devices must be very loosely coupled to work in a cloud computing world. This is one great example of how you could architect for that eventuality, in my opinion.

Wednesday, January 23, 2008

Children of the Net: Why Our Decendents Will Love The Cloud

Our children--or perhaps our grandchildren--won't remember a time when there was a PC on every desk, or when you had to go to Fry's Electronics to buy a shrink-wrapped copy of your favorite game. This, as Nick notes frequently in The Big Switch, is one of the real parallels between what our ancestors went through with electrification and what we have yet to go through with compute utilities. Heck, I already find it hard to remember when I didn't have access to the World Wide Web, and in what year all of that changed. Also, I'm frankly already taking the availability of services from the cloud for granted.

My Dad used to tell me stories of when he lived in a house in Scotland with only a few lights and no other electrical appliances, no indoor plumbing and no telephone. I can't imagine living like that, but it was just about 50-60 years ago. Those born in the latter half of the twentieth century (in an industrialized country) are perhaps the first to live a lifetime without seeing or experiencing life without multiple sockets in every room. It is unimaginable what life was like for our ancestors pre-electrification.

There will likely be both positive and negative consequences that come from any innovation, but to the innovator's descendants, they won't remember things any other way. In the end, once basic needs are taken care of, all human kind cares about is lifestyle anyway, so the view of how "good" an "era" is, is largely driven by how well those needs are taken care of. One of those basic needs is the need to create/learn/adapt, but another one is the need for predictability of outcome. This constant battle between the yearn for freedom and the yearn for control is what makes human culture evolve in brilliantly intricate ways.

I for one hold out hope that our descendants will be increasingly satisfied with their lifestyles, which--in the end--is probably what we all want to see happen. Will those lifestyles be better or worse from our perspective as ancestors? Who knows...but it won't really matter, now, will it?

Of course, one of the biggest challenges to humanity is meeting even the basic needs of its entire population. To date, the species has failed to achieve this--the study of economics is largely targeted at understanding why this is. Cloud computing could, as Nick suggests, actually make it more difficult for some groups of people to meet their basic needs, but I would argue that this would be counter productive to the rest of society.

At the core of my argument is the fact that so much of online business is predicated on massive numbers of people being able to afford a given product. Nick argues that life in the newspaper world shows us the future of most creative enterprises; the ease of the masses to create and find content makes it difficult to sell advertising to support newspapers, thus the papers struggle. But if huge numbers of people are out of work, with no one valuing their talents and experience, that will lead to less consumer spending. Less consumer spending will lead to less advertising, which will in turn lead to less income for "the cloud" (i.e. those companies making money from advertising in the cloud). Its a horribly negative feedback cycle for online properties/services, and one I think will fail to come to pass.

The alternative is that the best of the talent out there continue to find ways to get paid, while the masses are still encouraged to participate. Newspaper journalists are already finding opportunities online, though perhaps at a slower pace then some would like. I believe that ventures such as funnyordie.com and even YouTube will create economic opportunities for videographers and film makers to rise above the noise. Musicians are already experimenting with alternative online promotion and sales tools that will change the way we find, buy and consume music. Yes, the long tail will flourish, but the head of the tail will continue to make bank.

The result of this is simply a shifting of the economic landscape, not a wholesale collapse into a black hole. Yeah, the wealth gap thing is a big deal (see Nick's book), but I believe that the rich are going to start investing some of that money back into the system when the new distribution mechanisms of the online world mature--and that should create jobs, fund creative talent and create a new world in which those that adapt thrive, and those that don't struggle.

Did I mention I think the utility computing market is a complex adaptive system?

Sunday, January 20, 2008

Evidence of pending doom and imminent salvation...

Two news articles that occurred as soon as I went offline for the birth of my daughter provide increasing evidence of the importance of service level automation and image portability between vendors:

  • Joyent, one of the most ambitious new "capacity on demand" managed hosting services, has experienced a multi-day outage that has affected two of their prime storage services. No failover path was available to users of the services, and there is no mention of functionality or services to assist customers with moving--temporarily or permanently--to another vendor's service. Odds are high that some of these customers have lost access to key data, or are flying without substantial backups to key systems. Any decision to move to a different servers (like Twitter will according to the post) is on the customer's own dime.

    A prime example of the dangers of vendor lock-in that Simon and I have been warning you about...


  • Oracle has announced its intention to build and sell "Grid 2.0" technology that will target--yes, you heard right--service level automation. Welcome to the SLAuto game boys. I hope you're ready to talk standards for image and policy portability; as well as policy platform interoperability. Otherwise, you're just creating a new DB grid "silo", and not helping anyone in the long run. Please, feel free to educate me if you think otherwise...

These events show the caution that users of cloud services must employ. Be ready to take on increased integration responsibilities as you deploy more and more elements of your datacenter to the cloud, automate more of the management of those elements, and find the product landscape one in which there (still) is no silver bullet. You may not be writing apps, but you sure as heck will be writing the orchestration that will tie the apps you employ into a cohesive business process ecosystem. You may also find yourself writing backup integration again, just in case you experience "Joyent 2.0"...

Thursday, January 17, 2008

Off Topic: Introducing Emery Anne Urquhart


Emery Anne Urquhart
Born 1/16/2008
7lb, 12 oz
19 3/4"
Mom and baby are fine. Dad is scared silly, however...

Tuesday, January 15, 2008

Off Topic:The next two weeks...

Just a quick note about what I will be doing for the next two weeks starting tomorrow morning. At 5:30AM sharp tomorrow, my wife and I will arrive at the hospital for the birth of my daughter, my second child. I will post pictures and/or video when it is available. (Also off topic, I know, but I'm just too proud...)

Once "Baby Girl" has arrived, I will be splitting my time between caring for my son, caring for my wife and baby girl, and caring for all three. In other words, the blogging will suffer a bit. Once we get settled in a bit, I'll start posting again. That may be a few days or a few weeks. Please be patient.

On a vaguely related note, I finally got Feedburner set up for my site, and I was happy to find so many of you were regular subscribers. I hope many of these are mutual subscriptions where I also follow your work, but if you'd like to let me know where and what you post, please post a comment here and I'll check it out.

In the meantime, for utility computing related topics, stay in touch with Nicholas Carr, Simon Wardley and Anne Zelenka. (Anne's post on GigaOM is especially good, and one that I seriously wish I wrote myself. She captured much of what I would want to say about the effect of utility computing on the middle class, and placed Nick's book in exactly the right context.)

Friday, January 11, 2008

The Compute Grid is Like Nothing Before It

In a continuation of the discussion regarding Nick Carr's "The Big Switch: Rewiring the World from Edison to Google" and Yochai Benkler's "The Wealth of Networks: How Social Production Transforms Markets and Freedom", I want to focus today on the shortcomings of the electric utility analogy--or any other analogy I have heard of for that matter--in describing the compute capacity utility story. It is important to note that, while the electricity-as-utility story has dominated the utility computing discussion to date, other interesting analogies have been put forth lately that enlighten some aspects of the compute story while clouding (no pun intended) others.

Let's start with the electric utility analogy that Carr focuses on in his work. Nick does an excellent job of laying out both the history of electric production and distribution in the United States, as well as mapping those to similar aspects of compute utilities. As Nick puts it:
"The commercial and social ramifications of the democratization of electricity would be hard to overstate...Cheap and plentiful electricity shaped the world we live in today. Its a world that didn't exist a mere hundred years ago, and yet the transformation that has played out over just a few generations has been so great, so complete, that it has become almost impossible for us to imagine what life was before electricity began to flow through the sockets in our walls.

Today we're in the midst of another epochal transformation, and its following a similar course. What happened to the generation of power a century ago is now happening to the processing of information. Private computer systems, built and operated by individual companies are being supplanted by services provided over a common grid--the Internet--by centralized data-processing plants. Computing is turning into a utility, and once again the economic equations that determine the way we work and live are being rewritten."
OK, so its hard to argue with the basic premise that we are undergoing a change that is similar to the introduction of cheap, readily available electricity in the early twentieth century. Nick is a master for pointing how the evolution of electric technology fed changes in societal norms, and vice versa. "It's a messy process--when you combine technology, economics and human nature, you get a lot of variables", he writes, "but it has an inexorable logic, even if we can trace it only in retrospect."

Unfortunately, the same can be said about a variety of other technical advances that didn't end up looking like the electric marketplace; take manufacturing, food production, and music and film production, for example. All of these have elements that can be seen as paralleling utility computing, social production or both. Yet none of them really map completely, and the flaws in the analogy have a "chaos"-like ability to magnify as history bears out.

Now, to Nick's credit, he does start Part 2 of the book--his in depth comparison of the social implications of utility computing--with the following comments:
"Before we can understand the implications for users...we first need to understand how computing is not like electricity, for the differences between the two technologies are as revealing as their similarities."
He goes on to highlight the following differences, using them to make key points about how the effects of compute utilities on society may not be nearly as beneficial as the effect of electric utilities:
  1. With electricity, the applications of the commodity lie outside of the utility--i.e. the appliances, electronics, lighting, etc. that consume the power. With computing, the applications themselves are deliverable over the network, and can be shared by anyone that wants to (and is allowed to) use them.


  2. Computing is much more modular than the electric grid, meaning that the components that make up the commodity service (storage, processing, networking) can be split up and offered by a variety of different parties.


  3. The compute utility is programmable; it can be made to perform a variety of custom tasks are required by its customers. Electricity from your basic power outlet is a fixed state commodity--there are exacting standards to what it is and how it is delivered, as well as laws of physics that limit how it can be used.


  4. Choosing an electric utility was generally an all-or-nothing choice; you either got power from the grid, or you had your own power generation. The modularity of computing, however allows for a slow transitional change from private to public consumption. (I think there is a serious flaw in this analogy, for what its worth. Look at the increasing installation of solar power systems in residential applications--all while remaining a part of the grid. This seems to indicate a gradual transition to a hybrid public/private power grid in the electricity space.)


  5. The compute utility allows others to participate directly in creating value for the utility, and do so cheaply and simply. Providing power to the electric grid has always been expensive and very technical (as, I have to admit, is true in my objection in point 4).
These are excellent examples, and are all important to note (even point 4). However, I think Nick fails to note the most important difference between electricity and data processing; namely

data != electricity

There are huge implications to what is being moved over the network versus what is being moved over the power grid, beyond just the programmable elements. These differences are critical when analyzing the compute as utility story, and its a shame he doesn't address them.

For example, checking his index for the terms "security", "data security" or "software security" shows exactly zero entries. When talking about the transition of data vs electricity, it seems critical that one consider the sensitivities that people and organizations have about how it is transmitted. "Privacy" is the subject of a 7 page essay highlighting what we have been willing to give up so easily, but he basically uses the subject to highlight a specific trait of the network without investigating how related issues will cause compute capacity to differ from electricity. My own opinion is that these two subjects--security and privacy--are exactly what will slow down the "total conversion" to centralized computing utilities for customers like banks, classified federal bureaucracies and health care. I spoke of this in detail before.

As noted earlier, others have commented on some of these issues, and have used other analogies like manufacturing to counter the electricity analogy. One excellent example of this is an an article by Michael Feldman of HPCwire in which he argues that a better analogy is food production. As he puts it:

"When food became a commodity, agribusiness conglomerates took over and replaced lots of family farms with much larger, more efficient "factory farms." Today, crops like wheat and soybeans are typically grown on multi-hundred acre land parcels. But not all food products are easily commoditized. Specialty fruits, vegetables, and organic products don't usually lend themselves very well to large-scale production. According to the U.S. Department of Agriculture about a quarter of farm revenue is still generated on family farms. Many of these farms are focusing on these specialty items and have formed cooperative arrangements in order to remain economically viable."

This analogy works from the standpoint that it describes a system in which people care about the varying qualities of the service output by the "utility". For example, we all know the amount of effort spent by the FDA and others to make sure our meats aren't tainted with deadly bacteria. In fact, some specialty food producers have built their marketing message around food safety and health, and many of those are small, boutique producers. Other small players have provided specialty food items to very specific markets with great success. I have believed all along that the compute market will evolve into a few major players and hundreds (thousands?) of small boutique specialty players, especially in the SaaS space. ("Special SaaS with that?" Please forgive me...)

Unfortunately, the food analogy also breaks down in one critical way:

data != food

In this case, its the real, physical nature of food, and the accompanying issues with logistics, cost of production (including fixed real estate costs), and brick-and-mortar sales that don't compare well to the zero marginal production cost nature of data. Replicating food and shipping it to a new customer destination are expensive acts; doing the same with data costs nearly zero. Furthermore, geographic location means nearly nothing for computing. Food, on the other hand is subject to cultural, climatological and logistical limitations to where it can be produced and sold.

For this reason, computing will tend to a much higher level of centralization than food production has seen. Intuitively, one must believe that this will lead to larger displacement of private data centers than would have happened if it was more expensive to share infrastructure.

I'm still trying to digest all of this, but I have a growing feeling that Carr's dependency on the "Edison analogy" (to coin a phrase for no good reason) actually limits the likelihood of some of his arguments. He also seems to assume that the economics of the web won't evolve much from where it is today--largely advertising based, with millions of people willing to do stuff for free and few existing cultural industries willing to produce for online audiences. I want to bring Benkler back into the conversation when I cover this in a later post.

(One side bar on the commercial production of online content: did anyone see the news from NBC today?)

Monday, January 07, 2008

7 Businesses to Start in 2008

Rather than offer a list of predictions for 2008, I thought I'd have some fun suggesting some businesses that could make you money in 2008 or the few years following.

  1. SaaS<-->Enterprise data conversion practice: All those existing enterprise apps will need to have their data migrated to that trendy new SaaS tool; and should anyone actually decide they hate their first vendor, they'll be spending that money again to convert to the next choice. Perhaps they'll even get fed up and return to traditional enterprise software. Easy money.
  2. Enterprise Integration as a Service: No matter how much functionality one SaaS vendor will provide, it will never be enough. Integration will always be necessary, but where/how will it be delivered? Go for the gold with a browser based integration option. Just figure out how to do it better/cheaper/faster than force.com, Microsoft, Google, Amazon, etc...
  3. SaaS meter consolidation service: Given the problem stated in 2 above, who wants 5 or 6 bills where its impossible to trace the cost of a transaction across vendors? Provide a single billing service that consolidates the charges of the vendor stable and provides additional analytic capabilities to break down where costs and revenues come from. Then get ready to defend yourself against the data ownership walls put up by those same vendors (see 4 below).
  4. SaaS/HaaS Customer litigation practice: Given the example of Scoble's experience with Facebook, there are clearly a lot of sticky legal issues to be worked out about "who owns what". Ride that gravy train with litigation expertise in data ownership, vendor contractual obligations and the role of code as law.
  5. SaaS industry (or SaaS customer) data ownership rights lobbyist: Given 4 above, each industry player is going to want their voice in congress to protect/promote their interest. Drive the next set of legislation that screws up online equality and individual rights.
  6. Sys Admin retraining specialist: All those sys admins who will be out of work thanks to cloud computing are going to need to be retrained to monitor SLAs across external vendor properties, and to get good at waiting on hold for customer service representatives.
  7. Handset recycling services: The rate at which "specialized" hardware will evolve will raise the rate of obsolescence to a new high. Somebody is going to make a killing from all those barely used precious metals, silicon and LCD screens going to waste. Why not you?

Friday, January 04, 2008

"Social Production" vs. "Greed" Online

I want to start my comparison of Yochai Benkler's tome, "The Wealth of Networks: How Social Production Transforms Markets and Freedom", and Nick Carr's "The Big Switch: Rewiring the World from Edison to Google" with coverage of the direct critique of the former in the latter.

Benkler proposes that we are entering a new phase of economic history, which he calls the "networked information economy". Counter to the prior industrial economy, this phase is highlighted by the rising effect of "non-market" production on the creation of intellectual capital, made possible by the near zero cost of creating and sharing content on the Internet.

According to Benkler, in a network based economy:

  1. "Individuals can do more for themselves independently of the permission or cooperation of others."


  2. "Individuals can do more in loose affiliation with others, rather than requiring stable, long-term relations, like coworker relations or participation in formal organizations, to underwrite effective cooperation."
As a result of this, says Benkler, "we can make the twenty-first century one that offers individuals greater autonomy, political communities greater democracy, and societies greater opportunities for cultural self-reflection and human connection."

In chapter 7 of Carr's book, titled "From the Many to the Few", Carr makes an argument for the inequitable effects of social networking and unpaid content creation. With specific reference to Benkler and others writing about the rising importance of the so-called "gift economy", he notes that

"[t]here's truth in such claims, as anyone looking at the Web today can see...[b]ut there is a naivete, or at least a short-sightedness, to these arguments as well. The Utopian rhetoric ignores the fact that the market economy is rapidly subsuming the gift economy."
As evidence, Carr notes that two of the most important Web 2.0 acquisitions of the last couple of years--that of Flickr by Yahoo, and YouTube by Google--were driven in large part by the incredible economics of these companies. When Flickr was acquired for $35 million, there were less than 10 people on staff. YouTube had less than 70 employees when they were bought for 1.65 billion.

However, perhaps the most astounding comparison between the two is that both had millions of people producing, organizing and promoting content, but effectively none of them got a single dime of equity. When YouTube was sold, each of the 3 founders got about a third of a billion dollars for 10 months of work. Its hard to argue that Google bought the web site software for that price. Google bought content and traffic, both of which were largely attributable to those unpaid millions.

I think Carr is right, unfortunately, that we overestimate the influence that "open" technologies will have on the incumbent industrial system. Carr notes important evidence like the growing income gap between the richest Americans and the rest of us, as well as the struggle that newspapers and other media companies are having to generate sufficient income to sustain their businesses--and, in turn, their employee's standard of living. I will add that even the distinct line between "open source" and "proprietary" projects is blurring, as Anne Zelenka notes on GigaOM today. The result of this trend will, of course, be mixed. At times the content created out of love, frustration or even narcissism will loosen the grip of corporate systems on our society, but these may always be offset by new controls and entrepreneurial successes by these same systems.

On the other hand, I think Nick is too skeptical about the amount of change that will beset business in the coming decades. It is easy to think of ways to provide equity to those that produce content, and I believe someone will come up with a business that does so in the next year or two. Furthermore, the process of democracy itself may be changed significantly in the next two decades, as both the government and entities seeking influence over the government (or seeking to loosen the control of government) find new ways to tweak the system. John Udell at Microsoft has covered an interesting corollary, public access to government data, and noted some of the progress made in that space.

Those of you that have read me for a while know that I am extremely interested in complexity theory and its applications to technological development. In the end, I believe what we are going to see in the next data is an "edge of chaos" process, where the forces of liberalization continually struggle against the forces of social and economic inertia. In the long term, however, I believe that this process will continually better the lives of those swept up in it; with (significant) luck, the lives of everyone on Earth. What is left to chance, however, is the amount of pain and suffering that may be felt as change takes place.

Wednesday, January 02, 2008

First look at Nick Carr's "The Big Switch" and Yochai Benkler's "The Wealth of Networks"

Welcome back one and all. I hope everyone enjoyed the holidays as much as I did this time. While I enjoyed several visits with family and friends throughout the week, most of my time was spent either playing with my son, or preparing the house for the arrival of my daughter in two weeks. As you might imagine, the latter is taking up most of my mental cycles these days.

I did, however, spend some time reading two books over the break, both covering the broad topic of the effects of Web 2.0 and the compute cloud system on society and culture. One is a very positive economic analysis of what the possibilities may be, while the other is a skeptical comparison of the history of the electric grid with the evolving history of the compute grid.

"The Wealth of Networks: How Social Production Transforms Markets and Freedom", by Yochai Benkler--which can be read for free online--surprised me as being a much more fascinating read than I expected it to be. I knew that Benkler was going for a more formal economic analysis of the effects of "non-market" production online (e.g. videos submitted to YouTube, photos on Flickr, etc.), but his analysis of both the trends and possibilities was actually very easy for anyone in technology to understand, and didn't require a lot of economics knowledge. I'm still working on this one, but I will provide some more in depth discussion in later posts.

Nicholas Carr's latest, "The Big Switch: Rewiring the World from Edison to Google", is everything you would hope from Nick, though perhaps with a little bit darker outlook than expected. However, I believe this is a must read for anyone contemplating the utility computing revolution, as it lays out an honest assessment of the evils that utility computing will bring along with the good. Using the history of the electric utility grid as a model, Nick points out that particular technical revolution brought with it promises of the democratization of humankind, but actually unfolded with much more mixed results. Utility computing will be no exception, Carr argues, and I heartily agree with him--though I am not sure I agree with all of his detailed examples and predictions.

I actually recommend reading these two books in parallel, as I have been. Here's what I did, and I think it allowed me to read both texts with a more critical eye:
  • Read Chapters 1-3 of Benkler to get a sense of the economic arguments about how social production will change the way we interact, generate information and entertainment, and possibly change our political and cultural landscape to create a more egalitarian society.
  • Now read Carr's work in its entirety, mostly to get sucked back to earth about how Benkler's grandiose vision is just that, a vision; much of the positive developments Benkler looks for can easily be countered by opposing forces looking to maintain or enhance the status quo.
  • Now finish Benkler's work to gain a detailed perspective of the economics at work in the online world, but with a more critical eye towards his desired social and political outcomes.

I am still working on Benkler's book, but I can say now that my eyes have been opened to how much change is before us, and how the great value we get from social production is tempered by the effects on certain careers, economic segments and perhaps even the quality of work we produce itself.

I will dig into a few specific subjects soon, comparing Benkler's vision with Carr's, and adding my own "special sauce". I would really welcome comments from my contemporaries who have read one or both of these works, including critiques of my critiques. My intuition tells me that those that understand what is at stake, and what could happen--both good and bad--will have a distinct advantage as the next two decades play themselves out.

Update: Below are links to the follow on posts for this joint review of the two works:

Tuesday, December 18, 2007

Some more skepticism about Amazon WS as a business plan

I've been interested in Don McAskill's review of Amazon's SimpleDB in light of SmugMug's future plans. He is very positive that he can use this service for what it is intended for; infinitely scalable storage and retrieval of small, structured data sets. His post is a good one if you want to get a clearer idea of what you can and shouldn't do with SimpleDB.

However, I worry for Don. As a growing number of voices have been pointing out, committing your business growth to Amazon, especially as a startup, may not be a great thing. Kevin Burton, founder and CEO of spinn3r and Tailrank, notes that this depends on what your processing and bandwidth profiles are, but there are a large number of services that would do better to buy capacity from, say, a traditional managed hosting facility.

Burton uses the term "vendor lock-in" a few times, which certainly echos comments that Simon and I have been making recently. But Burton brings up an additional point about bandwidth costs that I think have to be carefully considered before you jump on the Amazon-as-professional-savior bandwagon. He notes that for his bandwidth intensive business, Amazon would cost 3X what it currently costs spinn3r to access the net.

Burton goes on to suggest an alternative that he would love to see happen: bare metal capacity as a service. Similar to managed hosting, the idea would be for the system vendors to lease systems for a cost somewhat above what it would take to buy the system, but broken down over 2-3 years. Since the credit worthiness of most startups is an issue, lease default concerns can be mitigated by keeping the systems on the vendor's premises. Failure to pay would result in blocked access to the systems, for both the customer and their customers.

I like this concept as a hybrid between the "cloud" concepts and traditional server ownership. Startups can get the capacity they need without committing capital that could be used to hire expertise instead. On the negative side, however, this does nothing to reduce operational costs at the server levels, other than eliminating rack/stack costs. And Burton says nothing about how such an operation would charge for bandwidth, one of his key concerns about Amazon.

There have been a few other voices that have countered Kevin, and I think they should definitely be heard as this debate grows. Jay at thecapacity points out the following:
[B]usiness necessitates an alternate reality and if expediency, simplicity and accuracy mean vendor constraint, so be it.
I agree with this, but I think that it is critical that businesses choose to be locked in with open eyes, and a "disaster recovery" plan should something go horribly wrong. Remember, it wasn't that long ago that Amazon lost a few servers accidentally.

(Jay seems to agree with this, as he ends his post with:
When companies talk about outsourcing these components, or letting a vendor’s software product dictate their business & IT processes… I always check to make sure my lightsaber is close.
This is in reference to Marc Hedlund's post, “Jedi’s build their own lightsabers”.)

Nitin Borwankar, a strong proponent of Amazon SimpleDB commented on Kevin's post that SimpleDB is a long tail play, and that the head of the data world would probably want to run on their own servers. This is an incredibly interesting statement, as it seems to suggest that even though SimpleDB scales almost infinitely from a technical perspective, it doesn't so much from a business prospective.

On a side note, its been a while since I spoke about complexity theory and computing, but let me just say that this tension between "Get'r done" and "ye kanna take our freedom!" is exactly the kind of tension what you want in a complex system. As long as utility/cloud computing stays at the phase change between these two needs, we will see fabulous innovation that allows computing technologies to remain a vibrant and ever innovating ecosphere.

I love it.

Friday, December 14, 2007

Lessons in schitzophrenia from Sun's customers

From Don McAskill (via Robert Scoble) and Jonathon Schwartz comes fascinating insight into the complete dichotomy that is the IT world today. What I find especially interesting is the range of personalities ranging from the paranoid (e.g. "anything Sun does in the Intel/Linux/Windows space is bad for SPARC/Solaris") to the zealot (e.g. "screw what got you here, open everything up and do it low/zero margin").

I'm not surprised that the CTO audience (as represented by McAskill) was more eager to push Sun into new technologies than the CIOs. First, Sun has always been a company by engineers, for engineers, to engineer. Their sales success has come from selling to a technical audience, not a business audience. (Contrast this with IBM, or even Microsoft at the department level.) Second, CIOs are always struggling to keep up with the cost of implementing new technologies, while CTOs are being pushed to discover and implement them--in part to keep their own technical staff's skills relevant in the modern marketplace.

That's not to say that CIOs aren't technology conscious or CTOs don't care about the bottom line--I grossly exaggerated to make a point, after all--but the tendencies indicated by Jonathon aren't surprising in this light.

What I find especially fascinating, however, is that even though both the business and technical cases are made for utility/cloud computing, its the grunts that are blocking implementation in even the most forward thinking data center. Again, utility computing touches everything and everyone, and that is scary as hell, even to a hard core techie.

Thursday, December 13, 2007

"The techno-utility complex" and cloud lock-in

OK, so in the process of commenting on Nick Carr's post, "The techno-utility complex", I came up with a term I like: cloud lock-in. This goes to my earlier conversation about vendor lock-in in the capacity on demand world--aka cloud computing. I like the term because it reinforces the truth: there is no single compute cloud, and the early leaders in the space don't want there to be one. Rather, they are hell bent on collecting your dimes every hour, and making it damn expensive for you to move your revenue stream elsewhere.

My advice stands: if you are greenfield, and data security and access are less of an issue for you, go for EC2, the managed hosting "cloud bank", or the coming offerings from Google or Microsoft. However, if you want to take a more conservative approach towards gaining the economic benefits of utility computing, make your own cloud first.

Wednesday, December 12, 2007

Software fluidity and system security

I came across this fascinating conversation tonight between Rich Miller (whom I've exchanged blogs with before) and Greg Ness regarding the intense relationship between network integrity, system security and VM-based software fluidity. What caught my attention about this conversation is the depth at which Rich, Greg and others have thought about this branch of system security--what Greg refers to as Virtsec. I learned a lot by reading both authors' posts.

I know nothing about network security or virtualization security, frankly, but I know a little about network virtualization and the issues that users have in replicating secure computing architectures across pooled computing resources. Rich makes a comment in the discussion that I want to comment on from a purely philosophical point of view:

Consider this: It's not only network security, but also network integrity that must be maintained when supporting the group migration of VMs. If one wants to move an N-tier application using VMware's VMotion, one wants a management framework that permits movement only when the requirements of the VM "flock" making up the application are met by the network that underpins the secondary (destination) location. By that, I mean:

  • First, the assemblage of VMs need to arrive intact.

    If, because of a change in the underpinning network, a migration "flight plan" no longer results in a successful move by all the piece parts, that's trouble. If disaster strikes, you don't want to find that out when invoking the data center's business continuity procedure. All the VMs that take off from the primary location, need to land at the secondary.


  • Second, the assemblage's internal connections as well as connections external to the "flock" must continue to be as resilient in their new location as they were in their original home.

    If the use of VMotion for an N-tier application results in the a new instance of the application that ostensibly runs as intended, but is susceptible to an undetected, single point of network failure in its new environment, someone in the IT group's network management team will be looking for a new job.
Here is exactly where I believe application architectures are suddenly critical to the problem of software fluidity. In a well contained multi-tier application (a very turn-of-the-millennium concept) it is valid to consider the migration of the "flock" as a network integrity problem. However, when it comes to the modern world of SOA, BPM and application virtualization, suddenly application integrity becomes a dynamic discovery issue which is only partly dependent on network access.

In other words, I believe most modern enterprise software systems can't rely on the "infrastructure" to keep their components running when they are moved around the cloud. Its not good enough to say "gee, if I get these running on one set of VMs, I shouldn't have to worry about what happens if those VMs get moved". Rich hints strongly at understanding this, so I don't mean to accuse him of "not getting it". However, I wonder what Replicate Technologies is prepared to tell their clients about how they need to review their application architectures to work in such a highly dynamic environment. I'd love to hear it from Rich.

Also, from Greg, I'd be interested in knowing if he's thought beyond the effects on network security of virtsec to the effects on application security. At the very least, I think an increasing dependency on dynamic discovery of required resources (e.g. services, data sources, EAI etc.) means an increased need for virtsec to be application aware as well as network aware. I apologize if I'm missing a virtsec 101 concept here, as I haven't yet read all that Greg has written about the subject, but I'm disturbed that the little I've read so far seems to assume that VMs can be managed purely as servers, a common mistake when considering end-to-end Service Level Automation (SLAuto) needs.

I intend to keep one eye on this discussion, as virtsec is clearly a key element of software fluidity in a SOA/BPM/VM world. It is even more critical in a true utility/cloud computing world, where your software would ideally move undetected between capacity offered by entirely disparate vendors. Its no good chasing the cheapest capacity in the world if it costs you your reputation as a security conscious IT organization.

By the way, Rich, I dropped the virtual football after your last post in our earlier conversation...I just found a blog entry I wrote about 6 months ago during that early discussion about VM portability standards that I never posted. Aaaargh... My apologies, because I liked what you were saying, though I was concerned about non-VM portability and application awareness at the time as well. I continue to follow your work.

Monday, December 10, 2007

User Experience and Fluidity (er, Patration...)

First, thanks to Simon in reminding me about his seminal post defining a new key industry term, patration, to define what I call software fluidity. Is he serious? Only your use of the term in every day life will tell... [Insert cheezy smiley face here.]

Second, if you haven't run across it yet, check out the debate between Robert Scoble/Nick Carr and Michael Krigsman/the Enterprise Irregulars about the need for enterprise software vendors to learn from the "drive to sexiness" of consumer software. My personal opinion? I've worked in enterprise software for years, and I still don't understand why engineers take no pride in making something amazing to install, learn and use. All the effort goes into command line tools and cool functions, little goes into human experience. How has Apple remained relevant all of these years? A focus on sexiness, without losing sight of functionality.

I agree with Nick, sexiness and functionality/stability are not mutually exclusive--except in the eyes of most enterprise software vendors...

Wednesday, December 05, 2007

Oracle makes DBs fluid(?)

Well, Oracle is making a play at making databases portable via virtualization. This was a problem in the pure VMWare world, as no one was comfortable with running their production databases in a VM. I'm not saying that is instantly solved by any means, but "certified by Oracle" is a hell of pitch...

http://www.networkworld.com/community/node/21849

How fluid is your software?

I come from a software development background, and I can never quite get the itch to build the perfect architecture out of my system. That's partly why it is so hard for me to blog about power, even though it is an absolutely legitimate topic, and a problem that needs to be attacked from many fronts. However, power is not a software issue, it is a hardware and facilities issue, and my heart just isn't there when it comes to pontificating.

All is not lost, however, as Cassatt still plays in the utility computing infrastructure world, and
I get plenty of exposure to dynamic provisioning, service level automation (SLAuto) and the future of capacity on demand. And to that end, I've been giving a lot of thought to the question of what, if any, software architecture decisions should be made with utility computing in mind.

While a good infrastructure platform won't require wholesale changes to your software architecture (and none at all, if you are willing to live with consequences that will become obvious later in this discussion), the very concept of making software mobile--in the changing capacity sense, not the wireless device sense--must lead all software engineers and architects to contemplate what happens when their applications are moved from one server to another, or even one capacity provider to another. There are a myriad of issues to be considered, and I aim to cover just a few of them here.

The term I want to introduce to describe the ability of application components to migrate easily is "fluidity". The definition of the term fluidity includes "the ability of a substance to flow", and I don't think its much of a stretch to apply the term to software deployments. We talk about static and dynamic deployments today, and a fluid software system is simply one that can be moved easily without breaking the functionality of the system.

An ideally fluid system, in my opinion, would be one that could be moved in its entirety or in pieces from one provider to another without interruption. As far as I know, nobody does this. (3TERA claims they can move a data center, but as I understand it you must stop the applications to execute the move.) However, for purely academic reasons, let's analyze what it would take to do this:


  1. Software must be decoupled from physical hardware. There are currently two ways to do this that I know of:
    • Run the application on a virtual server platform
    • Boot the file system dynamically (via PXE or similar) on the appropriate capacity
  2. Software must loosely coupled from "external" dependencies. This means all software must be deployable without hard coded reference to "external" systems on which it is dependent. External systems could be other software processes on the same box, but the most critical elements to manage here are software processes running on other servers, such as services, data conduits, BPMs, etc.
  3. Software must always be able to find "external" dependencies. Loose coupling, as most of you know, is sometimes easier said than done, especially in a networked environment. Critical here is that the software can locate, access and negotiate communication with the external dependencies. Service registries, DNS and CMDB systems are all tools that can be used to help systems maintain or reestablish contact with "external" dependencies.
  4. System management and monitoring must "travel" with the software. Its not appropriate for a fluid environment to become a Schrodinger's box, where the state of the system becomes unknown until you can reestablish measurement of its function. I think this may be one of the hardest requirements to meet, but at first blush I see two approaches:
    • Keep management systems aware of how to locate and monitor systems as they move from one system to another.
    • Allow monitoring systems to dynamically "rediscover" systems when they move, if necessary. (Systems maintaining the same IP address, for instance, may not need to be rediscovered.)

This is just a really rough first cut of this stuff, but I wanted to put this out there partly to keep writing, and partly to get feedback from those of you with insights (or "incites") into the concept of software fluidity.

In future posts I'll try to cover what products, services and (perhaps most importantly) standards are important to software fluidity today. I also want to explore whether "standard" SOA and BPM architectures actually allow for fluidity. I suspect they generally do, but I would not be suprised to find some interesting implications when moving from static SOA to fluid SOA, for instance.

Respond. Let me know what you think.

Off-topic: Its official, rock beats paper and scissors

Having some fun with Google Trends, I ran the following comparison:


which yielded the following result:

where blue is rock, red is paper and yellow is scissors.
As I read this, rock has consistently beat paper and scissors for four years running.
Of course, my assertion is based on Google's observation that Trends can predict the future.