Yet Another (ex-)VC Blog

One of the central tenets of cloud hosting (e.g. Amazon EC2) is that application owners no longer need to be concerned with the lower level underpinnings of the infrastructure.  Theoretically, the app owners can focus on their application code and then let the cloud provider handle the configuration and scaling of everything underneath (VM, server, network, storage).  This sounds great, but in practice, its just not the case, particularly in the enterprise world.

When I was running infrastructure operations at FOXSports.com, we used a managed services provider for a variety of our hosting needs.  They provided us certain services on a “cloud” basis, which meant that our servers could access these resources freely, but that we had very limited visibility into the infrastructure providing those services.  This made it very hard to debug issues related to this service since the MSP provided limited monitoring information for the systems providing the service.  I remember fighting very hard to get additional visibility into the service, and ultimately the MSP built some tools to support that need.

Fast forward to 2008…if I am an enterprise thinking about deploying anything remotely business critical to a cloud hosting provider, I will want to know (in gory detail) how the systems and networking supporting the infrastructure are configured and architected.  Why?  Because if something in the infrastructure breaks (and as we know, something always breaks), I am going to need to fix the issue as soon as possible.  With little visibility into the underlying infrastructure, I’m going to have a very hard time isolating and ultimately solving or working around the problem.

Where am I going with this?  For the larger clouds (like Amazon) there is a somewhat limited amount of information publicly available about how the underpinnings of their system works.  If I’m Amazon, for example, I probably have a great deal of know-how and trade secrets related to my cloud infrastructure that I’d like to protect.

The conundrum (I think) is that to see true success in the enterprise, the cloud providers will need to reveal a good deal of this information to potential customers in order to get them comfortable enough to move significant workloads and applications to their cloud.  Is it worth it for the cloud provider to give up some of that competitive advantage in exchange for more enterprise traction?

Related articles by Zemanta

• Big Day for Amazon EC2: Production, SLA, Windows, and 4 New Capabilities (Amazon Web Services Blog)
• Amazon’s cloud now less prone to failure
• Savvis jumps into the SaaS bandwagon
• VPN Cubed – Cloud is Ready for the Enterprise

I wanted to make all of the NYC-based entrepreneurs aware of a great program called InSITE. 

From their website:

InSITE is an entrepreneurial mentorship program that brings together
the best and brightest students from Columbia and NYU Business and Law
schools to support New York entrepreneurs in the development of their
businesses and their pursuit of venture capital and angel investments. 
InSITE’s mission is to accelerate technology start-ups through their
early-stage development, transitioning them from their seed stage into
being venture-funded companies.

A bunch of business school classmates of mine are involved in the program and I from what I have heard and seen it provides a great value for startups who need help on the business/fundraising side of things but don’t have the dollars to hire help.