Paul Venezia got me thinking this week with his InfoWorld article, Why do we trust Google? In the article, Paul points out that generally people are reluctant to hand personal data over to a third party, unless that third party is Google. While Google has a "Don't be evil" motto, that's hardly reason to extend them trust. After all, that's exactly the motto you'd expect for an evil corporation, right? Paul rightly points out that with all the various data that Google is collecting about us, starting with search terms but then extending to location data used with Google maps on smart phones, to email, to documents, there is a lot you can know about a person if you just sift through the data and make connections. And Google has really great infrastructure to sift through that data. Should that concern us? You bet. But that said, at some point you have to start trusting service providers. The only alternative is to completely avoid using service providers at all.

For instance, the Amish culture's avoidance of many modern conveniences is not because these inventions are viewed as evil, but rather that the Amish do not want to become dependent on the outside world for their survival. Because the Amish don't fully control the electricity that would power their farms, their desire for independence requires that they avoid using it.

Richard Stallman, of GNU fame, has previously argued that computer users should not cloud computing because of the associated loss of control. In effect, Stallman is an "Amish computer user." He has always been adamant that users be able to control their computing environment, all the way down to having all the source code available to all the programs that they run, a philosophy that kicked off the GNU project and ultimately the whole open source movement.

Unlike the Amish or Richard Stallman, the rest of us are typically seduced by the dark side to one degree or another. I use electricity and other modern conveniences pretty much 100% of every day in one way or another. PCs and smart phones make up a large fraction of that mix and those devices are all connected to cloud computing resources in one way or another. At some point, I simply don't have enough time to be paranoid; I have to give up, trust other people, and get my work done.

That said, I'm still wary of many providers. I tend to avoid stuffing my confidential information into new, unproven service providers, for instance. I'd rather see a provider build up a track record on which to base my trust, rather than believing the image projected by a slick home page. I keep my financial life separated from my social life (hint: if you're using the same username and password for both your online banking application and Facebook, you might want to rethink that). Finally, I'm constantly asking myself, "Can I afford to lose this data, or have it compromised? What would happen if either the service provider's security was breached, or the service provider started to misuse the data I'm giving them?"

Trust, whether between humans in the real world or between humans in the cyberworld, is earned. It takes a lifetime to build and can be destroyed instantly with a single careless action. While I'm maybe not as distrusting as Richard Stallman, the Amish, the question is a good one and Paul Venezia is right in asking it about Google and every other cloud provider. You're right in asking the same question, whether personally or about your enterprise's cloud providers.

For the last couple of years of cloud computing evolution, people have noticed that enterprises have been hesitating to fully embrace the cloud. It's obvious that enterprises are intrigued and even excited about the promise of cloud computing, but something has been holding them back. The common wisdom was that security was the problem child. Without a strong security architecture, enterprises wouldn't embrace the cloud.

While security is part of the problem, the larger underlying concern is really governance in general, says a new report by research firm Ovum. Enterprises, says Ovum, are very concerned about exposing their businesses to new risks and need to be able to manage these risks before cloud computing can be fully embraced.

Lachal said that as companies build out their private clouds and begin integrating them with public clouds, IT administrators will have to implement new rules for managing and sharing data that promise to be more complicated than anything they've dealt with before.

"Despite growing interest in IT transitioning from managing technology to providing technology as a service, neither business nor IT executives have been particularly proactive in managing the various changes that such a transition requires at all levels," he added.

Cloud computing makes IT governance more difficult by introducing an additional layer of complexity that businesses need to control in order to make the most of its benefits, the report said.

At ServiceMesh, we agree completely. Two years ago, we started developing the Agility Platform to provide a tool for companies to get their arms around the full lifecycle of applications living in the cloud. Using end-to-end policy management, customized automated workflows, security overlays, and automation in concert, the Agility Platform provides the cloud governance solution for large multi-national companies, particularly in highly regulated industries such as financial services, healthcare, and life sciences. We believe enterprises need to actively embrace a proper governance strategy to create the environment in which they can fully exploit the benefits of cloud computing and Agile IT.

I saw this article the other day and had to chuckle: Gadget Watch: Apple Sorry for iPhone 4 Fiasco

Summary: Apple opens up iPhone 4 preorders and is overwhelmed by 600,000 orders the first day. The order-taking infrastructure crashes from the load:

"Yesterday Apple and its carrier partners took pre-orders for more than 600,000 of Apple's new iPhone 4," Apple said in a statement Wednesday. "It was the largest number of pre-orders Apple has ever taken in a single day and was far higher than we anticipated, resulting in many order and approval system malfunctions."

The company apologized to users that were turned away "or abandoned the process in frustration" and hopes that users "will try again or visit an Apple or carrier store once the iPhone 4 is in stock."

It appears that problems weren't limited to AT&T and the US. SoftBank Mobile Corp. saw users lining up for several hours to attempt to reserve their phone and servers crashed in Tokyo too, according to the Associated Press.

Now, this is a prime use case for cloud computing. Cloud computing excels at taking some risk out of the infrastructure requirements surrounding the launch of a new product.

You have this new product, see, that is going to revolutionize the world. If it's popular, perhaps really, really popular, like Apple's iPhone 4, then you want to be able to scale up your infrastructure to handle the order volume. If users can't order the product when they want to, you risk either losing or greatly delaying the sale until the user can find the time to order it again. In other words, demand rebuffed is demand that runs the risk of never materializing again. That's probably less of an issue with iPhones, but it's a very real issue with time-bound purchases such as concert tickets or Christmas presents; if you can't take the order during a critical window, the demand moves elsewhere and disappears.

On the other hand, you don't want to risk buying a lot of infrastructure. What if your product is a bust and nobody cares? You don't want to design for the best case because the best case will only happen rarely.  Cloud computing insulates you from this risk. If you architect your software correctly, using a stateless architecture, you can scale up as required to meet unforeseen demand, or scale down if demand fails to materialize.

Most of the time, the demand for your new product will be somewhere between wildly popular and complete bust. That's okay. With cloud computing, you can dial in the exact resources that are required, as you measure what is happening in real time, so you can scale up if things go your way. You pay for what you need, so you never over buy if they don't.

Maybe Apple, AT&T, and Softbank should have used the cloud.

Eric Knorr asks an interesting question over at InfoWorld: Will Google buy Salesforce next?

It's an interesting thought. Eric's analysis is that if Google really wants to make any headway in the enterprise applications space, it better buy its way into the market. Google Docs has seen limited uptake, but Salesforce is used by literally thousands of enterprises, large and small. If Google really wants to go after the enterprise, it would be easier to use its extensive market capitalization to buy Salesforce and then build on that to create a robust enterprise SaaS / PaaS play.

I think Eric's question is more interesting in the large. That is, rather than looking at this from a "What's the best strategy for Google?" point of view, let's look at it from the "Who will be the technology consolidator for cloud applications?" point of view.

In past technology waves, a large company has emerged as the consolidator of technology, typically by acquiring a host of smaller companies. In the PC world, this was largely Microsoft. Cisco did this well in the networking and communications space. IBM did so for high-end enterprise computing, and Oracle has recently done something similar for high-end enterprise software.

So, the question is, given the new world of Agile IT, clouds, and SaaS, who will be the new technology consolidator? Google is certainly a reasonable candidate. They know how to build cloud-native applications at scale and they have the market capitalization to buy their way into anything the want. As Eric points out, at $152B market cap, Google can swallow Salesforce ($10.4B market cap) without so much as a burp. What Google has in technical acumen, it lacks in enterprise savvy, and it's reasonable to import that DNA via acquisition rather than trying to build it organically.

Cloud computing and networking are inextricably linked. Without high speed wide-area networks, public cloud computing would not be possible. The folks at Sun Microsystems were never more right than today: the network really is the computer when it comes to cloud computing. But while cloud computing is enabled by high-speed networks, cloud computing will also begin to force changes on the network as they evolve together. Here are five ways that cloud computing will change the network in the coming years:

1. Cloud computing will put pressure on network bandwidth, particularly in far-away geographies that have traditionally not had the best connectivity. Simply, more resources located in remote locations means more bandwidth required to deliver the bits. Running a workload in the cloud is only useful if you can transport the require data set to the computation and the result back to the user. That simply translates into more raw bandwidth required. Interestingly, this bandwidth may be asymmetric in the opposite sense of traditional web browsing. The web was characterized by small requests and large downloads. The cloud will be characterized by large datasets being uploaded, with smaller result sets being downloaded.
2. Cloud computing accelerates the movement toward IPv6. It's estimated that the Internet will run out of free IPv4 addresses sometime in the fall of 2011. Technologies such as CIDR and NAT have been able to prolong the inevitable, giving us a reprieve of more than a decade from address exhaustion, but the time is rapidly approaching where you won't be able to get an IPv4 address -- they will all have been allocated previously to somebody else. The move to cloud is a big accelerator toward that, however. Previously, you only allocated an average of 1 IP address to each physical machine. With virtualization and cloud, you can now have tens of VMs running on a single piece of hardware. And because many of those VMs are running in clouds, they must be publicly accessible. This means you can't use private addresses with NAT.
3. Firewalls have to get a lot smarter. Previously, most enterprises subscribed to the "egg model" of network security -- crunchy on the outside, soft and gooey on the inside. The fundamental assumption was that you were trying to protect yourself from the "bad guys" on the outside and everybody on the inside was considered a "good guy." With cloud, however, the model is under attack. What does "inside" mean in a cloud environment? Do you trust your cloud provider? If they aren't exactly a good guy, do you treat them like a bad guy?
4. Networking gear will stratify into two fundamental types: ASIC-based low-level switches and software-based high-touch processing. In the past, we tended to think of networking devices as always being purpose-built hardware systems. That's true for some devices. Low-level switching hardware, for instance, is all built around high-speed ASICs. The ASICs are fast, but relatively dumb. That is, they perform one or two simple jobs, but they do them very quickly. High level packet processing has almost always been done in software, albeit software running on purpose-built hardware. Whereas the algorithms that govern low-level switching are largely settled and therefore unlikely to change moving forward, the algorithms that govern high-level packet processing are constantly in flux (think about the move to IPv6 and smarter firewalls, mentioned previously). Because of this, it's almost impossible to embed them in hardware as they would be obsolete in a couple of years. Everybody wants to buy a system and then keep it current with a software upgrade. This phenomenon wasn't directly tied to the adoption of cloud computing, but with cloud computing you'll see it accelerating. There are going to be a lot of changes to the network and so you're going to see massive amounts of network upgrades (both topologies as well as devices) to accommodate the change.
5. High-level network packet processing goes virtual. Once you admit that high-level packet processing is all about software, you can then ask yourself, "In a cloud environment, where is the best place to run that processing?" It turns out that embedding the processing inside an x86 virtual machine is very handy. You are now able to run your VPN code inside your cloud provider and can provide an overlay routed network to connect your cloud-based VMs into your data center network. The first steps in this direction have already occurred with products like Vyatta. Expect it to accelerate.

It's going to be interesting to see cloud computing and the network evolve over the next few years. There is a very close relationship between them and innovations on one side will force innovations on the other side.