Monday, December 21, 2009

Reducing atmospheric soot a leveraged global warming play

There's been a lot of discussion of late regarding the contribution of soot and other particulate to global warming. Washington's blog did a nice job of summarizing why soot reduction is important to climate efforts. NASA has been studying the effects of soot for some time. And when Scientific American, BusinessWeek and U.S. News wrote about it, it got me thinking...

In specific, I wondered how much warming comes from areas which are "susceptible" to melting, as a proxy to measure soot's potential influence (light absorption, inducing precipitation, and resulting exposure of darker surfaces under snow & ice)? Fortunately, it's reasonably easy to do a proxy study after a trip to NASA's Goddard Institute for Space Studies to download some GISTEMP data and after doing some programming handywork.

The findings are telling! Warming is accelerated much more (2x or 3x) in areas which fluctuate on either side of freezing, and no so much in areas which remain frozen or never freeze. This may warrant more serious consideration of soot's effects.

What I calculated was the extent (in terms of time and degrees Celsius) spent on both sides of the freezing point for each station. If for example, a given station in the GISTEMP list experienced temperatures always below (or always above) freezing, then it is taken to have no vulnerability to soot-induced thawing. For each of a station's monthly datapoints, I summed up separately the distances above and below freezing and took the minimum of the two. The result is an approximation of the potential for warm days to thaw the freezing from the colder days. Below is a graph showing the results, where I binned and averaged stations together that fell into various "thawing vulnerability" buckets (X-axis), along with corresponding averages within each bucket of 100-year warming trends for the related stations (Y-axis):

The bin labeled "None" holds stations which had all temperature readings below or all above freezing, but not a mix. As the graph progresses to the right, the X-axis shows increasing amounts of vulnerability to thawing, as an increasing amount of freezing temperatures were offset by thawing temperatures (and shown parenthetically is the number of stations which were binned into the designated range). To clarify/exemplify the methodology, if 4 months of data read [-5, -5, +5, +10], then I would sum 10 degrees of freezing and 15 degrees of thawing, resulting in only 10 degrees worth of "thaw vulnerability". Over 4 months that would be (+10 / 4) = 2.5° C/mo. That would dictate the bin in which I would then include the station's normal 100-year warming trend (as calculated by a least squares regression across the most recent 100 years of the station's temperature data). And within each bin I used a simple average of all included stations' 100-year trends, the Y-axis above.

As can be seen from the graph, stations which have more "thaw vulnerability", record substantially more average global warming trends. I added the overall 100-year warming trendline on the graph, the average of participating stations as if they were placed all in one bin. Apparently, "thaw vulnerable" stations are leveraged to global warming at 2x to 3x overall rates. And so, a reasonable inference may be that reducing soot is a highly leveraged way to reduce global warming as soot would have the most impact on areas which are vulnerable to its thawing effects (and those areas happen to be leveraged to warming trends).

As "soot capture" is relatively less expensive than "carbon capture", and given its potential leverage, it also makes for a strong investment case. And by the way, reducing soot comes with an enormous "knock-on effect" of reducing a massive amount of health-care related issues surrounding respiratory problems.

Methodology note: I screened for stations which had a 100-year data series which ended within the current decade (assuming the most recent 100 years would likely yield more accurate readings than otherwise). Fwiw, the chart looks fairly similar if I use recent 50 or 75 year series instead. I also screened out stations in areas which were marked as having 2mm or greater populations (to remove "heat island" effects), though this didn't matter very much.

Disclosure: no positions

Saturday, August 15, 2009

Cloud Pipeline: future of inter cloud provider sneaker-nets

One of the notable frictions surrounding use of cloud computing providers has been the difficulties in getting large data sets into and out of the domain of the cloud provider. Once your data set grows beyond a certain level, it's just not feasible to use the public network to transfer it. Amazon, in May 2009, began addressing this friction by offering an import feature, whereby one can ship them data (on an external SATA/USB drive), and they'll load it into their S3 storage service. And just recently, Amazon added a similar export feature. This is extremely useful between the customer and Amazon, but I believe it's only the beginning of a trend in what's to come to inter cloud "sneaker nets".

There are a slew of interesting use-cases of transferring data sets between various forms of providers, without the customer ever touching the data, nor ever sending physical devices. This of course, would dictate there being some (set of) standards/formats for inter-provider transfer. There are obvious and well known uses such as shipping data off-site for DR (Disaster Recovery) purposes. If the the DR site is also a cloud provider, the transfer should optimally occur between the two providers without the customer being involved in sending media devices. Under the right circumstances, data could be sent directly from the source to destination provider, eliminating the need for the destination to send a media device at all; that would remove one delivery day from the equation. Doing this would likely require some combination of the data being encrypted and the media being properly scrubbed from its previous data. Or starting with a pool of fresh devices on the source provider side, and shipping the used device back to the customer from the destination provider side, with the extra cost of the device added.

"Cloud Pipeline"

A more efficient and seamless transport of large data sets will be a key enabler that will allow the cloud computing landscape to evolve in usage and in number of providers. With that evolution will come a lot of other "touch-less" uses, such as exporting your database through FedEx from a provider such as Amazon to a database analytics specific provider who houses an army of specialized columnar analytics database engines. Or perhaps to a provider that specializes in render farm activities, real-time 3D server-side rendering, massively parallel HPC (High Performance Computing), compliance, de-duplication, compression, bio-informatics, or a host of other specialties. One could actually set up a 'pipeline' of cloud services in this way, moving data to the stage in the pipeline where it is most optimally processed, based on capabilities, geographies, current pricing, etc. Perhaps the next big Pixar-like animation studio company will make use of a Cloud Pipeline. Or perhaps the next big biotech company. It wouldn't be surprising if they start out with some stages of the pipeline in-house, and farm out an increasing amount of work as the cloud evolves.

Cloud Marketplace

Ultimately, there will be market places for cloud computing. But initially, many things must be developed and normalized/standardized before the compute side has the full potential of being "marketized". One example is e-metering, which can't be simply bolted on as an after-thought, but needs to be deeply integrated into layers of the cloud fabric. That may take quite some time before it becomes marketplace friendly.

But the inter-modal data transport (aka "sneaker net" or "FedEx net") level is a level of abstraction at which a cloud marketplace gets interesting in the shorter term. Here we have the opportunity for a given data set to be copied or multiplexed to a set of receiving providers, based on pre-arranged or real-time market criteria. It may be that by the time the data movement occurs, a provider may have come available who can process the data more efficiently, with a lower pricing for the same efficiency, or perhaps just in a more geographically or politically friendly locale. Perhaps a given provider just rolled in a bank of analytics database engines, or maybe they added banks of GPGPUs. These are the kinds of events that could make one provider much more competitive in the market (10 or 100x). As long as a customer can periodically and inexpensively transport copies of their data to another (backup) site, much of the tie-in problem vanishes. It becomes more of a data format standards issue, one that the customer has more influence on.

Keep in mind a related cloud marketplace would require APIs; orchestrating workflows across a cloud pipeline with real-time market based routing would need them. ;-)

Disclosure: no positions

Monday, August 10, 2009

Server side Android, a Google version of Amazon's EC2

While everyone contemplates the place that Android will hold on the mobile device, in home entertainment and on the netbook, there is another interesting use-case for Android that's not yet been talked about. There's no reason that Android, as a complete OS, application stack and ecosystem (including the app market), has to be run on the client side. In environments where multiple users might want to use the same client hardware (monitor, keyboard, mouse, etc), such as at the office, the thin-client model could be a very useful way to access any given user's Android session. This way, the Android session can be displayed at any end-point, be it a desktop, notebook, meeting-room projector, or even smartphone device. Using a VPN or even SSL protected web browser session from home, a user could also bring up their work Android session.

And of course, as soon as one contemplates serving Android sessions from a server farm, virtualization springs to mind. While one could put each Android its own VM, Android is ripe for an application style of virtualization, having only one kernel and multiple application group boundaries. One can achieve much higher consolidation ratios that way. With whatever choice of virtualization style, one can then imagine that the Android sessions are not necessarily constrained to any one company's private datacenter/cloud, but could also be served from a public cloud. If a public cloud provider can put sessions close enough to a given user's current location (networking latency wise), this proposition gets really interesting. For one, because Android could work its way into the consumer and enterprise VDI spaces. And two, because Google owns a lot of datacenters and could potentially go beyond the OS/application stack space, and into owning the execution of user sessions as well as maintain all their data. This would be likely be a reoccurring revenue (rental) type of service, and open the door to some premium options such as backups, latency/bandwidth QoS, execution locality zones, etc. Kind of the Android desktop version of Amazon's EC2/S3 web services.

There are a number of interesting ways to enhance the server-side Android model. For example, one could allow an Android session to seamless migrate from execution on a server to execution within a local hardware environment (using a VM or otherwise). So for example, if you want to "snap to local device", then execution migrates to your local device and the display interface originates from the local hardware rather than be remoted. There's no reason the user has to see or care about this transition. If you want to "snap to home entertainment device", then your Android session moves seamlessly to your TV. Ditto for the display on your car or netbook. To pull this off, it helps if the environments synchronize in the background automatically. And of course, doing all this on any real scale, means one has to have access to a hearty (Google) sized infrastructure.

Adding in one more piece of the puzzle, a thin-client style tablet (or other form factor) which I wrote about recently, would be an excellent way to access a server-side Android session without ever having any hardware smarts or locally resident data (which can be lost of stolen), and yet would also provide a larger interface for smartphones etc. This kind of device could be manufactured inexpensively on mass scales because it has very little in the way of hardware requirements (runs only firmware). But would be a big opportunity for Google branding and penetration into new markets, and would be a gateway to the evolution of for-pay Google services as mentioned. Perhaps this would be something manufactured by the ODMs such as Compal.

But the discussion isn't nearly complete until we talk about gaming! Server side rendering is a new trend, which decouples the amount of compute power from the end-point device, allowing less capable devices to display amazing server-side rendered games (see my previous article). And it has some of the same requirements as above, in terms of placing the sessions close to the end-point (latency wise), having enough data centers to cover important geographic areas, etc. And a hearty amount of the popular smartphone apps tend to be games, making a great synergy with a "cloud based Android". This style of computing could usher in a new era of phenomenal photo-realistic gaming, decoupled altogether from the underlying client-side hardware. Write once, game anywhere...

Disclosure: no positions

Monday, August 3, 2009

Fault tolerance a new key feature for virtualization

VM migration has been a key feature and enabling technology which has differentiated VMware from Microsoft's Hyper-V. Though as you may know, Windows Server 2008 R2 is slated for broad availability on or before October 22, 2009 (also the Windows 7 GA date), and Hyper-V will then support VM migration. So you may be wondering, what key new high-tech features will constitute the next battleground for differentiation amongst the virtualization players?

Five-Nines (99.999%) Meets Commodity Hardware

One such key feature is very likely to be fault tolerance (FT) -- the ability for a running VM to suffer hardware failure on one machine, and to be restarted on another machine without losing any state. This is not just HA (High Availability), it's CA (Continuous Availability)! And I believe it'll be part of the cover-charge that virtualization vendors (VMware, Citrix/XenSource, Microsoft, et al) and providers such as Amazon will have to offer to stay competitive. When I talk about fault tolerance, I don't mean using special/exotic hardware solutions -- I'm talking about software-only solutions which handle fault tolerance in the hypervisor and/or other parts of the software stack.

Here's a quick summary of where the various key vendors are w.r.t. fault tolerance. Keep watch of this space, because the VM migration battle is nearly over now.

VMware's product line now offers Fault Tolerance, which they conceptually introduced at VMworld 2008. This was perhaps the biggest wow-factor feature VMware talked about at that VMworld. FT is not supported in VMware Essentials, Essentials Plus or vSphere Standard editions. It's supported in more advanced(/expensive) versions.

In the Xen camp, there are two distinct FT efforts, Kemari and Remus. Integration/porting to Xen 4.0 are on the roadmap. If/when that occurs, the Xen ecosystem will benefit. After battle-testing, it's easy to conceive of Amazon offering FT as a premium service. It does after all chew through more network capacity, and will necessitate extra high level logic on their part. There's also a commercial FT solution for XenServer from Marathon, called everRun VM.

Microsoft appears to be leveraging a partnership with Marathon for their initial virtualization FT solution. This is probably smart given it allows Microsoft a way to quickly compete on fault tolerance, with a partner that's been doing FT for a living. One would imagine this option will come at a premium though, perhaps a revenue opportunity for Microsoft for big-money customers, with an associated disadvantage vis-à-vis similar features based on free Xen technology and massive scale virtualization (clouds). That may make Marathon a strategic M&A target.

Licensing Issues, Part II

Just when you thought software-in-a-VM issues were mostly resolved, the same questions may be raised again for FT, given there is effectively a shadow copy of any given FT-protected VM. It's not hard to imagine Microsoft aggressively taking advantage of this situation, given they live at both virtualization/OS and application layers of the stack.

Networking is Key

Fault tolerance of VMs is yet another consumer and driver of high bandwidth, low latency networking. The value in the data center is trending from the compute hardware to the networking. FT is another way-point in the evolution of that trend, allowing continuous availability on commodity hardware. You probably won't run it on all your workloads (they will run with a performance penalty), but you might start out with the most critical stateful workloads. If you want to do this on any scale, or with flexibility, architect with lots of networking capabilities. For zero-sum IT budgets, this would mean cheaper hardware and better networking, something that might be a little bitter-sweet for Cisco, given its entrance into the server market.

Disclosure: no positions

Friday, July 31, 2009

Apple Tablet-killer: the Thin-Tablet

While the 'net is abuzz over rumors of the Apple tablet, I'd like to point out a category of device in a form-factor that doesn't yet exist, but would be a killer product. It's also what I believe the CrunchPad tablet should have been designed to be. And that's the "thin^2 tablet". By thin, I mean it's physically thin in dimension, like the iPhone, but it's also thin in the sense that thin-clients are thin when they have nothing but firmware to access a remote server.

The problem I see with a rumored $800-ish device of that size, is that it's highly likely the same buyer will also own a smartphone. For the CrunchPad, at a rumored $400-ish price-point, it's hard to buy into the couch-surfing, coffee shop sipping usage model. In either case, if you already have a capable smartphone, home & work PC, and/or just have an available WiFi network, why duplicate functionality, applications, and user configuration and data files across multiple devices? One company that has identified this kind of thinking is Celio, with their REDFLY product that I wrote about previously. Rather than fall into the trap of providing yet another software stack (see the myriad of netbook-specific OS variants for example), this class of device provides remoting of the end-user experience (screen, keyboard, mousepad, etc) from a local smartphone.

But what I'd like to see is a product that advances in two areas vis-a-vis the REDFLY. First, rather than depend on a smartphone, why not support remote display protocols directly over WiFi etc? Currently, REDFLY is focused on what I call "local remoting". I'd like to see "remote remoting" (as well as local). If you're surfing from your couch, chances are you have WiFi. Why do we need an OS? You can tap directly into your home PC, or run a session from the 'net. Maybe even from Amazon. If you're on the go, why not use the tablet form factor device as a terminal for your smartphone? Just leave your smartphone in your bag, and talk via bluetooth. At home, hand the thin tablet to a family member and let them tap into their own custom environment.

Outside the consumer market, a thin^2 tablet is an excellent proposition for businesses. You can hand them out to employees, walk around the office, take them to meetings, take them home, etc. And data files are never copied to the device. For the educational market, it makes for a universal window into whatever software infrastructure is used (Windows, Linux, etc). Why force making a choice? IMO a sleek, affordable, multi-touch, thin^2 tablet would be the ultimate CrunchPad type of effort.

Beyond that, I'd really like to see thin tablet devices having a dual-mode screen that can function as e-paper, like the Kindle. And flipping mobile device virtualization on its head, why not run Android sessions in the cloud, and remote them back to the device? Then you can tap into your mobile environment from anywhere (thin tablet, home or work PC, web browser, e-console of your car, etc). This would be ripe for an application-level of virtualization (same Linux kernel, multiple application groups) to get really high server utilization ratios.

Who would make such devices? Well, probably at the end of the day there's no margin in the hardware side of this. But there is a lot of business value in the branding and ecosystem enablement. Which is why I think Facebook, Google or Amazon should make one. Any takers?

Disclosure: no positions, related IP

Wednesday, July 29, 2009

A business model for Twitter, Google-style

While the scale first style of attacking a market is still be proven out, getting a critical mass is mostly certainly a key element in the success of a social networking startup. These kinds of startups can pop up seemingly overnight in mass quantities, and one of the key ways to compete is to create an extremely rapid growth of user base and establish a site or service as de facto (and a verb) for the space it's in. This describes the trajectory that Twitter appears to be on.

Scaling to 1 billion users for any one startup is monumentally difficult. Scaling to 10 billion, given the current population, is impossible. Sometime before reaching either size, a startup needs to transition into a real business model. There's always the M&A path, but having a real business model amps up the M&A valuation significantly. In that spirit, here're some thoughts about some changes Twitter could make to allow them to "turn on the revenue" tap when they need to.

Two things I see holding Twitter back from gaining serious revenue potential are 1) you can do a lot from a twitter client without visiting the twitter site and 2) lame SMS-style messages lack much of the richness which would otherwise enable monetization opportunities, as I describe below -- the kinds of things that Google capitalizes on. And as I'll explain, if you can fix #2, you get #1 for free. So really, I believe enhancing Twitter messages will be a key factor in their future business proposition.

To be brief, twitter messages hail back to SMS (text) messages, which are limited to ~160 characters. After reserving 20 characters for the user name, you're left with 140 characters, the size of the Twitter-colored text you just read. If you want to add in a link, you probably will use a URL shortening service and lose another 20 characters or so of text space. There's not heck of a lot you can do in that amount of space. Some people claim this is part of Twitter's charm. Blaise Pascal might have claimed "The present letter is a very long one, simply because I had no leisure to make it shorter." In any case, I'd claim they're giving up significant revenue potential. To demonstrate my point, here's a hypothetical tweet (minus the sender info), which includes a shortened link but no other mark-up:

And here's a similar tweet, if tweets were allowed to be marked-up, both explicitly by the sender and implicitly through automatic means:

A number of improvements are shown: 1) the sender was able to mark-up the phrase "Tesla Model S" with a URL, 2) the phrase "electric car" was highlighted automatically by a keyword (perhaps advertising) engine, 3) the phrase "pic of prototype" was linked to an image file the user attached, 4) a map of the sender's previous or current location is displayed, 5) a (potentially targeted) advertisement is displayed, and 6) a voice version of the message is linked to (could be the sender's recording or voice synthesis). Additionally, links can redirect through Twitter (as shown), so that Twitter can more dynamically decide where to redirect them and collect much richer analytics. The links could also include the Twitter viewer's user name to give further info (not shown).

How would this all work? First is the ability for users to mark-up tweets, attach files, and provide lots of other rich info and meta information. Second, Twitter clients need to be updated to access a much richer API and display richer tweets. But what about SMS? I believe the key here is to separate out the tweet message body from all other stuff (mark-up, attachments, meta info), or at least provide/generate a fairly equivalent alternate text body. This will be passed through to SMS. To make the experience much better though, one could effectively merge the SMS reader and a Twitter client on mobile devices. When an SMS tweet comes through, the client/reader could initially display it in raw form. But as soon as the device reaches networking availability, the client could negotiate with Twitter to identify the message (e.g. each side runs a hashing function on the message body) and convert the SMS tweet to its associated tweet ID in the API world. The mark-up and related info could then be retrieved and used to re-display the raw tweet in its much richer form. Essentially this gives a consistency between the SMS and client worlds, but allows messages to come through SMS (given its robustness and availability w.r.t. mobile data). It also allows words to be used where shortened URLs are currently placed (as shown), since mark-up is moved out of the message.

Many other capabilities could fall out of this: e-biz cards, signatures, per-tweet backgrounds, etc. But the win on the business side is that some Google-class services can be applied, and there is much room for differentiating pay-vs-free accounts. For example, paying accounts might be free of advertising keywords, get indirected less through the Twitter site, perhaps be offered more mark-up capabilities (or at all), get text to voice synthesis for their tweets, etc. This would bring Twitter to a higher plane for use as a professional marketing tool. All without breaking the lowest-common denominator (SMS) as a transport.

And might I suggest a "Twitter Platinum" feature, messages greater than 140 characters...

Disclosure: no positions, related IP

Sunday, July 19, 2009

Yahoo's infrastructural disadvantage to Google: Java performance does not scale

Yahoo(YHOO) uses a Java-based MapReduce infrastructure called Hadoop. This article demonstrates why Java performance does not scale well for large scale compute settings, relative to C++, which is what Google(GOOG) uses for their MapReduce infrastructure.

A couple months ago, I wrote an article about how Hadoop infrastructure should use C++/LLVM, not Java, to be as scalable and efficient as possible. And to be competitive with Google infrastructure. Discussions surrounding Java vs C++ performance often seem to morph into something bordering on religion, are muddled with arguments about various tweaks that can be done in one language or the other, and then dissipate into the abyss of non-action. Very few discussions focus on the real issue.

I thought I'd take a different tact, and benchmark what I believe the real problem with Java is, vis-a-vis its use in large scale settings. Rather than focus on the relative Java-vs-C++ performance, I instead benchmarked the behaviour of multiple benchmarks running concurrently. In a desktop setting, a user may primarily be running one active application. It is possible for the overhead of a single Java VM to get buried in the over-supply of cores/memory/MHz/cache that are available on the PC. But in a large-scale server setting, it's desirable to max out the resources with as many workloads as the hardware can handle, hopefully without making usage of any one resource unbalanced w.r.t. the rest of the resources. And thus, any overhead imparted also means displacement of other work that's not done. Nothing comes for free; sometimes it's just not noticed (which is the "dirty little secret" of Java benchmarking I noted in the mentioned article).

So how does Java performance fare, when there is more than one thing going on? That's what I set out to benchmark. I highly recommend people repeat the same kind of methodology on whatever workloads they deem appropriate. For a quick-and-dirty assessment, I used the benchmarks from here, with the binaries (C++, i686 versions) and compiled Java classes as-is (ran with -server option). But rather than be concerned with Java-vs-C++ performance, I benchmarked each language relative to itself when a number of benchmarks were loaded on the same core.

To do this, I first timed each C++ benchmark individually. Based on those times, I created bundles of benchmarks to be run sequentially, each bundle taking approximately 30 seconds to complete end-to-end. Then for each of Java and C++ separately, I ran from 2 to 10 bundles both serially and in parallel, to see how much more efficiently the system could run the work when it had access to all the work-to-be-done in parallel. This is multi-tasking, and it's how real systems work. Any Java overhead will impart "displacement" of some kind, be it in terms of MHz, cache consumption, etc. And this is the kind of methodology that will illuminate such overhead in real terms.

The above graphic shows the results. Given concurrency, the system can complete Java workloads (bundles) about 15% faster than for the serial case. But for C++, it's about 30% faster. Benchmarking other (more real) workloads will have differing results, and I'd like to encourage others to do so. Note that this C++ multi-tasking advantage is cumulative with whatever gains it may have over Java on single task benchmarks. Keep in mind that large cluster scale applications are the kinds that are worth running after profile-guided compilation. This is a way to offer C++ applications some of the dynamic profiling gains that Java offers, without the Java overhead.

For reference:
bundle 1: matrix + nestedloop + random + sieve
bundle 2: fibo + hash
bundle 3: hash2 + heapsort + matrix + strcat
bundle 4: methcall + random + sieve + strcat
bundle 5: nestedloop + objinst + hash
bundle 6: sieve + random + nestedloop + matrix
bundle 7: hash + fibo
bundle 8: strcat + matrix + heapsort + hash2
bundle 9: strcat + sieve + random + methcall
bundle 10: hash + objinst + nestedloop
For some other reading, you can look at why the Hypertable project chose C++ over Java. And to clear up some mis-conceptions: 1) no, LLVM does not JIT C/C++ code, but it does offer later stage optimizations relative to traditional compilation and linking, and 2) Google's Dalvik (Java-like) VM is an endpoint (desktop, mobile device) technology, and not as relevant to the focus of this article.

Disclosure: no positions

Monday, July 13, 2009

Venture 3.0, Andreessen Horowitz will change venture capital forever

The announcement of the new VC firm, Andreessen Horowitz, and their first $300 million fund, is not just the entry of yet another high-profile person into professional venture capital. It delineates the emergence of a new style of VC, a recipe of successful venture capital going forward, and the Darwinistic demise of those who do not quickly adapt to it.

I've been dialed into startups on the entrepreneur side for 15 years. It's pretty clear to me, the conventional ways of venture capitalism are no longer effective. Entrepreneurs have gotten smarter, are much more informed, and are seeking alternative ways to fund startup companies. In the age of TheFunded ("the Yelp of the VC world"), it's become imperative to think about the funding process as a customer service industry. Treat an entrepreneur poorly, get some bad juju added to your rating.

What's even more difficult to contend with, is that the rate of technology change is accelerating. The Stone Age lasted about 2 million years, the Bronze Age about 2000 years. Twitter is 3 years old. We are moving faster like some kind of technological Doppler effect. The duration of a "technology generation" is probably in the range of 6 months to 2 years. Now think about this; imagine taking 6 months to go through the funding process for a startup. You might be obsolete before you get started! Years ago, when a technology generation may have been 10 years, or even 5, consuming 6 months of overhead in the funding process wasn't the end of the World. It can easily be the death-knell now.

Although the venture world is thought of as the bastion of risk-taking, the truth is many of them are more conservative than you may think; they wait for markets to emerge first (and be proven out by others), then jump on them quickly -- the "fast follower" approach. Again, this strategy worked much better with longer technology generations. But it's quickly hitting the skids with today's rate-of-change. This fairly recent phenomena is pushing many VCs to move up into later-stage financing. Why? If you think about it, funding later-stage startups in proven markets is the same thing as going back in time -- back to startups attacking previous and longer duration technology generations. Rather than adapt their models to new circumstances, they're chasing history. Good luck. At the top of the heap, are other types of funds (hedge funds, private equity, etc) pushing down the financing stack. The early stages funding void left by VCs moving up, is being filled by super-angels and angel syndicates on the bottom. This whole picture is going to get ugly.

What VCs really need to do, is to get much more aggressive and quicker to fund seed-stage startups, network harder and broader, get more dialed into by-the-minute developments, and get on-board a fresh crop of new faces who are the pioneers of what's happening next -- they will often not have the long resumes, "brand names" that VCs so revere, and will probably sound crazy as hell. And by the way, nearly every startup funded will need to change shape drastically as it progresses. Welcome to the new order!

And then came the announcement from Andreessen Horowitz. It took the likes of a team which has angel invested in 45 tech startups in the last five years, to break the Da Vinci Code of startups (which has been hiding in plain site, in places such as Judy Estrin's book). These guys are spot on. Fund lots of initial stage startups, see which ones survive, and then go in with some real money. And just look at the sacrilege: focus on the importance of the tech founders being the CEO (what, you don't want to replace them right away?), don't bother taking boards seats (or even bothering to create a board) for initial stage startups, unafraid of new business models, and more. This is what adaptation looks like! That's how you get access to tomorrow's Google.

To add some texture to just how competitive the VC landscape is, here's a quote from Andreessen:
There are, he says, on average 15 tech companies launched a year that will ultimately do $100 million a year in revenues, and these companies are responsible for 97 percent of the returns in the venture industry overall.
Imagine if a new VC firm swoops in and takes up 2 of those 15 each year. Make sure you're invested in a VC firm that's on the right side of Darwin. And as of the Da VC code, I think I know the next couple code ciphers to find the Holy Grail of 15...

Disclosure: no positions

Wednesday, July 8, 2009

kaChing: the sound of money flowing away from mutual funds

This year's Finovate Startup 09 Conference in San Francisco hosted some 56 financial oriented startups. Attending as a blogger from Seeking Alpha (a conference sponsor) and a serial startup guy, it's hard to beat merging the best of two worlds. If you didn't have a chance to attend, a great way to summarize the big picture painted by Finovate Startup '09 was encapsulated by a remark from a fellow Seeking Alpha blogger and hedge fund manager; there are no areas of finance left which will not be heavily disrupted. Some of these startups represent such disruptions to current financial business models. If you're in the biz, I heavily recommend attending the flagship Finovate in NYC on September 29, 2009. Your life is about to change.

My runner-up favorite theme at Finovate was peer-to-peer lending. This has a lot of potential in that it creates a new asset class which takes banks out of the equation, allowing (pools of) borrowers to directly borrow from (pools of) lenders. And as a general rule, startups in this space tend to tout more transparency to the process. There was a great wrap-up of related startups here. If I were a bank, I'd think about buying into these startups early. And note that transparency is the new trend.

But the one startup that stood out from the pack, and stopped me dead in my tracks as an entrepreneur was kaChing. If I had to describe kaChing in one phrase, I'd say "look out mutual funds!" Here's how it works. Portfolio managers make investment decisions on the kaChing site, and will also be able to import past decisions from previous trading activities to establish more history (assuming it's good!). They also declare their investment strategy, perform research, and blog. To extents, these kinds of things have been done by various services/sites. But here's where kaChing's magic begins. One of the most prevalent (and toughest to solve) problems of such a service is to assign ratings to portfolio managers which have real meaning. Basing ratings purely on returns can be a very poor way of assigning a metric, as returns can change quickly and don't reflect important facets of investing such as risk taken or consistency with a strategy. By contrast, kaChing believes they have "broken the code", creating a meaningful rating system called Investing IQ, which ranks managers by the same criteria that premier endowments look for:
  1. Great risk-adjusted returns
  2. Compelling investment rationale
  3. Adherence to a stated strategy
This of course is not easy to do on any scale. But it's absolutely essential, if you want to provide a service which retail investors can bank on. But then comes the brilliant part of kaChing's story -- one won't have to passively follow a portfolio manager; instead, in September you will be able to actively and automatically mirror their trades in real brokerage accounts!!! And portfolio managers will earn fees from followers, as in any real fund scenario. But to earn money as a manager, and to protect mirroring investors, managers have to earn a score above 70, which turns out to be very hard to do. Click on "Find Managers" on the kaChing site to see how few make the cut so far. Fwiw, kaChing thinks not too many mutual funds would make the cut either, but it's hard to tell due to lack of transparency.

I can see a whole new order of portfolio managers being created. If you're consistently good, you can live and manage from wherever you want. And the more prolific you are in your research and interactions with your followers (blogging, answering questions, etc), the more followers you can aquire ("the twitter effect"), which in turn scales your income nicely for the same amount of work! This is also a great venue for promising finance students and investment clubs to cut your teeth and show what you're made of -- get benchmarked with Investing IQ against the brightest. Ultimately, putting an Investing IQ on your resume may be cover-charge, like taking a GMAT is for entering an MBA program. What I'd like to see is a time when talking heads in the media have to disclose their Investing IQ -- what a great way to sort out hot air.

Going mobile? kaChing's iPhone app is now available for free. You can get real-time quotes for US exchange listed equities/ETFs, check out your account, get top-rated research, look for investing ideas, etc. I recommend checking out the "Investing Ideas" screen. You can see investment ideas where the smart money differs from the rest of the pack. Want another idea, just shake the iPhone. This alone is worth using kaChing.

To stay tuned for the trade mirroring feature coming in September, send an email to ''. This is the company to watch. And it's worth noting, kaChing is a SEC Registered Investment Advisor.

Disclosure: no positions

Tuesday, June 9, 2009

Airbus looking at descent until it adds pilot override

I think we'll see accelerating cancellations of Airbus orders. It will have little to do with whether Airbus can identify and correct sensor and/or other problems with Air France Flight 447, which went down a week ago while en route from Rio de Janeiro to Paris. Rather, I believe it will be because the Flight 447 crash will make the public aware of something that must be very unsettling to pilots -- Airbus has a design philosophy of using computer fly-by-wire, without the ability of pilots to override! Of course, Boeing jets also operate with fly-by-wire, but at least pilots' inputs can override the computer.

I don't know if this design philosophy truly reflects a difference between American and European cultures. But I would say, to the public, this is not a story about culture or mechanical sensors. It's a story about whether the pilots in the cabin have a fighting chance to bring you back alive, if something goes very wrong. That is an epic human story, of which I would not want to be on the wrong marketing side. If I were an airline, I would have already cancelled any Airbus orders possible. That's exactly what I expect to see happen.

Note to Orbitz et al. Offer an extra search option to select for aircraft with pilot override. It would be a great differentiator.

Disclosure: no positions

Sunday, May 10, 2009

Hadoop should target C++/LLVM, not Java (because of watts)

Over the years, there have been many contentious arguments about the performance of C++ versus Java. Oddly, every one I found addressed only one kind of performance (work/time). I can't find any benchmarking of something at least as important in today's massive-scale-computing environments, work/watt. A dirty little secret about JIT technologies like Java, is that they throw a lot more CPU resources at the problem, trying to get up to par with native C++ code. JITs use more memory, and periodically run background optimizer tasks. These overheads are somewhat offset in work/time performance, by extra optimizations which can be performed with more dynamic information. But it results in a hungrier appetite for watts. Another dirty little secret about Java vs C++ benchmarks is that they compare single-workloads. Try running 100 VMs, each with a Java and C++ benchmark in it and Java's hungrier appetite for resources (MHz, cache, RAM) will show. But of course, Java folks don't mention that.

But let's say for the sake of (non-)argument, that Java can achieve a 1:1 work/time performance relative to C++, for a single program. If Java consumes 15% more power doing it, does it matter on a PC? Most people don't dare. Does it matter for small-scale server environments? Maybe not. Does it matter when you deploy Hadoop on a 10,000 node cluster, and the holistic inefficiency (multiple things running concurrently) goes to 30%? Ask the people who sign the checks for the power bill. Unfortunately, inefficiency scales really well.

Btw, Google's MapReduce framework is C++ based. So isn't Hypertable, the clone of Google's Bigtable distributed data storage system. The rationale for choosing C++ for Hypertable is explained here. I realize that Java's appeal is the write-once, run anywhere philosophy as well as all the class libraries that come with it. But there's another way to get at portability. And that's to compile from C/C++/Python/etc to LLVM intermediate representation, which can then be optimized for whatever platform comprises each node in the cluster. A bonus in using LLVM as the representation to distribute to nodes, is that OpenCL can also be compiled to LLVM. This retains a nice GPGPU abstraction across heterogeneous nodes (including those including GPGPU-like processing capabilities), without the Java overhead.

Now I don't have a problem with Java being one of the workloads that can be run on each Hadoop node (even script languages have their time and place). But I believe Hadoop's Java infrastructure will prove to be a competitive disadvantage, and will provoke a mass amount of wasted watts. "Write once, waste everywhere..." In the way that Intel tends to retain a process advantage over other CPU vendors, I believe Google will retain a power advantage over others with their MapReduce (and well, their servers are well-tuned too).

Disclosure: no positions

Friday, May 8, 2009

50% of Cloud Compute Power & Carbon Waste Solved by Software Technique

Ever wonder why virtualized servers are usually run at nominal loads of 30..40%? It's because the speed at which VMs can be live migrated is much slower than the speed at which load spikes can arise. Thus, a large "head room" is built into the target loads at which IT is generally comfortable running their virtualized servers.

Faster networking would seem to save the day, but per-server VM density is increasing exponentially, along with the size of VMs (see latest VMworld talks). Thus there are many more (increasingly bigger) VMs to migrate, when load spikes occur.

Besides the drastic under-utilization of capital equipment, it's a shame that the load "head room" is actually in the most efficient sweet spot of the curve. The first VMs tasked on a server are the most power-costly, and the last ones are nearly free (except we only use that band for spike management).

If loads could comfortably be advanced from 40 to 80%, half (or more) of the compute-oriented wasted power consumption, resultant carbon footprint, and excess capital equipment could be saved. And that's exactly what my R&D showed can be done, with a software-only solution. And as an added value, the same technique accelerates VM migrations across data centers, which is where cloud computing is going.

Essentially, we're blowing an extraordinary amount of money and trashing the Atmosphere from out-moded virtualization software. None of the virtualization solutions from VMware, Citrix, or KVM have this new technique yet. And it's not available via Amazon's EC2. Here's to hoping the future is greener. As well, a high-end networking infrastructure throughout will be essential. Time is money, and time to migrate VMs translates to a lot of money! For the next cloud computing decade, "networking is power". Consider getting long cloud providers and virtualization vendors that support accelerated VM migration, and networking vendors that supply the goods. It nearly goes without mention that Cisco has entered the server market...

Please help spread the word, and feel free to bug your providers.

Disclosure: no positions, related patents pending

Thursday, April 23, 2009

Boosting server utilization 100% by accelerated VM migration (MemoryMotion™)

Recently I guest-wrote an article on about a technology I've been researching for some time, called MemoryMotion™. By providing a distributed memory disambiguation fabric, VM live migration time is greatly accelerated. Besides the obvious benefits, ultra-quick migration unlocks a healthy chunk of additional server utilization, currently inaccessible due to slow migration times in current hypervisors.

It's worth stepping back a moment and asking the question, "why can we only run a physical server at say a nominal 40% (non-VDI) / 60% (VDI) maximum load?" Based on intuition, one might answer that it's due to workload spikes, which cause us to provision conservatively enough as to absorb spikes to an extent (the micro level), and fall back to distributed scheduling across servers to balance out at the macro level. But that's really how we deal with the problem, rather than an identification of the problem. The truth is that a good chunk of the 40% of nominal under-utilization comes from the slowness of live VM migration. It's easy to demonstrate this with a question. What could the nominal maximum load factor be, if we had infinitely fast VM migrations (0.0 seconds)? Probably 90%+ or so. Statistically, there are likely to be physical servers that are under-utilized at any one time. If we can quickly move VMs to those servers, we can adapt more quickly to load spikes, and thus achieve higher holistic utilization rates. The more servers one has, the more this is true.

Now, if we're using distributed VM scheduling for the purpose of power management, we want to pack as many VMs on as few powered-on physical servers as possible. In that case, we often have powered-off servers, which can be spun up quickly. And thus, we have even more head-room available. With infinitely fast migration and server power-ups, one could push physical server utilization near 100%, without losing quality of service. There's not much reason not to. This would yield a huge gain in power efficiency (and thus power costs).

The article highlights MemoryMotion™, a technology which by way of providing much faster VM migrations, provides a mechanism to greatly boost server utilization. Using high speed network fabrics, we can finally look at distributed VM scheduling like an Operating System scheduler, because the scheduling time-frame decreases down to the sub-1-second range. This is how we can tap the next 100%(relative) of ROI/power-consumption improvements, as highlighted in the following slide.

As far as I'm aware of, this could be the next killer virtualization feature, since the advent of live VM migration. Feel free to contact me if you'd like to know more. Note that it is patent pending technology.

Disclosure: no positions

Tuesday, April 14, 2009

Inflows and outflows of US cities using a U-Haul barometer

Expanding on the U-Haul metric idea in the article "Fleeing Silicon Valley", I gathered costs of moving a household via U-Haul throughout a matrix of cities in the US. The thesis is that moving truck rentals will fairly accurately reflect the supply/demand equation, likely on a near real-time basis, giving us a current indicator of where the inflows and outflows are. This is interesting for a whole host of investment (and personal) themes, such as which direction commercial and residential real estate values will trend in various areas.

I picked 10 cities, which represent top startup locations in the US (a personal bias). To net out differences in travel distance, and to normalize values so that one can quickly compare and see trends, I gathered data for one-way moves in both directions between every one of 10 cities, and then divided the price of source-to-destination by the price of destination-to-source. What remains are ratios which show which way people are likely moving. The results are very enlightening.

The winners (highest in-flows 1st): Austin, Raleigh, Boulder, DC, Seattle.

The losers (highest out-flows 1st): LA, Silicon Valley, NY, San Diego.

Worth noting, Boston was nearly net-neutral, but it's interesting where it's picking up people from in droves (Silicon Valley, LA and San Diego). Most cities are poaching from California. This can't be a good thing for California's urban real estate markets, municipal bond ratings, nor for its state income tax receipts -- right at a time when revenues are falling short of projections.

Disclosure: no positions

Thursday, April 9, 2009

Portable Linux future using LLVM

Imagine a single Linux distribution that adapts to whatever hardware you run it on. When run on an Atom netbook, all the software shapes and optimizes to the feature set and processor characteristics of the specific version of Atom. Want to run it as a VM on a new Nehalem-based server? No problem, it re-shapes to fit the Nehalem (Core i7) architecture. And here, when I say "re-shape", I don't mean at the GUI level. Rather, I mean the software is effectively re-targeted for your processor's architecture, like it had been re-compiled.

Today, Linux vendors tend to make choices about which one or set of processor generations (and thus features) are targeted during compile-time, for the variety of apps included in the distro. This forces some least-common-denominator decisions, based on processor and compiler features, as known at the time of creation of a given distro version. In other words, decisions are made for you by the Linux distributor, and you're stuck with that. When you run a distro on new hardware, you may well not be able to access new features in the hardware you purchased. Or, a distro targeted for advanced hardware may not run on your older hardware. Such is the current state of affairs (or disarray as I like to think of it).

Enter LLVM, a compiler infrastructure which allows for compilation of programs to an intermediate representation (IR; think Java byte codes), optimizations during many phases (compile, link and run-times), and ultimately the transformation of IR to native machine code for your platform. I see the IR enabling powerful opportunities beyond the current usage -- one opportunity being, distributing Linux apps and libraries in IR format, rather than in machine code. And then having the infrastructure (including back-ends specific to your platform to transform the IR to native machine code), and potentially caching this translation for optimization's sake. The obvious benefit here is to enable much more adaptable/portable apps. But it also orthogonalizes compiler issues, such as which optimizations are used (and the stability of those optimizations), such that those can be updated in the back-end without touching the apps in IR form. Modularization is a good thing.

A resulting question is, how low-level could we push this in terms of software? At a LLVM talk I attended, there was mention that some folks played with compiling the Linux kernel using LLVM. I'd like to see that become a concerted effort from the processor vendors, as it would allow Linux to become more adaptive, perhaps more efficient, and show off features of new processors without having to adapt all the software. I have many related ideas on how to make this work out.

Especially given the trend towards some exciting convergence between CPU and GPU-like processing, and many available cores/threads, I think it's time we take a hard look at keeping distributed code in an IR-like form, and orthogonalizing the optimizations and conversion to native code. In a lot of ways, this will allow the processor vendors to innovate more rapidly without breaking existing code, while exposing the benefits of the innovations more rapidly without necessitating code updates.

Disclosure: no positions

Thursday, March 19, 2009

Microsoft + Facebook + netbook = World domination (again)!

I'd imagine Microsoft is still stinging, years after letting the Google opportunity slip through their fingers. That's always an unfortunate possibility for companies who adopt the wait-and-follow approach to innovation. Although Microsoft did switch gears significantly and invested in Facebook in October 2007 before it ran away too. Based on the deal terms (a 1.6% stake of $240 million), it would appear there was more value to Microsoft than just the equity position. But I've come up with a strategy for Microsoft to get ahead of the curve this time, one that could return it to it's World domination position.

It's no secret that Facebook's growth is stellar, projected Worldwide at 5 million new users every week! Facebook is in some ways becoming to social networking what Google is to search. And that is what makes a phenomenal opportunity to Microsoft if they get ahead of this one. Less than 25% of the World's population are Internet users. For many of those users, Microsoft could service using their current roadmap. But what about the remaining 75%? Several trends taken together, paint a pretty clear picture of how to capitalize on this massive wave of Internet newbies.

The first trend is towards ultra-cheap netbook like devices. The more inexpensive they are, the more appealing it is to subsidize them with service oriented revenues, thus accelerating their availability. A related and second trend is a move towards pushing applications and data to the cloud. Microsoft has already jumped on this bandwagon to extents, both with lightweight browser-based versions of Office apps, and with its Azure platform. And a third trend is that to many users, social networking is becoming a central 'platform' of its own.

Putting all of this together, my idea for Microsoft is to 1) buy Facebook right now, 2) get extremely aggressive about producing (through ODMs of course) the most insanely cheap netbook-like device imaginable, 3) market these devices to emerging markets with high Internet adoption potential (they're not displacing existing business anyways), and 4) grow the next billions of users on the platform.

If you look at Google's Android platform and its potential to be put on ultra-cheap devices (like say a netbook sized tablet-shaped device with only a soft-keyboard), the above may sound very similar. But there's something importantly different about what I'm proposing. The Android strategy seems to be riding the commoditization curve downward, penetrating new markets as the technology improves and more importantly as the cost to manufacture decreases. In a previous blog, I proposed a way to get in front of this, and produce an extremely inexpensive device that would serve the low expectations market which includes those who are starting at zero. As those users and their related economies grow, they could then purchase more capable devices, and at the same time, economies of scale would keep even those new purchase prices low. So in essence, I'm proposing the opposite trajectory as Android, i.e., start with masses of people who are just barely able to get connected, and work backwards to reach people who are farther along over time.

Microsoft has the resources to put a big push behind technologies, such as higher-refresh no-power screens, like those on e-book readers. Those would be a huge help in reducing battery requirements, and thus reducing production costs. Every such reduction accelerates the feasibility of a subsidized model, which ultimately means devices could be given out en masse, in order to grow the next billions of users who provide service revenue and user base. Why play catch up in established search, when you can own new search, LBS, social networking, software as a service, e-book sales, media sales, etc? Ultimately, service revenue is where it's all going. Why not prove it out in non-competitive markets? Make Facebook the first experience users ever learn. It's obviously sticky. That could be a huge advantage to Microsoft.

Forget $100 netbooks. Make $25 devices and subsidize them to $0. If the device doesn't do its own processing, a lot of components can be scrapped. At any rate, school systems would be a great place to seed these devices...

Disclosure: no positions

Virtualization / cloud M&A opportunities

We've entered the phase where M&A of technology companies gets interesting. Oddly, while the economics are less than stellar, and cut backs and lay-offs run rampant, a number of major companies sit on mountains of cash. Recent M&A activities and rumors thereof, will knee-jerk companies into the buying frenzy that accompanies this phase. But beyond that, there is a new trend of Unified Computing, written indelibly in ink by the recent Cisco move into the server market. This will focus the M&A urgency on a few specific areas, and light up the war rooms at many corporate headquarters. So I'm offering some related ideas.


In the open source dimension I see a big future for Linux+KVM. Factoring in trends towards cloud computing, a bad economy putting a push behind Open Source, and a huge ecosystem surrounding Linux, Linux makes sense as the hypervisor. And as it so happens, the company behind the KVM hypervisor (Qumranet) is now owned by Red Hat, who has a focus on the Linux server business -- the same Red Hat who reported a 20% jump in earnings last quarter.

For those hiding under a news rock for the last week, Cisco's entry into the Unified Computing market means that to stay strong, players need to have an all-in-one solution. This reminds me greatly of the trend in the processor world, where to compete, players needed to pull in chipset and graphics logic to survive. So, for anyone who wants to be a big player in the cloud computing market, you'll need a strong virtualization and Linux and networking component. Buy Red Hat -- it'll cost you more than the USD 3 Billion market cap to not own it. You might also read my friend Tarry Singh's posting; he believes Oracle should snap up Red Hat.

Desktop virtualization isn't yet as pervasive as server virtualization. But it's a very interesting technology, and when implemented properly solves a lot of truly important problems: offering multiple OS personalities (one personal, one corporate), operating off-line or on-line, allowing remote unified image management, backup management, etc. We can really break this category down to two major bins, the hypervisor and everything else. The most interesting thing here is the everything else bin, because that's the logic that can potentially operate across a multitude of hypervisors. As far as promising companies here, the most interesting is Virtual Computer. Currently, they use Xen as the hypervisor, but their strength is really the everything else bin. My recommendation for big players who count corporate notebooks and desktops into their future, is to buy Virtual Computer now. So far, they are the most innovative private company in the space. Adding a team to extend it across Hyper-V and Linux+KVM environments would be a good follow-up idea.


In short, everything about cloud computing means more networking -- moving forward, computing is a dynamic fabric overlaying a multitude of physical sites. As soon as we start talking about dynamic and multi-site, many continuity problems arise which require more sophisticated techniques, with underlying networking. Storage becomes very much a networking issue, for example. If you want to see where multi-site memory optimizations (which enable cloud-wide long-distance VM migration and memory de-duplication) are going, check out a recent post of mine. These optimizations are new consumers of networking, and that will only increase. Networking continuity itself is a problem -- how do you maintain open TCP connections when migrating workloads to different physical sites?

To have a future selling solutions into tomorrow's data center, having a strong networking component is essential -- more so than ever before. Of course, some players will be forced to partner to get this. But Cisco's entry into the server market with their Unified Computing System, ought to send a smoke signal to the big players that they better get busy fast.

Rather than make recommendations here, I'll defer to some possibilities outlined in this article and this article (e.g. F5 and Brocade). My aim here is more to point out that networking is absolutely essential to the future of cloud computing. And I really don't separate virtualization out from cloud computing -- it's really and essential part of it. As well, I would think there'll be at least jockeying to partner or get busy with Juniper. A lesson learned from the processor and chipset market is that it doesn't pay fighting convergence. And convergence is exactly what is occurring. You need to offer it all-in-one, packaged neatly for the customer. IMO, M&A and deep partnership will have to occur soon.

Disclosure: no positions

Friday, March 13, 2009

Virtualization 3.0: Cloud-wide VM migration and memory de-duplication

For those unfamiliar with my background, I authored a full x86 PC emulation project in the 1990's, called bochs. It was used in one form or another, by a number of virtualization players, including an R&D project at Stanford which became VMware. It's been interesting watching x86 virtualization mature, from the early days of it being used as a developer's tool and then on to server consolidation (what I call virtualization 1.0). Consolidation is an interesting proposition of its own, making use of the VM level of abstraction to pack more work onto less physical resources. But it's still a very static technology in that VMs need to be booted and shut-down to be moved to different hardware.

When VM migration came onto the scene, it unlocked a wealth of additional value of virtualization, and a set of higher-level technologies. In VMware terminology, DRS tapped VM migration to do load balancing within a cluster of machines. DPM uses migration to pack VMs into lesser number of machines, de-powering ones not needed, thus doing cluster-wide power management. I call this whole suite of dynamic VM technologies, virtualization 2.0. Unfortunately, these dynamic features have generally been confined to within a physical site location, or at best within a Campus Area Network.

To get to where virtualization needs to go, we need to be able to look at virtualization as a fabric, stretching or overlaying numerous physical sites. And Cloud Computing will absolutely exacerbate this need. Many things that we've contemplated on a small scale (e.g. load balancing, power management, down-time maintenance), need to be brought to a larger context of a virtualization fabric stretching across physical sites. Virtualization needs to stretch to the cloud. To be sure, there are a number of issues to solve to make this happen, including networking and storage continuity. But I'd like to present a part of this next evolutionary step, virtualization 3.0, which is critical to its success yet unanswered elsewhere to my knowledge.

Memory density in servers continues to go up following its own exponential path. And as virtualization is used for increasingly higher-end workloads, the size of per-VM memory will continue to rise. Just imagine if you piled up all the RAM from all of your data centers, in one spot! Yet, to enable a fluid and dynamic virtualization 3.0 fabric, we need to rapidly allow all kinds of intra and inter-site VM migrations to occur, often driven automatically. That requires a whole new approach to how we manage VM memory; huge volumes of it effectively need to be transported rapidly. On the storage front, there are a number of technologies afoot, which are enablers of virtualization 3.0. But, I've been working for some time on concepts for making VM memory a 1st class citizen of the virtualization 3.0 vision.

We know from various benchmarks that there is a significant amount of redundant memory state across VMs. Within a server, VMware will consolidate some redundancy, on the order of up to 30%. Research which uses a sub-page granularity for reducing redundancy brings that up to 65%. Further research, using a differencing engine, ups this to a phenomenal 90% with similar apps and operating systems, and 65% even across VMs running disparate workloads!

Knowing all of this, what could we do if we managed memory with virtualization 3.0 in mind? In short, we can enable faster and more long distance VM migrations, cross-site load balancing and power management, de-duplicate memory thoughout multiple sites, and even WAN accelerate VM memory! Not only can we make the virtualization fabric quicker, more responsive, and encompass a much large geography, but we can actually increase VM density (and/or decrease physical RAM requirements), thus become more capital efficient and reduce overall power consumption. What's fortunate, is that the buzz around "long distance VMotion" (VMotion is VMware-speak) has finally picked up, starting at the latest VMworld. As storage, networking, and other hurdles are overcome, there is a vast amount of optimization opportunities at the VM memory level.

I put together this PowerPoint presentation to highlight these points. Feel free to pass it along. Note that this is Patent Pending technology. Give me a shout if you'd like to talk more.

Disclosure: no positions, author has related Patent Pending technology

Sunday, March 1, 2009

A netbook concept for the next billion people

Despite the current economics, netbook sales have been growing at double-digit rates. It's one of the few hot spots in the consumer computing space. There are now over 50 vendors with an offering across EMEA! What's really interesting is the shift towards the importance of the telco channel in accelerating netbooks sales. The decreasing price point of netbooks, while not necessarily exciting the hardware manufacturers, is enabling new ecosystems, use-cases, and facilitating a value-system shift from the hardware to the newly enabled ecosystems. In Europe, for example, this shift has been towards wireless data service providers, in much the same way that inexpensive handsets enabled wireless voice services. But there are many other exciting possibilities in after-market sales, with decreasingly expensive devices. According to IDC, "mini-notebooks will continue to shake the industry from both a go-to-market and a pricing perspective".

Sales prices (not factoring in subsidies) don't necessarily have to follow a smooth and continuous curve. Sometimes there are significant changes which drive big step function price decreases. I'm presenting one such change, which I believe would change the pricing point enough to drastically accelerate adoption and enable new after-market value systems to emerge, especially in developing nations. In short, I believe this change would help enable the next billion people to get connected. It's worth pointing out, when those people come online, they're not necessarily starting with the same expectations, given they're starting from nothing or very little. So the form factor for the next billion doesn't have to obey the same rules as the first billion. Sometimes we need to think differently, to see where the change will come from.

So how do we make an extremely high-volume, high-competition device like a netbook, even less expensive? Well, how about the following idea.

Why do the smarts of the netbook need to be an attached part of the netbook form-factor? Imagine if we split a netbook into two, one display unit that essentially had the functionality of a Celio Redfly (smartphone companion) device, and another smarts unit with a CPU, memory, network port, storage and wall power plug (which ideally would fold in when not in use). Let's assume the display (and keyboard) unit is driven by an inexpensive integrated SoC solution; no RAM, disk, or additional intelligence is needed. It would have integrated WiFi, to speak with the smarts unit. To have something concrete in mind, let's say the smarts unit looked something like the Marvell SheevaPlug, or other product of their Plug Computing initiative. The two units could communicate via WiFi, or perhaps a USB port (also good for re-charging batteries). Potentially, these two units could snap together like Legos, to form something on the order of a conventional netbook or tablet. If one got creative, the USB port could even be used as the data and power connection to keep the BOM costs low. But they don't need to physically attach to keep the design simple.

This arrangement would at first blush seem to increase the Bill of Materials (BOM) cost. But that's assuming everyone needs the smarts unit, which they don't! A home or work PC can function as the smarts, as can a laptop or an educational server, or a smartphone. Anything programmable with even humble computing capabilities and wireless communications can act as the brains. Additionally, there's no reason why one smarts unit can't support multiple displays (essentially a terminal server), which means one smarts unit could potentially support a household or small class-room, when needed at all.

Having less hardware in the display also requires less battery costs and weight, which allows it to be manufactured less expensively. Effectively, we've lifted out redundant costs and power consumption, and put them in a separate unit which can be shared or is not needed. Perhaps as e-ink solutions come down (helped along by the Amazon Kindle), power consumption could become even lower, further reducing the battery input costs.

I mentioned enablement of after-market value systems. Thus far, wireless data services has been one such case. But what else could we do with extremely inexpensive netbook-like devices? To be sure, enabling the next billion people opens up significant educational opportunities -- a whole ecosystems of its own. But what about electronic books in general? By definition, there's an entirely untapped market for low cost versions of books in electronic form, because those people don't have devices yet. We have the concept of low-cost drugs for developing countries, why not e-books? Or, what about social networking? Could an extremely inexpensive device be branded by Facebook? Why not be the first thing people learn to use when they enter the connected world? Or how about a Google branded device? Maybe an Android companion would be interesting. There are just so many opportunities here. The question in my mind, is who will do this first?

Disclosure: no positions

Saturday, February 21, 2009

Future of Linux desktop: co-Linux on Android

We're at the native Linux desktop, moving towards the Android desktop (netbooks coming soon). What would bridge those two environments, is to offer a second Linux sandbox which runs along with Android.

Android has a very specific architecture, with its own libraries and non-X based GUI, which are not conducive to running standard Linux/X applications. Even it's libc version (bionic) omits certain POSIX features, making it not fully compatible. Android apps have to be targeted for and compiled against Android.

To allow native Linux apps to run, a second sandbox environment is needed, which can co-operate with Android. Android would be the master environment, providing all of the kernel, hardware drivers, and complete software stack that it already does. The co-Linux environment would provide a separate set of non-kernel components: libraries, configuration and administrative files, applications, etc. As Android drives the hardware, the co-Linux environment would need to defer to Android for some facilities. For example, X apps running under the co-Linux would need to speak with a special X server running on Android. The audio system on the co-Linux would likewise need to redirect to Android's audio manager. But the co-Linux environment would not need any boot-path files (Android takes care of booting), nor its own kernel.

Using a chroot sandbox is nothing new; it's used by Linux build environments such as the Moblin image creator, and to create a nice clean 32-bit environment on a 64-bit Linux box (even for X apps). Doing some porting work, would take the same concept to an Android environment. Perhaps further work could make the two environments more seamless to the user (UI, disk files, installation, etc.).

Note that another way to come at this, is to put the co-Linux environment in a VM, but there are downsides. First is that running a second kernel and VM in general adds more power consumption, burns more CPU cycles and consumes more memory; not a good thing for a constrained mobile device. And second, current Intel Atom netbook processors do not support virtualization.

I would think a co-Linux would be a boon for coming netbook platforms, where some users may want to chose from the available native Linux apps, including educational, gaming, just plain familiar, or otherwise. It would be really cool if the co-Linux environment itself could be bundled as an Android app. In any case, bundling key native Linux apps as Android apps, would be a fantastic way to piggy-back on the Android Market and ecosystem, without building out any new infrastructure. This would also enable one to focus on delivering only those apps that add significant value, and not spend time duplicating technical efforts with Android. In fact, I believe this could be the future of the Linux desktop distro, until the time when all apps are available on the cloud. And what a perfect use-case for portable Linux packages using Zero Install, which removes vendor specific head-aches and is appropriate for application level packages. Disruptive play for a new age desktop Linux company?

Disclosure: no positions

Monday, February 16, 2009

Linux winners will be deal-makers with Microsoft

We have just entered a new era in interoperability between Linux and Windows.

The Desktop

A week ago, Google announced that they licensed Microsoft's Exchange ActiveSync protocol technology, and released a beta of the Google Sync service. Google Sync is a new push technology that allows over-the-air sync of Google calendar appointments and email contacts, across a number of handset environments including Windows Mobile devices. This was a wise move and one with a desktop component best described in a related quote I found:
"... a solid step in Google's march toward owning the desktop."
If Linux wins ground on the desktop, it won't be because the Bell Curve of users cares it's Linux -- it'll be because the desktop gives users what they want. Easy synchronization is essential. At the same time, I believe this was smart of Microsoft. Android and Google services are gaining traction, and at some point Microsoft has to capitalize on the areas it has value, rather than trying to own the entire space. What'll be interesting to watch is whether Google Sync will be supported by Ubuntu, Moblin, and other Linux platforms.

The Server

Today's news was the clincher on the server side; Red Hat and Microsoft agreed to validate each other's operating system on their respective virtualization hypervisor technology. Once validated by both parties, customers with valid support agreements will receive cooperative technical support. What was really impressive is that Red Hat pulled this off without patent or financial clauses. I believe this deal was inked, simply put, because customers demanded it. It also shows Red Hat has some serious pull, not surprising given their beat-the-street quarter and posture to gain some new ground as a result of poor economic times.

Winners and Losers

The market has spoken; it wants choice, interoperability and support. Enough players with clout have signed on. Although, this creates a whole new dynamic for other players in the Linux vendor space. Vendors who have not struck such deals are at a disadvantage until they do. If they aren't able to make the deals, they risk getting boxed out, or at least getting relegated to the fraction of the market formed by pure Linux shops.

Disclosure: no positions

Thursday, February 5, 2009

Canonical half as revenue efficient as Red Hat, per person

Canonical is the company behind Ubuntu Linux.

Recently, Canonical's CEO gave some indications of their annual revenue (about $30 million/year). As Canonical is a private company, there hasn't otherwise been a lot of financial information forthcoming. However, it's estimated that Canonical has 200+ employees.

This makes for an interesting opportunity to compare revenue efficiency on a per-employee basis with Red Hat (RHT), a competing public Linux company. Red Hat has approximately 2200 employees and its estimated 2009 revenue is 653.65 million dollars. I love this as a first order comparison between direct competitors to see how efficiently companies generate revenue.

That would put Red Hat at ~300K dollars per employee and Canonical at ~150K dollars per employee, or only half. To add some perspective, Microsoft rakes in ~676K dollars per employee. To be fair, Canonical is a younger company, and has likely made investments that will need time to play out on the revenue front. What I can say is that at the bottom end of the Linux commercial spectrum, a trend is that some customers tend to opt for supporting themselves with their own IT departments. I wonder sometimes if Red Hat loses more on the bottom end to CentOS than Canonical earns, due to this trend.

As Android ramps into the netbook space and beyond, I think it'll grab more Linux desktop market share. A co-Linux strategy might be a good thing for Linux desktop vendors, providing the native Linux apps that Android doesn't have. But it's not clear to me what course Canonical has set, with Android invading the desktop, and their server business being lower on the totem pole than Red Hat's. Canonical will have to scale much bigger to capture any real share of the server business.

Fwiw, I use Ubuntu (and others) myself, and worked for a Linux distro before. It's a tough gig. But I like the community element of Ubuntu; it's a philanthropic success in any case.

Disclosure: no positions

Tuesday, January 27, 2009

Cloud storage in, consumer HDDs out

There are a lot of rumblings of recent about a possible Google Web Drive offering. Of course, Microsoft has its cloud storage counterpart SkyDrive, and there are a whole panoply of companies with existing offerings with a bias from online file sharing to storage to backups. Just to name a few, there is, IBackup, Mozy, Iron Mountain’s Connected Backup for PC, and many others.

For consumers, online storage is a lot about convenience -- one of the key values which consumers will pay for, and in this case quite possibly on a reoccurring basis. There's the convenience to access files from anywhere. And to share files with others groups or even with the public. And to have someone else deal with back-ups. Forget buying a NAS box for backups -- backup to a service. What enables this trend to occur is simply network bandwidth availability. It certainly wouldn't have been feasible with a modem dial-up ISP.

It's worth thinking about other trends to which cloud storage is very complimentary. Netbooks for example, are targeted for mostly online activities, and as such are well suited for use of cloud storage for user files such as photos, videos, songs, etc. If a lot of storage needs of user files can be pushed to the cloud, then the requirements of netbook local storage goes down or doesn't need to grow as rapidly (end of the Moore's law of consumer storage). That shifts the suitability curve of flash memory storage products (like SSDs), accelerating its adoption in netbooks. The same can be said for any PC platform, for that matter. Which would mean that HDD storage growth will shift from consumer products to the server dimension, where it's utilized by cloud storage providers.

What will be interesting to watch play out, is how each cloud storage vendor handles security. For private storage, consumers will want an option to secure their files with no less exposure than they have with a local drive. And at the same time, if smart-caching of well-used files is done well (even across boot-ups), we'll have a very functional cloud storage model with relatively few trade-offs.

Disclosure: no positions