Digital Ribbon CEO Erik Weaver discusses his company’s vision to create a pure exchange for computing resources, as well as the fine points of monetizing computing resources, turning a profit in the utility computing space, and what consumer applications might become the next killer apps.

—

GRIDtoday: First, what is Digital Ribbon? What kind of service do you provide to customers? Do you host applications, or just offer computing?

ERIK WEAVER: Digital Ribbon Inc. (DRI) is an aggregator of computation resources representing over 10 million monthly core hours; we are the foundation of an early stage exchange for computational resources. Our primary deliverables are computational resources (CR), which consist of computing power, memory, storage, security and bandwidth in flexible volumes.

DRI’s vision is to develop into a pure exchange for CR, wherein clients can both list resources and buy resources in a secure standardized environment globally. Our current practices leverage partner companies’ resources through a business-to-business model called cogeneration, which sets us apart from EC2 and Network.com. Another variance is each contract allots a predefined amount of time for consulting at no additional charge to ensure a seamless transition to the resource.

Digital Ribbon’s clients are very concerned about the nature of the project running on their systems. We do not typically host applications, but we have early on explored hosted products such as Maxwell Render, Blender and Callminer. Hosting applications moves into the next evolution toward products or end-user consumables. Our primary focus is the platform that delivers raw resources that others might use to manufacturer secure consumable products.

Have you ever read “Empires of Light” by Jill Jonnes? One of the fundamental epiphanies or transformations in electricity was the building of the Niagara Falls electrical plant. For the first time in history, vast amounts of electricity were available at affordable rates in varying quantities that could be accessed at a distance. Out of this revolution emerged companies such as Alcoa. The electricity allowed them to run blast furnaces at temperatures and costs that made aluminum cost effective to produce. This mirrors the place in history at which computational resources currently are. Making vast quantities available on demand while leveraging economies of scale to lower cost opens the door to a whole new generation of products once unattainable.

Gt: From where do DRI’s resources come? How do you guarantee service levels and availability?

WEAVER: Our resources come from partner companies. Without getting too elaborate, we use a cogeneration model to leverage a varying list of for-profit and not-for-profit organizations looking to maximize system resources return. Basically, we allow any group to register their resource, then evaluate it for output, architecture, bandwidth and SLA compliance. After comprehension of the resource, we attempt to best marry it to potential contracts.

As for the question of SLAs, each resource has a varying service level agreement predefined. There are penalties built into the contracts for failure to meet SLA agreements. Up to this point, we have yet to experience a failure to meet standards, however the bulk of our current clients have mid-level SLAs, not “99.9 percent” contracts. One of our very first jobs had a lightning strike on the facility while running a job, which knocked power out for six hours.

DRI was originally formed in 2000 with the intent of building clusters and selling time on the systems as additional revenue stream. Our change came in 2003 when an intern forced to read the latest Globus book pointed out in his presentation the concept of service requestor, service provider and a service registry to handle such transactions. At that point, we had datacenters and clusters, and we realized this was not the model to reach our goal of an exchange for computational resources, so we relinquished our hard resources.

Gt: How flexible is DRI’s resource pool? Can you provide different products or technologies depending on a user’s needs?

WEAVER: Our model of leveraging a cogeneration model has opened the door to a plethora of varying resources, which we could have never supported in a traditional datacenter model. Our resources cover almost all major manufacturers, architectures, processors, interconnects, bandwidth/connections, storage volumes and operating systems. DRI’s total available capacity at this point is 329,760 daily core hours or 10,030,200 average monthly core hours.

We are also developing partners that build out resources for large contracts. One example of this is a job we are bidding in which we would deliver 500,000-plus daily core hours across a grid of resources. Other areas we are exploring are partnerships with companies such as Panasas, wherein clients could see the benefits of their technology by testing their technologies on large-scale systems.

Gt: How is pricing handled? Is it a flat rate? Pay per use? Some other model?

WEAVER: Traditionally, we deliver a set number of computational hours over a predefined timeline. We also define storage, bandwidth, resources definitions, max number of cores and consulting hours. Any overages have predefined rates, very much like a cellular contract.

For example: a “peak contract” may have 10,000 core hours with a max capacity of 400 cores, 20 hours of consulting, OC3 connection and TB of data backup.

Gt: How do you determine the cost of computing resources? Is there a strategy around monetizing something as seemingly nebulous as computing?

WEAVER: This is a question I have seen a lot: “How do we price this?” I believe someone developing hard resources must first understand “the bottom,” or what does the electricity cost to maintain the system and facility housing it. We call this the bottom because you must know the lowest number you can possibly sell your resources for, beyond that obsolesce curve for the life of the fixed asset and all the other usual suspects, like support and maintenance. Lucky for us, our business model avoids all the tough questions — we immediately understand the cost and resources available, thus creating transparency in the market. This transparency is a critical step in building a market for and monetizing CR.

We are very involved in the development of standardization and monetization of CR; this is at the core of what we do. In this effort, I would like to first clear up a few misconceptions:

• Fallacy No. 1: “All computing power is equal.” A few years back, I was speaking with someone from EC2 and they made the statement, “We are going to kill Sun with our rates of .15 an hour.” I proceeded to explain that 1.75 Ghz processors at .15 cent a CPU dose not equate to dual-core 3 Ghz with 2GB of RAM per processor and high-speed interconnects. The volume of processing each system yields in an hour greatly varies, and the additional RAM adds a tangible value.

• Fallacy No. 2: “This is all about CPU power.” Most current contracts are sold by CPU hour, with a few specialized groups selling by the MHz hour. This is not an accurate view of consumption and demand and the market matrix. A more accurate term is computational resources. Computational resources refer to several aspects important to a consumer. Bandwidth, bemory, disk storage and network interconnects are as important as capacity, peak yield, processor type (64 bit vs. 32.) and availability. CR is the commodity of the future.

• Fallacy No. 3: “The commodity solution will be identical to current electrical kilowatt-hours.” The development of the market will be a little closer to grain markets. Kilowatt-hours does not compare to a unit of CR due to the number of variables represented by CR. For example, hard red spring wheat is traded in grain futures, as opposed to a kilowatt-hour-type model. The wheat market has multiple adjectives to define the deliverable product, and the CR market also has very critical distinct descriptions in deliverables.

Gt: I understand you’re working on some standards around monetization? Can you explain those efforts?

WEAVER: We are currently looking into defining “petaflop” as our kilowatt. In defining a standard, we have chosen to take the path toward volume/output, utilizing Linpack as a yardstick that gauges the yield of the system as a whole.

Please understand, the creation of such a standard is still nascent and requires imput and acceptance from many. As such, we are open to productive feedback. As for our effort for acceptance, we are talking with many leaders in the community and seeking their opinion. We are also moving toward writing our contracts in both core hours and petaflop deliverables.

Gt: What kinds of benefits do your suppliers experience? Why would an organization want to sell resources?

WEAVER: The benefits are maximization of fixed resources. Now the IT department is a revenue source and not just an expense. This is a very powerful shift in organizational dynamics.

Gt: How does DRI’s service differ from other high-performance utility services, such as Sun’s Network.com, IBM’s Deep Computing On Demand, etc.?

WEAVER: Each of these services has its own unique market segment and a solid place in its focused field. One of the biggest differences is our ability deliver across such a wide variety of solutions and resources. We also have low overhead and a grassroots growth that snowballs as user participation increases. As for our unique market segment, having a Windows cluster solution has been very beneficial, as has been our ability to deliver large-volume, low-cost bulk contracts.

EC2 was originally developed as an evolved Web-hosting platform and has evolved into a more robust cloud solution. Network.com has taken the products route, which offers greater profitability. IBM’s solution is designed around secure lock-box volume processing. Again, each is succeeding in their market segment, helping bring new users to this type of solution.

Gt: In general, how viable is the utility model for actually turning a profit? What does a utility service provider need in order to be successful?

WEAVER: I personally believe Sun could be turning a profit now, if they are tightly managing their expenses. Now it’s probably not a large profit, but the industry is rapidly growing and they have positioned themselves well. I think anyone building and maintaining clusters will have a challenging time at a for-profit business without products. However, most groups we work with that have supercomputers own them, with other primary objectives for the systems. As for my advice: If you are going to be successful, you must understand costs, especially operational expenses such as electricity, be able to understand vacillations in consumption, and have consumable end-user products.

Gt: How many users does DRI currently have, and what kinds of applications are they running?

WEAVER: We currently have about a dozen suppliers of varying size. We have seen contracts and bids in a wide variety of markets, including bioinformatics, oil and gas, rendering, testing, video gaming, and underpinning others’ resources. One of our most recent successes was simulating 120,000 concurrent users to stress test Quazal’s online gaming engine for a very popular game involving a guitar.

Gt: What industries or what types of applications are ideal for a service like DRI? Are there any up-and-coming use cases that seem exciting in terms of being the next “killer app” for high-performance utility computing?

WEAVER: Our biggest opportunities are in niche fields, bulk processing and creating market stability. Big opportunities present themselves in bioinformatics, but only as proof-of-concept work; larger-scale data mining, including voice to data processing; and underpinning grids or other larger resources with vacillating demands. We hope to eventually be supplying the resources to EC2, Sun and IBM as they realize our ability to mitigate their spikes in consumption.

As for upcoming killer apps, on the product side we have been preaching rendering and rendering processing for a while — products such as Maxwell Render, Blender and eventually Maya Mental Ray. I also believe a new generation of appliances will evolve that the general public will find delightful. Who could have imagined the TV back in 1901? It will probably be something the experts deem trivial, such as photo manipulation, 3-D rendering of traditional video recordings, even Gotcha for camera phones, wherein facial recognition software processed on supercomputers is used for fraternity entertainment. As barriers to the market shrink, new superfluous applications are open pursuit.