If I were to play buzzword bingo today I'd really like to have the words Cloud, Fabric, OpenFlow, API, and Stack lined up - I would be sure to win in any vendor briefing in the first 42 seconds of the meeting. Let's face it, even if a vendor has products that were designed for wiring closets or branch routing they are all trying to find some way of hitching them to the Cloud train.
My fundamental question is - does that work? Can I take products and technology that had design points, price structures, and power draw that were aimed squarely at large enterprises when they were built and conceived and repurpose them for the cloud market effectively enough that customers and providers are not impacted?
See, the challenge of this is that public cloud is one of the purest forms of IT. IT Operations is THE business of a public cloud, period. There is nothing else that can mask the sins of the architecture - failures/outages are gloriously public, CAPEX and OPEX of the architecture directly impact the bottom-line, and to paraphrase Steve Jobs, you can't mask bad IT decisions by selling more sugar water.
I have heard many people talk about 'The Cloud' (which the way they say it I feel must be capitalized) and one that struck me profoundly was a conversation I had with Randy Bias, CTO of Cloudscaling who stated quite directly, "You cannot build a profitable and competitively priced public cloud with enterprise technology, the vendor taxes are just too steep."
Randy also stated that clouds required new design patterns, ones based on commodity hardware, open source software, APIs for programmatic access, simple systems that horizontally scale, automation, and multi-tenancy. So I explored this a bit and realized cost came in several ways into these cloud deployments, some more tangible than others:
Asset Acquisition Cost - you, a public cloud provider has to buy gear. (Vendors like this of course and as cloud providers start taking on more and more small/medium business applications there can easily be some demand-side consolidation so its a crucial fight for the vendors affected.) The problem is that the vendors have to operate this gear for profit. So the less they pay, or the more cost effective gear they use, the more profitable they are.
I have seen some configurations cut the revenue potential of a public cloud in half by taking too much power, and then further reduce profitability by having per Socket/CPU taxes on software, grossly expensive networking gear chock full of features that add to the complexity of the network - yet aren't consistently manageable or capable of being automated, and have no programmatic APIs.
OPEX - operational expenses add up, and the one many people hone in on is power draw and maintenance contracts. I have seen many vendors looking at power draw as, "We are 30% less power than Competitor X, so we can save you money." I will contend this is probably a bass-ackwards way of looking at it for a cloud provider - its about compute density.
The 3MW data center therefore has a maximum income potential of $21,941,760 per month.
But this is where your mileage can really start to vary - every switch, router, load balancer, and firewall you put in reduces the number of servers you support. Every 350W you consume takes out $2560 per month of earnings potential.
Can the equipment that you are contemplating using be managed by your cloud management system - does it tie in and integrate? These costs can quickly surpass all others - if the system has local or remote APIs that are well defined, adhered to, and version controlled or pre-integrate with whatever cloud management software/framework you are using you are probably off to a good start. If the best available is a CLI and you are expected to write PERL and do some screen-scraping to provision VLANs and segments and add routing entries you may want to continue looking.
Common problems I have seen recently:
All of these are variations on a theme btw, many cloud management companies seemed to have started with the premise that they can bare-metal provision the servers and if they put nice UIs around it they can have a neat new service. They got things up and running, it worked great in one or two cabinets. Then they started to build out a bit - Then they ran into The Network. Many of them forgot that networks were designed the way they are for a reason, and many customers are not comfortable changing their networks wholesale, and almost never does a network exist that every port can talk to every other port at wirespeed, L2, with no hierarchy and supports thousands of ports. (I don't want to get into a debate about whether it can be built and which vendors support what : It's build-able but most existing networks are not set up that way.)
So, my summation from these stories, some spreadsheets I pulled together doing cost comparisons, and from what I have seen with many companies building public clouds is that if you use the 'Cloud in a Can' approach from vendors selling products that were designed and built for Enterprise customers you may be able to get it to work, but you will lose in the near-term:
But what have you all seen? Are there examples of profitable and growing public clouds that do not run on open-source software, cost-effective hardware, or have programmatic APIs and simple systems?
Douglas Gourlay is the vice president of marketing at Arista Networks - the leading developer of 10Gb Ethernet switching platforms. In this role Gourlay is responsible for the global marketing and product management for Arista. Arista has recently won the ClearChoice award by NetworkWorld for top 10Gb Ethernet data center switch, and Best of Interop: Infrastructure and overall Best of Interop for the Arista 7500.
Prior to joining Arista Networks Gourlay was the vice president of Cisco’s Data Center Solutions Group, where he defined and executed Cisco’s global marketing strategy for data center, virtualization, and cloud computing. This included the Nexus and Catalyst data center switches, application and server load-balancing, storage networking, blade switching, and wide-area application services product families. Under his leadership Cisco’s data center segment grew from a nascent business to over $5B in annual revenue.
Since 1998 Gourlay has led and contributed to numerous hardware, software, and systems architecture developments across Cisco. He has served as senior director of product management for the Nexus Family of data center switches, director of product management for the Catalyst 6500 Series of LAN switches, and led product management for Cisco’s Application Delivery product family. Gourlay has filed or holds more than 20 patents in networking technologies.
Prior to his work at Cisco, Gourlay was an industry consultant and served as a US Army Infantry Officer. Gourlay is an avid pilot and can often be found tinkering on his Cirrus at Palo Alto Airport.