What Clouds Will Form Around Data's Gravity?

The concept of Data Gravity posits that as data accumulates (whether it be stored, analyzed, used) it tends to attract even more similar data. And as the data amasses there is less likelihood that it will be moved/migrated elsewhere.  If you're not already familiar with the concept definitely check out Dave McCrory's excellent blogs, analyses and presentations on datagravity.org

I believe this data aggregation concept can also apply to attracting computing too. As I've mentioned in It will be a data-centric (cloudy) world, there are examples today where special-purpose compute clouds are already forming around special-use data sets... sometimes intentionally, sometimes organically. One example I frequently point out is the NYSE Capital Markets Community Platform - a special-purpose cloud computing environment formed with a massive market trading data set at its core.

I am increasingly asked by service providers and enterprises alike, what other businesses and special-purpose clouds might form around data?  What new clouds (and associated business models) might we build and monetize? How can we better serve vertical market needs in the Cloud?

Forming Community Clouds - Applied (vs. Theoretical) Data Gravitational Theory

After more thinking and conversations with experts on the topic, I wanted to offer some examples and ideas that I hope trigger further exploration by cloud- and service providers. Perhaps there are (or will be) new businesses based on some of these ideas of attracting data and computing.

Financial Services Community Cloud: as I've mentioned, the NYSE CMCP has at its core a huge database of stock market history.  It's natural attractor for trading firms and hedge funds to co-locate their compute loads near this data as they test and refine trading algorithms and prediction methods. High-performance processors with low-latency connections to Wall Street don't hurt the model either.  Perhaps there are other forms of gravitational financial data (other markets?) that could attract similar compute clouds?

Photography/Imagery Community Cloud: More and more companies (Shutterfly, SmugMug, EverPic stock photography companies etc.) are in the business of warehousing photos - mostly for simple monetization. But some innovative photo data collections might take advantage of this and provide a co-located compute platform for ISVs to provide higher-level photo identification, cataloging, enhancement and even geo-tagging services.  Perhaps the compute services could take advantage of knowledge about the larger database of images that have been previously tagged or otherwise cataloged within the larger community.  [Bonus thought experiment: create a shared medical imagery cloud].

CRM and Customer Insight Community Cloud: Consider the amount of customer data located on Salesforce.com and others. Now consider the amount of consumer behavior information collected by systems like Marketto and others.  What if one of these giants begins to acquire additional firms who house complementary marketing data - and begins to build valuable "big data" around customer behavior?  Much like force.com, the customer data would attract even more marketing and consumer behavior application workloads, again attracting more data and workloads.

The Retail Community Cloud: Start watching what Walmart Labs and Nielson are doing in the Big Data and retail analytics space.  It would be but a small jump for either to create a retail cloud - centered around a huge (but perhaps anonymized) database of consumer purchasing patterns, geographies, pricing and outlets. Monetize it by allowing co-location of marketing analytics workloads from marketing firms seeking insights into better forms of micro-marketing, associative/recommendation sales, and other forms of retail analytics engines. All retail firms great-and-small would want a piece of that action.

The Energy Community Cloud: What would it be worth to amass data about energy consumption -- at the customer level -- across the country? Perhaps associate those users with industry/SIC codes, zip codes, electricity prices and/or electricity source renewabilty (or carbon footprint)?  No single utility has this data, but firms such as Enernoc monitor consumption data across the country. What if they developed a cloud that encouraged co-location of workloads and businesses which take advantage of this data - such as monitoring which businesses are really "greenest", which vertical industries are growing fastest, or where alternative energy sources would be most attractive. Add to the database information such as energy efficiency programs or overlay it with data about alternative (wind, solar, geo) energy generation. The data at the core could attract compute workloads for use by other energy, efficiency, and economic monitoring businesses.

And more clouds: As I've mentioned before,

I could see this transforming both the cloud service provider ecosystem, as well as entire industry groups. Consider new Cloud Service Provider models:  What if NOAA formed the Weather and Atmospherics Community Platform? If healthcare companies created federated Medical Records Community Platforms? If the USGS formed the World Geologic Community Platform? If other brokerages created equivalent capital markets platforms? 

Building a Community Cloud with Gravity

The next natural question I wonder is how one might go about building a community cloud or "special purpose" data repository and associated compute cloud - be it around a vertical industry or specialized data type. In my opinion there are a few necessary properties each cloud (business) would have:

• Data sets that become more valuable as they grow and become more diverse - and of course which generate additional gravity of their own
• Business models that monetize the data - and perhaps generate additional derivative data. (In some instances the data may need to be anonymized).
• Co-located workloads that need to be co-located near the large (gravitational) data sets due to their frequent access 
• Privacy, security and regulatory controls specific to the industry and/or data type and globally provided/reinforced
• Industry-specific sales & marketing - presumably each community cloud would have appeal to specific verticals, markets or industry groups. Driving demand / awareness within these markets is of course critical.

If you know of community clouds based on data gravity, please share. In my opinion we'll see dozens of these special-purpose clouds form around data sets in the coming years.


For Further Reading:

• Data is the new platform, and Social is the Intelligence
• The next-generation business: Data is the new Platform
• The Data-Driven Enterprise Marketing Revolution
• NSF OpenTopography Project (The seed of another special-purpose cloud?)

A Tour of Switch's SuperNAP

I have to admit that I was prepared to be underwhelmed when I toured the Switch SuperNap in Las Vegas. After all, how impressive can a co-location facility be?  Just slab, cooling, ping, pipe and power.  Right?

With thanks to Mark Thiele (EVP Data Center Technologies) and Jason Mendenhal (EVP Cloud), I was able to spend some quality time in-and-around the facility (even inside one of the AC units) and got an education that mega data centers are much more than a structure to house servers.

First - let me give you some amazing first-impressions: Switch's SuperNAP is all about design and function. The structure, the architecture, the even the color scheme is all for a purpose - to communicate attention to detail. And while it might cost a bit more to color-code pipes and conduits, label every piece of equipment, architect custom lighting, or build with industrial design principles, it's clear that every item in the entire structure is there (and highlighted) for an intentional purpose.

And now for some observations and learnings:

Energy Efficiency
In all of the talk about energy efficiency, the SuperNAP averages a PUE  around 1.24 during the year. That means overall Switch's ability to minimize energy loss and to maximize cooling efficiency is extraordinary compared to most competitors... less than 25% of the total facility power is used for "overhead" operations, while the majority goes directly to the servers and equipment. That's a relatively rare feat these days, with the industry average of 2.9, and only 20% of data centers scoring better than 2.0 according to a Digital Realty Trust survey reported by the Data Center Journal.

Cooling Options
Arguably the breakthrough for the design of the datacenter is Rob Roy's breakthrough thinking about cooling. Traditional data centers take a "diffusive" approach to cooling equipment. That is, they place AC units throughout the data center, diffuse cool air (via raised floor) over everything, and allow the hot air from the servers to re-mix with the cooler ambient air.

But if you think about it, server racks should really be viewed as radiators (think about the radiator in your car). To achieve the best heat transfer efficiency, pull cool air directly through the radiator, and channel it directly back to the cooling device. And that's what switch does with their T-scif  (Thermal separate compartment in Facility). Cool ambient air is pulled through the server racks and channeled directly into a hot-air plenum. there is no mixing of the hot air w/cool. Think of this as hot-aisle/cold-aisle containment taken to the extreme.

Data Center Density
The notion of density makes sense along many dimensions. First, more server manufacturers are designing equipment as inherently dense - a packed Cisco UCS or Dell Blade enclosure can potentially pull 7kW or more. And there may be 4 or more of these units in a rack enclosure.... that means a given rack might consume as much as 15-25kw. (The SuperNAP is designed to support about 1.5kW/square foot, easily enough to handle a packed cabinet). But the beauty of density also helps with creating a larger heat differential aiding in heat transfer efficiency.

Supporting power and cooling density ultimately helps Switch because it means that a given customers needs less space - which equates to $ savings. Yet density also helps Switch due to the obvious efficiencies.

Co-Located Compute
Very early in the tour Jason pointed out the advantages of customers and partners co-locating their equipment within the SuperNAP.   With the physics of bandwidth and latency hard-at-work, it became clear that certain customers had an advantage to co-locate their private cloud infrastructure in the same data center as their public cloud partners (or other service provider customers). Apparently there were many examples of this co-located hybrid cloud approach at the SuperNAP. 

Co-Located Networking
The SuperNAP is literally a nexus of multiple Network Access Points - that's the NAP part - originally built by Enron. (In fact, it was pretty cool literally seeing the conduits come up out of the floor with the fibers inside!)  This fact provides users with advantages such as network redundancy as well as the ability for Switch to broker bandwidth at wholesale prices. They market this as the Combined Ordering Retail Ecosystem (CORE).

Physical Security and Disaster Preparedness
It wouldn't be complete if I didn't mention the physical security that Switch provides... something slightly out of "24".   While it's not appropriate to share details, suffice it to say that entry onto the campus, into the building, and around/within the cages was closely and carefully monitored and guarded.  The facility itself is secured in multiple zones, as-are the tenant areas.

But the other security blanket Switch offers is back-up power and cooling. Should there be an outage from the local utility, cooling is literally designed to "flywheel" for enough time for generators to kick-in.  And there is sufficient fuel on-site (and sources off-site) to maintain operations through even the fiercest unforseen disaster.

Example: Content Hosting and Distribution
Without naming names, a major content streaming company chose Switch for nearly all of the reasons above.  But what I found particularly  fascinating and compelling is that they even co-located their physical broadcast operations at the SuperNAP.  Picture aisles of million-dollar storage arrays pumping-out movies and live TV shows 24x7 across the country. Co-located is the nerve-center -- not unlike NASA mission control -- that monitors performance and delivery country-wide. Why Locate at Switch? Besides all of the efficiency and security aspects, access to nationwide backbone networks ensures maximum video performance.

Going forward, Switch will be more than doubling its capacity in the next year or so, building into new expanded facilities. And from the sound of it, much of the space is already spoken for.

Who says the data center isn't important? I certainly wasn't underwhelmed by this visit.



For More Information

• Assessing Data Center Metrics Fountainhead blog
• High vs. Low Density Data Centers, Cloud, Cost, PUE & Sustainability by Mark Thiele of Switch
• Mapping a Course to Data Center Efficiency by Jack Pouchet on Data Center Knowledge Blog

What Is Meant by a "Cloud-Ready" Application?

Is calling an app "cloud-ready" just a form of cloud-washing?  C'mon - aren't all apps "ready for the cloud" (and for that matter, ANY cloud)? Doesn't IaaS and its elastic capacity + automation solve for all app scaling and configuration issues?

You'd think so if you listened to all of the accolades paid to the public cloud these days. But as I dug into the complexities of maintaining sophisticated app landscapes, just dropping them onto a public IaaS cloud only helps to a point.

Why? Because a complex landscape will include many servers (often virtual machines) linked by unique network topology (including load balancing, firewalls, etc.) connected to differing forms of storage (not to mention storage tiering, backup etc.) and all choreographed to work together in a specific manner with unique rules.

Only your ISV and app architect know for sure...

It turns out that IaaS (and/or PaaS) infrastructure foundations are necessary, but not sufficient solutions to allow app admins to fully maintain complex app landscapes in the cloud.

Why? It's because these landscapes don't fully self-manage the app environment. They don't interact with the applications' unique configuration rules and procedures. They don't have knowledge that only the ISV can have regarding optimal capacity and topology. And they can't predict what changes to make until told to do so.  Thus, most cloud hosting scripting - while convenient - is still a but of a kludgey solution if you really understand the specific application.

And the system gets another layer of complexity when you consider that different (public/private) clouds may embed differing properties. So if/when an admin wants to redeploy the app on a different cloud, he faces another headache.

Enter: ISV App Orchestration
Admittedly, I believe "orchestration" is another nebulous concept next to "automation" and other over-used terms.  But in the context above, let's consider "App Orchestration" and where it can help.  Later on, I'll give a few examples of providers who are currently solving the problem.

As I mentioned, the best forms of App Orchestration ought come directly from the ISVs themselves. Presumably they know the the ideal configuration dynamics, SLA controls and more. Specifically, app orchestration (AO) ought to provide the following:

• Blueprints for landscapes - The AO engine/layer must necessarily start with knowledge about the required app landscape and topology - and be capable of initiating it. Somewhat akin to AWS CloudFormations, the AO layer must be able to invoke a partial or entire instance of the app - for a specific scale or a given infrastructure. Such blueprints or templates then serve as starting points for other topologies and/or governing rules.
• Operating (or dynamic) orchestration - At the core of the AO layer is logic around optimal adjustments to compute (number and location of app images and VMs), network (including load balancing and QoS), and storage (connectivity, tiering, caching). Balancing these resources is not necessarily linear, and differing use cases for the app may impact how these resources are combined. In general, only the ISV architect may have knowledge about such workflows and optimizations.
• Goal-based automation - Even if you set up an app landscape on top of IaaS, it doesn't guarantee administrators won't have to adjust it in the future. Say you want to re-optimize around a specific SLA (or combination of SLAs). Or that you want to scale the system in advance of new users. This feature helps set (and sequence) future-state goals for the system to attain and maintain.
• Multi-cloud deployment - There are many pure-play vendors currently on the market that facilitate deployment onto differing public clouds (e.g. Rightscale, Scalr, enStratus) but none operate from within the app administration console. This allows the app admin to determine as part of the apps own policies, where and when to place workloads on differing private and/or public clouds.
• Multi-version management - Any vendor should recognize that larger customers with multiple locations will likely be running more than one version of their software. AO needs to recognize this reality, and orchestrate landscape instances (or even parts of landscape instances) that may have various versions.
• Multi-tenant management - Again, any vendor should recognize that larger customers (and especially service providers, SIs, etc.) are likely to need to manage separate/isolated tenants on the infrastructure. AO needs to recognize this not so much from a role-based admin perspective (a prerequisite) but from the perspective of maintaining isolation of one landscape while being capable of manipulating another.

Next: Suite Orchestration?

I also wanted to share a brief thought here: What would a "cloud-ready" software suite look like?

We all know that large software and platform vendors (think: Oracle, SAP, Microsoft, Symantec, Citrix, CA, IBM, HP etc.) offer tons of what they call end-to-end software. They all say that their SW is integrated.  But can they all claim that those suites are cloud-ready? Can they all be orchestrated as an integrated system together?  Probably not. Not yet anyway. Which leads me to the next section...

App Orchestration: A new (required) layer for ISVs?

Traditionally, ISVs (and their customers) have had focus on code, on APIs, on performance tools, and on management/monitoring software.

However, during the recent virtualization era, the push has been for ISVs to go further and ensure that their apps can be virtualized and supported in an entirely virtualized data center.

As we now enter the Cloud Era, I believe ISVs delivering complex apps and/or app suites will be required to provide intelligent orchestration when those app portfolios are run in a cloud environment. That means "north-south" orchestration, i.e. how the software interacts with the IaaS/PaaS layers, and "east-west" orchestration, i.e. how the software interacts with other components/products from the vendor.

The "east-west" coordination is what I find most intriguing. That might mean continuous orchestration between specific apps and networking, storage, firewalls, IaaS, DBs and more. Across all products from a given ISV's software suite.

This would shift the notion of a vendor's "suite" from being a loose aggregation of apps and tools, to one that was indeed cloud-ready and orchestrated as a system. Even if only for use with an on-premesis cloud.

Will vendors begin to acquiesce the need for true orchestration in a cloud? I hope so. The ISVs are really the only ones with the deep knowledge to do so. And in the Cloud Era, the value to customers would be immeasurable.



Other Resources

• App Orchestration Concepts [Blog] Ashish Gujarathi
• Wikipedia on orchestration
• IBM DeveloperWorks on Cloud Orchestration [Blog]
• ISVs doing this?
• OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA)

A Tale of Two Cloud Strategies

These are the best of times. These are the the worst of times. These are the times of the "cloud era" where two technology leaders are struggling to dominate the IT infrastructure, private cloud, and public cloud markets.

Two recent announcements lead me to making an interesting business strategy observation about two opposing approaches to dominating these markets:

• VMware's recent announcement that it intends to venture into the public cloud (assessment courtesy of James Staten)
• Amazon Web Service's recent (re) announcement of its Virtual Private Cloud (VPC) functionality as it ventures into the enterprise (on AWS Blog) as well as their recent teaming with Equinix and Netapp

As they mature, each company is trying to stake a claim in the others' territory. VMware venturing into Amazon's domain, and Amazon's venturing into customers dominated by VMware. 

AWS: A Strategy Going from Public to Enterprise

Let's first examine Amazon AWS. These guys essentially pioneered the public IaaS cloud. Early users were dev/test engineers, experimenters, and special projects teams to see how far they could push the cloud. Arguably these users remain the mainstay of AWS. But Amazon realized that it needed to grow beyond these early-adopter audiences.

And, AWS has steadily improved on their platform. Not just in raw size, but in services. It seems not a week goes by that AWS doesn't announce another service API for their cloud. One could argue that taken in total, AWS is constructing the de facto public cloud operating system.

But they've also recognized that growth depends upon expanding into and winning-over the enterprise with additional services, security and business-models that CIOs expect. I see VMware pursuing 3 strategies to do so:

1. VPC - Creating an extension of an enterprise's network and data center within a virtual private cloud hosted on Amazon's infrastructure
2. Public API - Tacitly (or explicitly) allowing 3rd parties with an enterprise presence to use the AWS set of APIs. Be it Eucalyptus, OpenStack, ASF CloudStack or others, Amazon knows that when enterprise software and IT skills are designed around their APIs, they ultimately win - since switching costs from deploying in the enterprise to deploying in EC2 become nearly zero.
3. Channel distribution - Amazon also knows that enterprises like to buy through trusted distributors and value-added resellers. AWS has been savvy in allowing the traditional channel distribution mechanisms to have access to AWS (at a reseller discount, of course).  Traditional channel VARs know that they ultimately have to develop business models with AWS, lest they be cut-out of the value-chain by customers going direct.

VMware: A Strategy Expanding from Enterprise to Public

In somewhat contrast, we have VMware. A leader in enterprise virtualization and management, VMware has been pursuing domination in enterprise IT focusing on its own virtualization and infrastructure management technologies - not to mention a cloud framework and sophisticated management tools.

VMware also believes that a strong ecosystem of hosting providers and cloud service providers will help it cement its technology in the market. By encouraging those partners to build their own clouds and services on top of its products, technologies and APIs they hope to expand the prevalence of their platform and use by enterprises - since many of these partners already have relationships with the CIO.

But recently (IMO) VMware has acquiesced that it needs more clout in the public cloud space to maintain growth in a quickly-saturating Enterprise virtualization market (threatened by Microsoft, Citrix, and others). Thus, they recently announced the intent to develop a hosted Hybrid Cloud service.  The intent would be to offer existing VMware customers what would appear to be a seamless extension of their virtual infrastructure into VMware's own hosted virtual infrastructure.

Whether this turns out to be a true public cloud (as in a direct competitor to AWS) remains to be seen. And even though this new service is expected to be sold through VMware's existing channel, there is no doubt that it will cause some channel conflict with their existing hosted service providers.

Nonetheless, this strategy clearly marks VMware's move into the public cloud style of business, perhaps encroaching into Amazon's VPC space.

What's Next: More of the Same

These sorts of growth strategies are not new to business. Companies continually try to go expand into adjacent markets when growth begins to stagnate or when competition gets fierce. No difference here.

These will be extraordinary strategies to observe over time. We all know that even the most dominating companies/technologies eventually meet their match (or their disruption).  Both VMware and AWS have appeared at times to be unstoppable. As they converge, it will surely be a battle of gladiators.  Unless (or until) of course, third, fourth and dark-horse players disrupt the party. As they always do.

Only in Silicon Valley: License Plate Sightings in the Field

Driving around silicon valley on routes 101 and 280 ("The 101" and "The 280" if you're from California) you can't help but notice this isn't like the rest of America.  You'll see dozens of Priuses. Frequently you'll even see Teslas and Fiskers. And there's that white all-electric 325i I see buzzing around. But what really drives-home the fact that this is northern CA are the Vanity plates.

Herein I will only post plates that I personally see. To wit:

Webmaster1 - yes, I believe you were #1... because this car may have been around since Tim Berners-Lee invented the web.

Ethernet - This guy is parked right around the corner from where I live. I'm thinking the car also dates back to the first time that a 10baseT got plugged in...

Patent: This one speaks for itself. Their other car is probably a Bentley.

WebApp.  Microcode?

 

1E4 Gauss. That's a Tesla.... literally and mathematically.  Maxwell would be proud of ya'.

Apple. No, not Steve's car. But I'm sure they've had multiple offers for this plate. Wondering how many times it's been stolen.

I Debug. What Claudius the engineer says. One classy coder.

Byte Law. I take that to be a metaphor for Shark Attorney. Nice Karma.

The Beginning of the Non-Dedicated Device World?

What makes your phone your phone? Or, for that matter, what makes your desktop, your laptop or your tablet yours? After all, millions of people own identical hardware/software configurations of iPhones, Android-based phones, tablets, laptops and other devices.

The answer lies in two defining aspects of each device: The user’s data that is locally-stored, and the user’s personalization information... More at  http://blogs.citrix.com/

The End of the Laptop-Centric World?

Is this you:  You own multiple laptops or desktop computers because you have different uses, jobs, clients or applications? 

Doesn't this seem ridiculously inefficient and wasteful - especially because we now in the "cloud era"?

Turns out there are quite elegant solutions that move us away from this "boat anchor" centric lifestyle where activity revolves around the laptop work hub.

The solutions I have in mind are not always broadly used, or for that matter, broadly known. But they are often quite simple, convenient, and even cost-advantageous.

Let me give you a hypothetical example - but based very much in reality (names have been changed to protect the innocent). And I'll share a very reasonable set of solutions, too.

Act I: The Setup
Let's take a consultant named Margo.  She runs a small firm with a handful of large corporate clients.  To accomplish her work she needs access to each client's intranet as well as a number of their secure, internal applications.  She also needs to share data with co-workers in her firm, as well as share it back to individual contacts within each client.

Each time Margo takes on a new client, they issue her firm a corporate laptop, usually equipped with VPN software and a 2-factor security app with a physical fob. Whenever Margo does remote work with a given client -- accessing the intranet, using internal apps, interacting via collaboration software, or even certain VoiP apps -- she must use the appropriate laptop.  And that's about 80% of the time.

To add to this, alongside each laptop, Margo uses a DropBox account with folders dedicated to each client. She shares these folders with her co-workers as well as client contacts within each company (and who are behind each client's firewall) as interactive project-based workspaces.

Act II: The (Troubling) Reality
Fast-forward: We have Margo with an office full of client-provided hardware. Together her firm is holding capital equipment that cost each client between $2k-$4k.  It's equipment inventory each of her clients have had to request, allocate, provision, track and maintain (and likely one day, recapture). Besides the cost and efforts to secure, the equipment is still subject to breakage, loss, theft and/or other forms of compromise. 

That's wasteful / risk-laden observation #1.

Next, we have the "DropBox problem": One day Margo realizes that she's running short of disk space on her own office tower computer. She tracks it back to the fact that her single DropBox account contains files from all of her co-workers representing the work from all of her clients... and it dawns on her that files from client A have been accessible to all other clients via the single DropBox account. She races to modify the access rights to various DropBox folders.

That's risk-laden observation #2

Finally, Margo finds herself on a business trip visiting Client A. She gets a call from Client B needing an urgent intervention. But since she isn't carrying the laptop from Client B, she's unable to help.

That's just plain silly observation 3

Act III: An Elegant Solution

All of these unfortunate scenarios are a result of a "PC Era" view of the world - where data, access and security are tied to the physical laptop. To be certain, there are absolutely scenarios where this should remain the case. But in Margo's case, the model is antiquated.  Let's move to the "Cloud Era" and see how things might be different.

Enter the concepts of "Mobile applications" and "Virtual desktops". In these cases, each of Margo's clients provides a shared (or dedicated) desktop OS behind their firewall. They might also provide a secure application streaming protocol for specific internal applications (think: SAP, accounting, web browsing, email, etc. etc.).  Both desktop and/or application gateway are made available as virtual desktops & apps via a web gateway to approved users.  All a user needs is a client device (laptop, iPad, smartphone) and a secure authentication mechanism.

So, Margo would simply carry her own personal laptop (or iPad, for example) as well as security fobs from each of her consulting clients.

Any time Margo needs access to work with a client, she connects to a gateway (think: click on an app) hosted by one of her clients, and enters her security credentials. Up pops a secure desktop belonging to one of her clients, just the way she left it the last time she accessed it.  All of her data files are there, as well as email and applications. And she'll have complete secure access to her client's corporate intranet.  In fact, she could even have multiple secure desktops from each of her clients up-and-running simultaneously on a single machine, with no security issues whatsoever.

But there's one difference: When she closes the session(s), no client data will reside on her laptop - safe and sound for her clients. And, no matter where she is, no matter what device she has (her own, a borrowed iPad, etc.) she can re-access those desktops and/or applications.  Pretty elegant.

What if Margo is "untethered"?  There's even a scenario for the untethered worker. She could install a virtual machine desktop on her laptop.  Within that secure "sandbox" would run the OS belonging to her client, with all access rights etc. Each time the device is connected to the net, the sandboxed OS (and its apps) would synchronize with her client's IT department. 

Oh - And what about that "DropBox Problem"?  With this model she (and her co-workers) can use a shared drive or service either (a) within the client's firewall, accessible whenever the virtual desktop is active, or (b) a separate shared drive brokered by a client's own gateway service.  Never would Margo risk data from one client being co-mingled with data from another.

In my opinion, the "PC era" will begin to ebb, as the concept of mobile apps and virtual workspaces begins to take hold. And as more IT departments become more comfortable with BYOD strategies and mobile work options, the more this trend will accelerate.

Here's saying goodby to the laptop-centric world.