101 Thoughts about the "Cloud Foundry" Announcement
Who knows if I'll make it all the way to 101, but my head's been spinning with all the angles, so here goes....
- Their Hypervisor is always under pricing pressure from free alternatives (Hyper-V, Xen, KVM), their middleware is now open-source and SP's probably aren't sure if they are vendor or competitor. Will be interesting to see what their revenue models looks like long-term.
- Cloud Foundry creates a PaaS model that isn't dependent on VMware VMs, but does attack their largest competitors, so an interesting "creative disruption" strategy. This always takes courage from leadership. Paul Maritz is uber-smart and been in the big boy games before, so you have to expect he has a grand plan for all of this.
- It's not clear if "for fee" Cloud Foundry from VMware is attached to Mozy's service. Mozy just raised prices. If they are connected, it will be interesting to see if the "for fee" service can remain competitive at scale...or if that's really part of their strategy?
- What does Cloud Foundry mean for existing VM Admins?
- How will the 1000s of VMware channel partners adapt to this new model? Do they have the skills to understand this and sell this? Moving from infrastructure to applications is not a simple context switch for most people.
- How will Cloud Providers (SPs hosting the apps) react to the portability capabilities? Will we see minimal friction (eg. number portability), or subtle changes to their services (ToS, billing, network/security infrastructure) that reduce that flexibility?
- Several people are already connecting the open-source dots of CloudFoundry and OpenStack, so what does this ultimately do to vCloud Director (at SP or between ENT & SP)?
- Does VMware have the deep pockets to support the developer community enough to make it dominant (like Google and Microsoft did before them)? Is VM revenue enough of a cash cow to sustain
- PaaS can be deployed on almost any infrastructure - silo of whatever, structured IaaS, etc. - but the mobility element means that there will need to be some structure or way to describe the infrastructure needed. Some form of Network as a Service or Network-level APIs.
- Networks underlying these PaaS environments will need to be provisioned via an automated mechanism, and preferably be virtualized at multiple levels (whether for VMs or bare-metal deployments).
- Just as the PaaS frameworks allow applications to be described (n-tiers, etc.), so too will there need to be a way to describe the underlying infrastructure (network segments, addresses, load-balancing, storage, etc.) so it can be requested as the application moves from cloud to cloud.
- How does the mobility effect storage for the application? How does the storage get bundled for movement (as a LUN, as a file-system, something else)? Does it mandate IP-based storage?
- Do we expect SPs or ENT to continue to build intelligence into the infrastructure (security, isolation, availability) or does the application eventually become the network?
- While some people (hint, hint @reillyusa) have called this the death of IT infrastructure intelligence, I actually think it just adds a new level of complexity into those roles. They now have fixed (legacy), mobile (VMs) and hyper-mobile (CloudFoundry) applications and all the associated issues that go along with them (security, compliance, auditing, assurance, etc.).
- Maybe I'm wrong about this, but I would have thought that developers went to a certain PaaS platform (Google App Engine, Salesforce, Azure, etc.) because they either valued the functionality around the platform (community, linkage to other properties within that platform, etc.) or they wanted to reuse existing applications (eg. Azure, .NET).
- Being the everything to everyone and open-sourced (bring your own business model) - doesn't that mean it doesn't necessarily doing anything outstanding unless it gets forked into projects that have narrower focus? Seems like the competition may have an advantage of focus.
- Let's suppose that Cloud Foundry becomes the dominant player, similar to Android's market-share vs. iPhone. Which existing player becomes the iPhone platform, or RIM?
- Does this lead to a new round of PaaS/SaaS consolidation so that the competitors can offer a broader "market" of in-house services to developers (sales, social, data mining, collaboration, etc.)
- Does this just increase the future value of companies like RightScale and Enstratus that build tools to manage multiple cloud environments?
- I wonder how long it will take before the Cloud Foundry App-Store opens for business and who will be the company taking 30% (ala the iTunes App Store). Is this VMware, somehow integrated with their "Project Horizon"?
- Beyond VMware, who is the first company to create solutions around this for the Enterprise (private/hybrid-cloud), or does the primary focus remain with ISVs and public-cloud deployments?
- Is there a clearinghouse or brokerage business to be build around helping apps move from Cloud to Cloud, or to Federate them?
- Has the "Cloud Foundry for Dummies" book been written yet?
- How much will we see applications moving from one cloud to another, or is the portability and open-source aspect just an insurance policy for running it on an existing IaaS/PaaS environment that may not be able to create enough cross-linkage, traffic or overall value?
- Anything that creates the ability for developers to create portability in an application is almost always a good thing. [NOTE: Can't think of when it wouldn't be a good thing...]
- One of the goals of Cloud Computing is to hide the "where did it come from" from the user. This seems to be a step in the right direction, whether you're an Enterprise, Web Company or a ISV/iPhone/Android developer.
- There are pros and cons to this being released as an open-source project. It obviously speeds up the pace of innovation, but equally speeds the race to $0 for many aspects around this business. It all depends on which side of that $0 you're on.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)