451 Research: The Open Compute Project; open is one thing, interoperable is another

In IT parlance, “open” is often used synonymously with interoperable, but is that really end of story? In this special report presented below, 451 research director for networks, Peter Christy, reconsiders levels of success achieved by open initiatives such as the Open Compute Project in ensuring that compute components work together and that systems can support standard software. Ultimately, he argues that if the hyperscale web companies (HSPs) have the expertise required to internally test, design and integrate systems using components built by ODMs, this same know how is missing in the broader market – a gap that is currently filled by legacy system vendors, who provide testing, integration, etc..

Interestingly, Christy describes a resurgence of interest within the enterprise in HSP-developed advances, such as Rack Scale Systems, spearheaded by the IT department which is looking for the means to compete with service delivery provided by these same external cloud providers (HSPs). He also identifies hyperscale innovation as the key to unlocking the digital transformation that enterprises are now told is critical to business success. But how are proponents of open innovation squaring the circle, i.e. delivering integration through an open ecology that validates and integrates systems for the enterprise – absent in-house expertise and absent the additional fee for value charged by the established vendor community? Stay tuned, 451 Research promises a second intriguing report on OPC efforts. (ed.)


The Open Compute Project (OCP) was launched in 2011 with a goal of creating a commercial ecology and market for the components within ‘rack-scale’ system architectures, similar to those used by the hyperscale service providers, and by doing so extending the commercial benefits to a broader market. However, creating a commercial ecology has turned out to be more difficult than some of the early organizers anticipated. One important and not fully solved question is the process by which these components are designed and tested so that a customer can buy an OCP-based rack-scale system with a high degree of confidence that its components will interoperate and support standard software platforms. These challenges are the subject of this report.

The 451 Take

The emergence and growth of public cloud providers has been an important part of the ‘digitization’ of business that is forcing the transformation of enterprise IT. The largest of these cloud service providers operate at such a scale that they have been able to significantly redefine system architecture, including the creation of rack-scale systems that provide improved configuration flexibility and procurement agility, and therefore, improvements in operational flexibility and cost efficiency. What enables the hyperscale providers to do this – their ability to bypass the traditional IT suppliers and procure directly from the ODMs – turns out also to be a key inhibitor to bringing these systems to a broader market. The hyperscale providers have broad and deep expertise internally, and therefore don’t have to depend on the legacy system providers to design, integrate and test the systems. The broader enterprise market does not have comparable expertise and is unlikely to be able to hire comparable staff.

The still-unanswered question is how to fill that gap and provide adequate testing and integration, and do so in a way that retains the cost attractiveness and procurement agility of the architecture. This is one of a growing number of examples where replicating the human resources within the hyperscale providers turns out to be a key challenge in providing alternatives to the use of those hyperscale systems.

Context: hyperscale service providers and ODMs

Peter Christy, director, networking practice, 451 Research
Peter Christy, research director, networking practice, 451 Research

The OCP opportunity results directly from the emergence over the last decade of very-large-scale service providers (we’ll use the common term ‘hyperscale service providers’ or HSPs). These HSP offerings have transformed datacenter computing by providing on-demand, elastic services that have in turn transformed what is possible in terms of creating and operating SaaS solutions, and the agility and cost efficacy of application development broadly. The size and self-supporting nature of HSPs has allowed them to redefine how systems are built and operated and created a great deal of interest in how these advanced systems can be sold to enterprises as well.

The OCP was launched in 2011 when Facebook announced its intention to make public many of the details of its hyperscale datacenter hardware designs with the hope of creating a broader commercial ecology, enabling a larger set of enterprise and service provider IT users to benefit from the advances driven by the largest providers, and in doing so also providing commercial benefits to Facebook as well. The Platinum members of OCP are AT&T, Cumulus Networks, Deutsche Telekom, Ericsson, Facebook, Goldman Sachs, Google, Hyve Solutions (an integrator and Facebook supplier, part of SYNNEX), IBM, Intel, Nexius (a network technology and services company), Penguin Computing, QCT (part of Quanta Computing), Rackspace and StackVelocity (a cloud system integrator and services company).

One of the important elements of OCP is a new form of physical system architecture – rack-scale systems (RSS) – where the system elements that used to be integrated with server, storage and network appliances are made available without an enclosing box with separate power and cooling, and these new elements – system ‘trays’ – can be configured into a specific and customer-optimized ‘rack’ system.

The concept of OCP also builds on the transformation of high-tech manufacturing that has occurred over the last 10-20 years, and the rise to prominence of specialist manufacturing firms. Today, an enterprise or lower-tier service provider still buys integrated (engineered and tested) systems from the traditional system providers, whereas an HSP can buy similar system elements directly from ODMs and assemble those elements into larger rack systems themselves. The HSPs’ system configuration choices are not limited to the integrated systems an IT vendor chooses to market, nor must the HSP wait until a system vendor incorporates new technology (e.g., a new-generation CPU or SSD advance) into a complete system.

The hyperscale providers have large enough procurement volumes and adequate internal technical competence to bypass the traditional IT suppliers (e.g., Dell, Hewlett Packard Enterprise, IBM) and procure systems directly from the ODMs, customized to meet their specific requirements, rather than procuring from the legacy suppliers and having them subcontract with the ODMs for manufacturing. By buying directly from the ODMs, the hyperscale providers gain process agility and systems that are optimized for their needs. Buying directly from the ODMs also removes one layer of profit from the process, at the price of losing the engineering, system manufacturing, global logistics and service capabilities of the legacy suppliers, and making the customer responsible for the system design, component interoperability and software support that the legacy provider would otherwise provide. A key issue in enabling a commercial OCP ecology is determining who provides these testing and assurance services for the customers beyond the HSPs, which don’t have comparable internal resources to do it themselves.

Markets: Why enterprises and second- and third-tier service providers need advanced systems

HSPs have created on-demand service platforms that are driving innovation in IT by revolutionizing the speed with which new applications can be created and evolve, and the availability of such agile platforms have in turn created a need for internal IT systems to become more agile as well.

The largest drivers of enterprise IT today are often collectively described as the transformation to the digital enterprise in which operational and contextual data about the business is integrated, used in day-to-day operations, analyzed, and the problems and opportunities discovered in that analysis used to drive change in the business.

Operating a digital business requires an agile IT platform so that the business systems can evolve with the business. HSP service offerings like Amazon Web Services have proven to be excellent platforms for agile IT. As a result, enterprise IT spending is palpably moving to the use of SaaS offerings and on-demand infrastructure providers (e.g., AWS, Microsoft Azure, Google Cloud Platform), and by doing so shrinking the budget and scope of the internal IT organizations and services. In many organizations, the need for more agile IT is no longer up for debate, and the challenge faced by the internal IT organization is improving the agility of internal resources so that they can provide business gains comparable to what has been demonstrated using external on-demand services, or see still more of the spending move to external services. This in turn motivates interest in using HSP-developed advances, including RSS, as enterprise private systems as well, and motivates having a commercial OCP ecology.

The crux of the matter: innovation and expertise

The HSPs have built remarkable teams, initially out of necessity in order to go where ‘no one had gone before’ with operational systems of unprecedented scale. The existence of these teams has also enabled the redefinition of system architecture, and the incorporation of new technology at unprecedented rates, compounding the benefits of HSP services use further.

The HSPs are able to create their own system designs and incorporate technology advances directly rather than waiting for the innovation to flow thought the traditional supply chain, and as a result, HSP platforms absorb new technology and respond to market shifts much more rapidly than we are used to. These unique internal teams also enable new forms of organization and operations (DevOps) that enable rapid injection and evolution of software as well.

Although many other enterprises and service providers would like to follow the lead of the hyperscale providers and have private systems with comparable benefits, this issue of expertise keeps cropping up, and is central to the testing and certification issues discussed here. The hyperscale providers go after the best engineers, programmers and operational teams in the world, can afford to pay whatever it takes to hire them, and are very attractive places to work because of the teams you work with and the problems you work on. There is no way that the broad market can hire comparable staff (a few enterprises come close, including the largest financial service providers), so the question is whether and how what the hyperscale providers have developed and use can be adapted to work without comparable internal expertise? So far, there are no simple answers.

The testing and certification challenge

The emergence of hyperscale service providers and the shift of high-tech manufacturing broadly to a set of specialist manufacturing firms have led to a new form of system architecture at the rack scale, and this new architecture provides procurement flexibility and agility that creates clear value for those HSPs. The HSPs are able to do this because their internal teams include deep engineering and testing competence that traditional buyers depend on the system vendors to provide (independently of whether the vendor does internal manufacturing or uses outside subcontractors).

When OCP was first conceived, these problems weren’t understood as clearly as they are now, and are a clear impediment to the growth of that ecology. If the legacy IT supplier is no longer part of the procurement process, who provides the assurance that a specific configuration of parts, possibly from multiple hardware suppliers, possibly a new specific configuration with a new software platform, will work reliably for the customer? In part two of this report, we will examine the solution approaches that have been identified to date, and highlight their pros and cons to make a commercial ecology a reality.