Avoiding platform integration risks with SA Forum based middleware

Joe and Alan walk us through the role the Service Availability Forum (SA Forum) plays in both reducing risk and speeding up development time, citing an example in which an Enea customer cut R&D integration costs.

[Application Feature]

Avoiding platform integration risks with based middleware

Joe and Alan walk us through the role the (SA Forum) plays in both reducing risk and speeding up development time, citing an example in which an Enea customer cut R&D integration costs.

With our growing dependence on computer-based services for day-to-day activities, including smartphones for business and personal communication, online financial management, and web-based services and applications, demand for service availability has increased steadily over the past decade. And while service availability solutions have been integrated into traditional telecom networks for many years, a broader than ever before range of industries now experiences the consequences of service availability health.

Consider the recent outages to the social network Foursquare  and to Chase Bank’s online banking site. These outages affected a significant portion of the millions of users and generated negative media coverage for both companies.

The Service Availability Forum (SA Forum) is an organization enabling the creation and deployment of highly available, mission-critical services by promoting the development of an ecosystem and publishing a comprehensive set of open specifications for service availability middleware aimed at 99.999 percent uptime achievement.

For example, a start-up company developing a carrier-grade system for telecom service providers wanted to accelerate time-to-market in order to have a field-deployable product within 12 months of project kick-off. The customer needed a high-performance, scalable solution with a high degree of service availability to address system capacity requirements. One approach would have been for the start-up to create middleware. Instead, it turned to Enea, an SA Forum member company.

To develop a carrier-grade system for telecom service provider Enea’s customer needed to buy or build hardware, middleware, and applications and then integrate these three large pieces. The hardware platform needed to satisfy the product’s scalability and performance goals while providing a manageable set of hardware resources for a highly available system. As well, a set of services enabling the customer’s developers to write distributed highly available applications had to come from middleware. And the application developers would have to design and implement their applications around the middleware APIs and behaviors.

Standards-based middleware from Enea based on the SA Forum’s Application Interface Specification (AIS) and Hardware Platform Interface (HPI) specification were teamed with a standards-based hardware platform, making it possible for the customer to focus on its differentiating feature, the set of applications (Figure 1).

21
Figure 1: COTS hardware platform and middleware implementations make concentrating on features that will make the product stand out in the marketplace possible.
(Click graphic to zoom by 1.6x)

 

The product developed by the customer would eventually use many of the Enea middleware services, but developers limited the initial product demo to redundant applications managed by the Availability Management Framework, replication of critical application state via the checkpoint service, and visibility of the hardware resources through managed objects in the middleware implementation reflecting information. With the availability of pre-integrated COTS middleware and hardware platforms, the customer developed applications designed and implemented from the ground up to incorporate and scalability. This approach enabled more capable early demos and first generation product releases. More importantly, it also allowed a smoother transition from one product generation to the next by tackling these fundamental design points from the outset. One of the largest time and risk challenges is “adding” high availability and scalability to a product. Figure 2 shows the relevant subset of the customer’s system.

22
Figure 2: Ease of progressing to the next product generation is aided by the ability to address key design points from the get go.
(Click graphic to zoom by 1.9x)

 

A typical product that addresses high availability and scalability from the hardware up through the application software requires a set of services that is either implemented within the applications or abstracted into a middleware layer. Adopting this procedure results in a software development cycle burdened not only by the time to design the architecture of the middleware, but also by the time it takes to craft the applications (Figure 3). The application architecture and implementation depends on the middleware architecture and implementation. Lastly, there is an integration exercise between the applications and the middleware and hardware platform. Newly designed middleware typically requires iterations of design, implementation, and integration as the middleware architecture matures.

23
Figure 3: A software development cycle that includes time to design the architecture of the middleware as well as the applications.
(Click graphic to zoom by 1.9x)

 

Early access has its advantages

The SA Forum AIS and HPI provide a mature middleware architecture and APIs. Over the last decade, a diverse number of SA Forum members have put these specifications through several generations of review. Also, the specifications incorporate feedback from multiple middleware implementers (including commercial vendors), as well as feedback and validation by application developers and system architects. A middleware implementation based on the AIS architecture is not a moving target, so there is no anticipated middleware redesign iteration. Having access to the middleware architecture at the beginning of the application design cycle allows the developers to proceed with clear guidance on what functionality they will use to build scalable, highly available applications. This early access shortens the design cycle, as shown in Figure 4. Having mature middleware APIs accelerates the implementation cycle. The integration with a pre-integrated, off-the-shelf middleware/hardware platform can begin during the application implementation phase.

24
Figure 4: Implementation cycles become smaller with the availability of mature middleware APIs.
(Click graphic to zoom by 1.9x)


Additional time can be saved using middleware and hardware that support the HPI interface (Figure 5). Traditionally middleware is either tied to a specific hardware platform or includes a hardware porting layer that needs to be implemented by the system integrator (often the customer). In the former case, the system integrator has to choose a particular hardware/middleware combination, which may require undesirable compromises. In the latter case, the system integrator must implement the hardware porting layer, which takes weeks to months. With hardware vendors that support an available HPI implementation (either from the hardware vendor, a third party, or open source like ) and middleware vendors that access hardware resources and events through the HPI interface, the integration can be completed in a matter of hours to days.

25
Figure 5: Using middleware and hardware that support the HPI interface cuts development time.
(Click graphic to zoom by 1.7x)

 

Risk shrinks for many of the same reasons that development time accelerates. The of the middleware architecture and interfaces reduces the likelihood of shortsighted system architecture and/or redesign due to API redesign/refactoring. Using the HPI to integrate the middleware and the hardware affords greater flexibility and reduces risk. The ability to manage vendor selection can help when a hardware or middleware vendor is no longer viable for business reasons or where changes in requirements make another vendor preferable.

Time to hone competitiveness

Out of the initial three-month demo preparation period, Enea’s customer spent one to two weeks in middleware training activities and another week near the end of the period integrating onto the target hardware. The rest of the time was spent developing the secret sauce applications that differentiate the product from its would-be competitors.

This use of the customer’s time resulted in a smooth integration, leading to a solution that met or exceeded all schedule goals. The demo was ready in three months, and the selection of SA Forum-based middleware eliminated major platform integration risks and reduced R&D integration costs by a factor of two.

At a higher level, service availability in general is becoming increasingly significant in the business world, as customers now expect that services will work continuously. The SA Forum is currently educating a broader audience on the benefits of service availability and is sharing practical information about SA Forum specifications and implementations in new ways. Whether a service provider needs more information on service availability when negotiating a Service Level Agreement (SLA) or a business manager is looking to differentiate a new online application, the SA Forum is striving to make this wide range of information easily accessible.

No upside to downtime

The Service Availability Forum is focused on building the awareness of service availability solutions and has launched a new cartoon series, “Walter’s Moments,” to demonstrate the need for service availability in daily life (Figure 6, courtesy of SA Forum). Like the Foursquare users and Chase customers who recently faced outages, Walter learns the costs of using services that do not have a very high level of availability.

26
Figure 6: A new cartoon series and ongoing webcasts are part of the SA Forum education efforts.
(Click graphic to zoom by 1.9x)
 

In addition to the newly launched cartoon series, the SA Forum is pleased to announce the latest installment in our well-received Application Webcast Series, “An Introduction to Software Management Framework.” This service is one of the most recent specifications developed by the Forum and addresses what is considered a critical requirement for service availability – seamless upgrade/downgrade of software and hardware components.

It also explores Software Management Framework (SMF) key features and benefits as well as the first real-world implementation from the Open Service Availability Framework (OpenSAF) open source project. With upgrades to software and hardware commonplace in most systems, the (SMF)  is an important component in the comprehensive set of service availability specifications. Future webcast topics include an introduction to the HPI specification and a high-level overview of the SEC Framework, a compelling security feature for application developers.

With the measurable benefits offered by SA Forum specifications, including enabling an application development ecosystem, reduction of cost and risk, and faster time to market, we expect continued momentum in deployments based on SA Forum specifications. For more information, please visit http://saforum.org.

If you are interested in sharing any of your experiences with downtime or ideas for future cartoon installments, please visit the Service Availability Professionals LinkedIn group and post a comment.

Joe Kidder is a member of the Service Availability Forum Technical Working Group. He is the Chief Architect for HA Middleware at Enea, based in Nashua, New Hampshire. Joe has 25 years of experience in the computing and networking industry, with a focus on systems and software engineering. He received his M.S. in Electrical and Computer Engineering at the University of Wisconsin, Madison.

Dr. Alan Meyer is Marketing Chair of the Service Availability Forum. He is also the Director of Telecom Platform Software at HP, based in Fort Collins, Colorado. Alan has more than 25 years of experience in the computing industry, with a focus on communications and open source software. He received his M.S. and Ph.D. in Computer Science from Washington State University.

SA Forum

www.saforum.org