Cloud computing has been getting an increasing amount of press recently, because it offers attractive solutions to a number of business problems. Cloud computing translates to "hosted applications;" a hosting company lets you build and deploy applications on its servers, delivers those applications through users' browsers, and generally promises near-24x7 uptime and unlimited scalability. To businesses, that translates to hard dollars: servers the company won't have to buy and maintain, databases for which the company won't have to buy licenses, free storage, backup, and disaster-recovery services—all of which mean IT personnel that the company doesn't have to hire and pay salaries and health care for.

Most hosting companies offer infrastructure for development as well. Common types of applications can be developed more quickly, deployed more easily, and scale immediately. That's an attractive proposition; however, there are downsides.

The first problem? Despite the promises availability  has been less than stellar. Many of the major hosting companies have had outages recently, including Google's Gmail, Amazon's S3, and salesforce.com. Web site outages aren't usually terribly important to businesses, because most sites don't host applications that the business depends on. But when businesses begin to host mission-critical applications in the cloud, such as email, customer/sales data, and financial services, they need and expect near-perfect service levels.

Second, because hosting companies own the hardware, it's unclear how difficult or expensive it might be to retrieve the data generated by all these cloud-computing applications. But in today's world, these applications and data are essential to the business. What happens if a service outage can't be fixed quickly? What happens if the hosting company goes out of business altogether? What recourse does a business have if a hosting company fails to back up their data and loses it? Hosting companies essentially hold businesses hostage to their own data.

Third, so far, each system is unique—there's little to no ability to move applications from one hosting company to another without rewriting and retesting the application. Sure, businesses could write applications that copy the data to internal servers—but that puts them back in the position of maintaining their own servers, losing one of the major advantages that cloud computing offers.

Finally, there's a question about what the hosting companies could do with the data that gets collected on their servers. Obviously, they have access to that data, and obviously, they must be allowed to have some level of interaction with it: encrypting and decrypting it, backing it up, copying it to improve throughput, moving it between servers, etc. This raises questions about exactly what rights the hosting company has. If a hosting company employee looks at your data, what's the penalty? What if a hosting company decides to sell one company's data to a competing company? What if they outsource the data-hosting portion of the business? What if the hosting company decides to mine the data for email addresses and user interests? Whose data is it, anyhow?

Unfortunately, the real-life answers to these questions have been disappointing. So far, court decisions about who "owns" stored electronic data have trended firmly in favor of the owner of the hardware on which that data is stored, or the business that generated the data, regardless of who generated it. For example, many employees have discovered (to their surprise) that anything they write or any data they generate using a company computer (such as email, documents, or Internet access logs) belongs to their employer, and that the employer is perfectly within its rights to analyze that data or use it however they see fit. One recent UK court case found that an employee who simply uploaded his Outlook contacts list to LinkedIn did so illegally, because—even though the employee insisted he had built that contact list personally—it belonged to the employer.

All in all, it's no surprise that a recent survey of top CIOs by Goldman Sachs & Co. found cloud computing was the last item on their priority lists. One analyst posited that the reason cloud computing placed so low is because "They [hosted services] require a technical understanding to get to their importance. I don't think C-level executives and managers have that understanding." But it's rather obvious from the simple advantages stated at the beginning of this blog that gauging the benefits of cloud computing does not, in fact, require much technical understanding. It's far more likely that executives and managers are avoiding cloud computing because they do understand the implications, and are simply making logical decisions to protect their business data.

An interesting split is becoming obvious in computing today; older people (among them those who were instrumental in empowering computing and the modern web), are increasingly worried about privacy, while younger people (those who've been exposed both to the weband on it—for most of their lives) seem to be far less interested in privacy issues, tending to view the web as a vehicle for social interaction, even if that social interaction involves losing control of their personal privacy altogether.

This emerging difference becomes glaringly clear in the brief comments in this TechnologyReview.com article. For example, Mena Trott, president and cofounder of Six Apart in San Francisco, says: "With the popularity of blogging and online video and photo sharing, we already know that people want to publish significant portions of their lives online. In 10 years, I can easily see someone putting 75 percent of their day online. But it won't all be public."

In contrast, Bjarne Stroustrup, Professor at Texas A&M University and designer of the C++ programming language, says that within five or ten years we can expect "The total end of privacy. Governments, politicians, criminals, and friends will trawl through years of accumulated data (ours and what others collected) with unbelievably sophisticated tools. Obscurity and time passed will no longer be covers."

Even Richard Stallman, the foremost advocate of open source, isn't really interested in open-sourcing people's private data, saying: "I see a danger in the Web today: doing your computing on servers running software you can't change or study, and entrusting your data to U.S. companies required to give it to Big Brother without even a search warrant. Don't risk this practice!"

The problem, as I suspect many older people see it, is that collusion between businesses (those license agreements that give businesses the right to have "associated businesses" access your data) and between businesses and government effectively makes a lie out of assurances such as Trott's that "it won't be all public." The opposite of public is "private," but what is private when ISPs and governments can search through every request, every post, every email, every IM transmission, and every digital phone conversation you have? Is it private just because your neighbors and friends can't see it? Ben Franklin wrote: "Three may keep a secret, if two are dead." That statement's just as true today as it was when Franklin wrote it. Do you really trust people with your private information? If so, why? People with access to secrets not only tend to misuse them, but also share them with others. Even at the business level, recent research suggests that a large number of those with access (network administrators) look at information they're not supposed to be viewing.

It's bad enough when you first truly understand that your recent data is not private. But now, imagine a world in which every faux pas you've ever committed can be discovered, resurrected and perhaps used against you.

Remember when you once posted those pictures of you at that graduation party in Maui? Now you're applying for a job at a company owned by a conservative Christian business network. Too bad. Rejected.

Remember that IM conversation you and your buddy had one evening about your career choices, where you said you never wanted to get put into the position of having to fire large numbers of employees? Now you're up for a promotion, but you have to be willing to wield the corporate axe. Oops, guess you won't get it.

The plain and simple fact is that there is no real privacy in digital data. There never was any complete and total privacy, of course, but there was a strong probability of privacy, because private data was difficult to access and search. Most paper-based data was filed in a single location, and access was typically restricted to people with good reasons to look. Even published information reached only subscribers, or those willing to spend the time manually scanning library copies. Moreover, much private data simply disappeared after a period of time. Records of childhood legal infractions were sealed. Financial records were destroyed after seven years. People threw away letters when you were no longer a part of their lives. And some communications were too difficult to monitor. Phone calls from public telephones were essentially anonymous. Conversations with a journalist were once considered unassailably private. None of that is true any longer—Stroustrup is correct in saying that obscurity and time passed will no longer be covers. The things you say, the places you go, the items you buy, the food you eat, the pages you visit—these combine to create an electronic trail that employers, governments, businesses, or any sufficiently interested and well-financed person can use to discover things about you that you might not want known.

When confronted with this fact, the enemies of privacy typically argue that there's no reason to hide anything you've done unless you've done something wrong that others should know about; that hiding information is tantamount to lying, and that in this age of terrorism, everyone has a right to know everything about you, particularly your government. That argument should sound familiar to those who remember the 1950's witchhunts.

But being able to outlast every tiny personal truth gives you the ability to become the person you'd like to be, rather than the person you were in the past. Americans have long believed in (or at least given lip service to) second chances. We love hearing about the gang member who gets his GED in prison, and goes on to become a successful business executive. We love stories about the prostitute with a heart of gold who marries the millionaire.

Conversely, the inability to obscure every tiny personal fact can make you now and forever the least appealing person you've ever been. The one who gave into temptation, who stole, lied, cheated—who failed in some way, perhaps even in a way that, at the time, wasn't considered a failure. For example, you might have voted for the "wrong" person for President, and mentioned it to your mother in an email, or written it proudly on your FaceBook page. A partisan administration might hold that against you.

On the other hand, perhaps most humans can see beyond the peccadilloes of people's pasts—particularly when their own mistakes are equally open to scrutiny. Perhaps the stigma of indiscretions currently held private will disappear, when it's no longer possible to hide them. Perhaps the total honesty engendered by "life searching" will create better, or at least more tolerant people. (I'm skeptical myself, but one can always hope.)

So is this generational divide in the approach to privacy due to accumulated wisdom, or is it due to aging pessimism? What do you think?

From a developer's perspective, Tech Ed 2008, which attracted over 6000 developers to Orlando, doesn't offer much that's completely "new;" however, it does offer a great deal of value for developers who need to find out about existing technologies. If there's a single overview word that one might use to describe the thrust of the conference, it's "unification." Microsoft is unifying the developer view into its existing technologies.

For example, starting with the small and moving toward the large, the .NET Compact Framework, the .NET Embedded Framework, Silverlight, Office, Visual Studio, SharePoint, BizTalk, and SQL Server all leverage developers' knowledge of the .NET framework and its supported languages in very much the same way; after becoming familiar with the framework and one language, you can build on that knowledge to write applications intended to run embedded in other devices, to run on mobile devices, to deliver rich content through a browser, integrate with Office applications, run as standalone desktop or Internet-connected applications, or run custom code inside SQL Server—all without having to learn a completely new environment or language. Unification is the theme not just with developers, but with architects, development managers, designers, testers, and maintenance; the newest and upcoming toolsets cover the entire application lifecycle.

One of the most exciting additions to this lineup is Silverlight—no, not the 1.0 version; the new 2.0 (still beta, but soon to be released with a Go-Live license) version. Silverlight puts Microsoft's WPF technology—specifically XAML—front and center in the development world.  The new version not only improves rich media (video/audio) delivery, but moves beyond JavaScript, letting developers write Silverlight code in familiar .NET languages such as C# and VB—and some newer ones, such as IronPython and IronRuby. If you haven't started exploring WPF, I highly recommend it.

Bill Gates, giving what may be his last keynote for Microsoft (he's stepping down at the end of June to concentrate on his work with the Bill and Melinda Gates Foundation) mentioned two other noteworthy topics. First, SQL Server 2008 (soon to be available as RC 0) adds the ability to store geographic location points (geopoints) as a native type. In a brief demonstration, he showed how a user could identify a point, and an application could request additional points of interest within a circle with a defined radius from that point. While perhaps not groundbreaking, adding location data as a base type both simplifies developing location-aware applications, and elevates them to mainstream status. 

Other enhancements to SQL Server 2008 include support for external blob storage in the file system, on local NTFS-formatted drives. Storing blobs externally gives SQL the ability to manage files and large binary data blobs in an intuitive way, letting developers treat them as standard file streams, while still taking advantage of SQL Server's transaction, rollback, and backup features. This also helps to avoid the performance penalty associated with storing large blobs internally.

Finally, SQL Server 2008 adds support for hierarchical data (tree structures). While it's been quite possible to handle such data before, T-SQL itself provided no assistance. Because tree-structured and hierarchical data has become ever more common, that's a welcome addition.

Another welcome technology, although still under development, is enhanced modeling in Team Studio.Brian Harry, a Technical Fellow in Microsoft's Developer Division, demonstrated how code submitted to a project repository containing a model of the application can be tested at check-in to ensure that the code contains no dependencies that would break the model. As applications have become ever more complex, improved modeling support helps to unify the original architect's vision of not only the application but the application code itself. The modeling support will ship as part of "Oslo," Microsoft's code name for its upcoming model-driven and service-enabled application toolset(Oslo is MS's vision, but what, exactly, is it? What kind of app? EG). Brian said developers could expect a CTP of Oslo at Microsoft's PDC conference in October.

Being in the front row for perhaps Bill's last keynote reminded me how long I've been working in this industry; I remember when IBM chose the relatively unknown company Microsoft as the supplier of its PC operating system—DOS. Bill's departure comes at a time when development is undergoing a major shift, where instead of having to learn new languages or new hardware platforms to gain new capabilities, developers can concentrate on gaining deep knowledge of their core focus areas, relying on tool improvements to give them access to new capabilities and new devices, while still using their existing tools. We all owe Bill a debt of gratitude. Sure, he was lucky to be in the right place at the right time, but he also helped create our industry and make developers a driving force in the modern world. Thanks, Bill. Good luck in your new endeavors. You'll be missed.

Business computing today works largely on a flawed vision of reality. For example, consider an inventory-management application. The system holds a list of items in a database, such that:

• When items arrive at the store, the item counts are incremented with the number of items that get stocked.
• When an item gets sold, the system decrements the count for that item.
• When an item count falls to a specific pre-set level, the system marks that item for ordering, or possibly even orders more stock automatically.

But the system doesn't really know how many items the store has. It can't, because the items themselves have no connection to the computer. For example, the system can't—by itself—account for misplaced items or stolen items. The system is forced to rely on a human to give it that type of information.

All that's going to change, because one of the next big advances in computing is location-based computing, which uses one or more methods to let the computer know and track the exact location of objects or people.

Location-based computing, so far, has been primarily concerned with GPS information: geographic locations—positions—of roads, buildings, trucks, and, in some cases, people. Trucking companies, for example can attach a GPS system to their trucks, which can then wirelessly send their location back to company headquarters every second or so, letting the company track the actual position of the truck. If it stops, the company will know. If it gets lost, the company will know. If the driver speeds, or drives too slowly, or takes a detour to visit his family, the company will know.

Similar applications let you track individuals via their GPS-enabled cell phones, or indeed, any cell phone, because software can triangulate the position of a cell phone by the relative speed with which it responds to various cell phone tower signals. That's how the 911 emergency service can locate a cell phone caller.

GPS tracking is fine for large objects that move large distances outdoors, but it's not cheap. A GPS receiver is relatively large, and it's not well-suited for tracking objects that are indoors, where they don't have clear access to satellite signals or objects that move only small distances, such as items in a store, books in a library, or children in a school. Another technology, called Radio Frequency Identification (RFID), is better suited for tracking small objects. Several years ago, Walmart, in a rare lucid action that might actually benefit employees, customers, and the corporation, announced it would require all its Sam's Club suppliers to tag shipping pallets with RFID tags by 2010. At that time, RFID technology was in its infancy, tags were battery-powered, relatively large, and expensive.

Tagging pallets to trackmerchandise uses RFID at the macro level, but still doesn't help computers track individual objects—the goods after they're removed from the pallet. But we're about to see an explosion in location-based computing at the micro level. Newer generations of RFID tags are far smaller, have (mostly) dropped the battery and draw power from the tag reader's electrical signal, can hold more data, and are more reliable. You can easily buy tags today that are about the size of a grain of rice—but much smaller tags are in development; some are the size of a dust particle, almost invisible to the naked eye. 
RFID tags do cost money, but the price is coming down rapidly. Costs vary depending on the type of tag (powered or unpowered), how close a reader must be to read the tag, the amount of information the tag will hold, the tag's frequency, the tag's size, and of course, volume. Common unpowered tags currently cost between 7 and 15 cents per tag. They're already being used on some big-ticket items, particularly those that are small and easy to misplace or steal. Readers cost money as well, running from $100 to $750 or so, with the average reader probably running around $300. At these prices, the tags obviously aren't ready to be used to track inexpensive items. However, they're already reaching the price point where they're useful for tracking more expensive items, where keeping the item's location in sync with software is critical.

If you're already working with location-based computing technologies, let me know. If you're not, but you have ideas about how you plan to use location-based computing in your business or your applications, let me know that as well.

Here's the average developer's newest dilemma: Intel and other CPU manufacturers have moved full steam ahead into creating multi-core chips to speed up computing. These chips increase processing speed not by improving the speed of a single CPU as has traditionally been the case when new chips debuted in the past, but by adding additional CPUs. These new chips contain two, four, or (soon) eight CPUs. The idea is that developers can (potentially) double, quadruple, or octuple the speed of their applications by writing code that can split operations across all the available CPUs. That's great--in theory. In practice, however, it turns out that few developers are comfortable writing and debugging even multi-threaded code running on a single CPU, much less writing and debugging code intended to run in parallel on separate CPUs. Moreover, the languages most working developers use don't yet contain constructs that allow them to target multiple CPUs, nor are the debuggers all multi-CPU aware or capable. Nonetheless, hardware manufacturers are already touting the speed increases businesses should expect from their software when it's running on the new chips. And no doubt, managers will soon be asking why their new dual-CPU hardware is no faster when running their existing applications than their old hardware was.

As usual, the hardware cart has been put before the software horse. Sure, the C and C++ guys can find some first-generation tools for writing multi-core code. But for business software, the miracles won't start appearing until developers get multi-core tools that work with their common standard languages.