Interview: Service Availability Forum

OSM: What is the argument for taking high availability into account for the early stages of one’s design?

Dr. Naseem: Often, high availability is an afterthought, especially with small equipment manufacturers where time to market takes precedence over many other concerns. Our experience has been that in such situations, high availability does not become an area of focus until the end customer, the service provider, starts to demand it. Consequently when this functionality has to be bolted onto an already built system, it is too costly, it takes time and it’s difficult to maintain.

So our view is that system developers are better advised if they take high availability into account at the early design stages rather than waiting until later when it becomes too costly and cumbersome to do so.

OSM: Are those early opportunities hard to come by?

Dr. Naseem: Historically, large equipment manufacturers have had to implement such functionality in-house using expertise and resources that they have developed over many years. They had to do that for the most part because of lack of commercially available software that met their requirements. Moreover, prior to the SA Forum, there was no open standards effort specifically addressing high availability middleware. All of that is changing now, albeit slowly. Tier 1 telecom equipment manufacturers are taking a serious look at open standards-based high availability middleware. I see that change not only in telecom, but also in other industries such as aerospace and defense. The story with smaller players, Tier 2 and Tier 3, is different, however. They often don’t have the know-how, the resources, or the time to implement high availability functionality in-house. It is often not a part of their key differentiation or directly related to their secret sauce.

Timing is the key here. As long as the design teams recognize the need for such functionality early on, they can evaluate their alternatives and appropriately incorporate commercially available middleware solutions in the design stages. When the temptation to get the first release to market ASAP is high, sometimes high availability becomes a casualty. And the team is faced with having to retrofit this functionality in the next release, which as I mentioned earlier becomes costly and hard to maintain and evolve.

At the SA Forum, we are focusing on educating designers and developers through multiple means to impress upon them the importance of designing high availability into their products early on. We are doing this in multiple ways. We are conducting webinars, have launched a webcast series, and our members and officers are conducting face-to-face meetings with design teams to emphasize the importance of upfront thinking about this area. In addition, we continue to add education material on our Web site with a focus toward helping designers and developers of highly available systems.

OSM: What's a recent example of how a seasoned application developer influenced SA Forum and vice versa?

Dr. Naseem: I have two examples for you. One of the more recent interface specifications the SA Forum has added to its Application Interface Specification (AIS) suite is the Information Model Management (IMM) service. The platform providers and the middleware companies have had particular needs for such functionality and therefore had a view of the requirements of such a service. So based on that, the SA Forum developed an early version of the specification. Then a company whose product portfolio included a commercial version of the configuration management application looked at the specification and provided significant feedback on the IMM service. With close cooperation between the application developers from this company and the SA Forum Technical Work Group, the IMM service not only addresses the needs of the platform and middleware developers, but also includes functionality critical to configuration management applications.

The other example is from the aerospace and defense industry, where the SA Forum received specific and critical feedback from a large Navy prime on a couple of the SA Forum services including the Availability Management Framework, more popularly known as AMF. As a result we have begun to see significant traction of our specifications in the aerospace and defense market.

OSM: What were some of the specifics with regard to the effort that led to the IMM service incorporating functionality critical to configuration management applications?

Dr. Naseem: There are multiple companies that provide commercial software packages that implement northbound management interfaces such as CLI, HTTP, SNMP, and a more recent IETF standard called NETCONF. Two such companies have recently joined the SA Forum to take advantage of the relevant standardization efforts, especially the IMM service. The IMM allows these companies to use a standard way to interface with the underlying management and/or configuration information. Thus a single source of data in a network element can be accessed seamlessly through multiple northbound interfaces.

OSM: What went into the plan to launch the Service Availability Forum Application Webcast series and what has been the response thus far?

Dr. Naseem: In the last year the SA Forum reached significant milestones. The Hardware Platform Interface specification, more commonly known as HPI, is a commercial success. Most hardware platform providers either supply HPI implementation as part of their platforms or have declared plans to do so. Commercial and open source middleware implementations based on AIS are now available in the market. Several system developers are implementing applications based on the SA Forum specifications. Having reached a critical mass of specifications and implementations, we believe that we are now in a position to take specific steps to help accelerate the adoption by the application developers. The SA Forum Application Webcast Series is one of those steps that is focusing on helping to provide the latest information to the application developers on the state of the commercial off-the-shelf – or COTS – industry, the technical and business benefits of adopting the SA Forum interface specifications in particular and open standards-based application-ready platforms in general. We have done the first of the Application Webcast series, and we are getting ready to do the second one shortly. We are encouraged at the response to our first webcast to date.

We expect that we will receive specific and important feedback after subsequent webcasts as we dive into more details of our work and discuss the benefits of developing applications that utilize our specifications. In addition, through our Marketing Work Group, we are making a concerted effort to hold targeted and focused meetings with potential adopters – to have face-to-face discussions with them to help them understand how far along the SA Forum is with its specifications and education material. We also solicit their feedback on any gaps or concerns that may be causing them to delay adopting COTS building blocks.

Do you see consolidation coming for the industry groups in the COTS space, that is, the Communications Platforms Trade Association (CP-TA), the Linux Foundation, OpenSAF, PICMG, SCOPE Alliance and the Service Availability Forum?

Dr. Naseem: This question does come up – why do we need so many different groups?

Perhaps the work can be done by fewer groups. However, if we step back for a moment, and look at the individual functions these SIGs provide, it makes perfect sense why they exist. It is accepted in the industry that at a high level, a highly available deployment-ready platform has roughly four functional layers – the hardware, the operating system, the middleware, and the application. For a viable industry of COTS building blocks to exist and emerge, it is important that these layers are clearly delineated and are abstracted from each other using agreed upon interfaces. As such, PICMG addresses the hardware architecture requirements, the Linux Foundation publishes the Carrier Grade Linux requirements, and the SA Forum provides the middleware interface specifications. It is also important – for example in the telecom market – for someone to define a base telecom platform that meets the fundamental requirements of service providers, the end customers of such platforms. SCOPE Alliance does that. The alliance also acts as an advisory to other SIGs by publishing profiles of various functional layers in a base platform, and provides guidance through gap analyses. Finally, someone has to ensure that all of these COTS blocks interoperate and play together. That is where the CP-TA comes in. All of these functions are critical to enabling a working COTS industry.

So, it is not a case of creating artificial functional layers so we can justify the existence of particular SIGs; instead it is a response to industry reality.

In my personal view, I see some consolidation more likely than keeping the current arrangement. Much synergy and cooperation exists among these groups already, and one could argue that there is reason for even closer cooperation. There is a significant intersection of the membership across all of these organizations, and there is much cross-pollination, formal and informal, that occurs on a regular basis. The economic realities are forcing many of us to think about different ways of doing the standardization work. With less travel and fewer available resources, it does make sense for us to think of more effective ways of getting the SIGs’ business done.

Figure 1

OSM: The telecom application developer’s role has changed; how is the SA Forum responding?

Dr. Naseem: As I mentioned earlier, traditionally, large system developers have had to develop the entire vertical stack in-house – the hardware, the OS, the middleware services – and then write their applications, which in most cases are their differentiators and the primary revenue generators. The reality is that before they could get to developing differentiated services, they had to spend significant time and resources developing a platform.

Today, the reality is that you can go to the COTS industry and buy an application-ready platform based on AdvancedTCA, blade servers, etc. Various flavors of Linux are readily available, as are the COTS middleware packages. Each is available by multiple suppliers. So the telecom system developers no longer have to invest time and resources in developing a platform; instead, they can acquire it from their ecosystem, and focus their resources and expertise primarily on their core strengths, the revenue-generating applications and services.

The SA Forum has helped define the high availability software into a COTS category. We have more work to do. We will continue to enhance our specifications and add new useful services to our suites; and we are focusing on creating education material and reaching out to the systems developers to help them understand the benefits of adopting COTS middleware, as opposed to developing it in-house. We also emphasize to the system developers and the industry that it is now possible to acquire a pre-integrated and pre-tested application-ready platform that is based on COTS building blocks. This effectively addresses one of the objections we have often heard from system developers, large and small, that goes something like, “Look, I do not want to have to deal with integrating and testing disparate pieces and have to go to multiple suppliers for support. Give me a single neck to choke. I need to be able to hold one of you responsible for the entire integrated stack, so I can focus my resources on developing my differentiation.”

This gives those of us working on the various layers a strong reason to come together.

Dr. Asif Naseem is President of the Service Availability Forum. He is also President and Chief Operating Officer of GoAhead Software, Inc. in Seattle, Wash. He has more than 20 years of experience in the computer and communications industry. Dr. Naseem is a frequent speaker at industry and academia events and publishes regularly on computer and communication related. He has an M.S. in Electrical Engineering and a Ph.D. in Computer Engineering from Michigan State University.