Skip the navigation

Sabre Flies to Open Systems

The air-travel software company has reinvented its 25-year-old mainframe applications with modern languages and commodity hardware.

By Gary Anthes
May 31, 2004 12:00 PM ET

Computerworld - Sabre Holdings Corp., the air-travel software company, has an ambitious set of objectives for the remake of its "shopping engine," a 25-year-old mainframe application with 10 million lines of assembler code that processes more transactions per second than the New York Stock Exchange.


In order to rein in escalating processing costs and offer customers more options, Sabre is completely overhauling the software used by airlines, travel agents and passengers to find and book flights. In stages, Sabre is replacing its old mainframe assembler code with modern languages running on cheap commodity computers and open systems, including Linux.


Sabre's Global Distribution System, which used to be called the Customer Reservation System, has roots all the way back to 1960. It consists of three air-travel subsystems, one each for shopping (which includes pricing), booking and fulfillment (day-of-travel operations). The Air Travel Shopping Engine, which accounts for more than 50% of Sabre's total data processing load, handles the shopping and pricing. If you're on Travelocity.com (a Sabre company) surfing for the best schedules and fares between New York and Washington, you're using ATSE.


Sabre likens its big system project to driving through a snowstorm. "Some people want to go 70 mph and don't worry about the ditch," says Craig Murphy, chief technology officer at Sabre in Southlake, Texas. "Then there are those who go 2 mph, drive on the shoulder and white-knuckle the steering wheel. But what we want to do is go 25 mph through the snow inexorably toward our destination, which is more capability, open systems, a services architecture, distributed components and far lower cost."


Forces for Change


Three forces hugely increased the processing demands on Sabre systems over the years. After airfares were deregulated in 1979, travel agents began shopping based on both price and schedules, not just schedules. Then, in the late 1980s, travel agents began using PC-based automated search tools that continuously scanned Sabre databases for the lowest fares. Finally, in the mid-1990s, consumers on the Internet joined travel professionals in shopping for flights. Sabre's processing economics took an ugly turn as the "look-to-book" ratio soared. Looking for the best schedules and fares generates data-processing costs but no revenue; it isn't until someone books a flight that anyone makes money.












Craig Murphy, CTO at Sabre
Craig Murphy, CTO at Sabre

Airlines added to the pressure by asking for myriad new options and features, many of which could be added to the old assembler code only with the greatest of difficulty, if at all. Adding a new rule, such as a discount for a Saturday night stay, could cost $1 million, Murphy says. Armed with a $200 million research and development budget, the $2 billion company relentlessly tuned its systems, but processing costs continued to climb. Sabre's IBM Transaction Processing Facility (TPF) mainframe environment in Tulsa, Okla., went from 1,000 MIPS in 1995 to more than 10,000 MIPS in 2001.


To the Rescue


But, Murphy says, while the look-to-book ratio skyrocketed and pricing and scheduling options proliferated, three technological forces came to the rescue: Moore's Law, open systems and ubiquitous standards. Moore's Law—which states that the amount of computing power available per dollar doubles every 18-24 months—enabled Sabre to assemble a scalable farm of powerful servers built around cheap commodity processors and huge memories. Open systems enabled Sabre to move from the proprietary and expensive TPF environment first to Unix and now to Linux. And standards such as Common Object Request Broker Architecture, the Lightweight Directory Access Protocol and Java enabled Sabre to move the shopping engine to a distributed and extremely flexible services architecture.


Sabre is now well past the midpoint of its four-year migration project. Simple North American flights are on ATSE, but complex trip types and international flights aren't yet. Sabre will move the booking and fulfillment functions to a similar architecture in the future.


Murphy says the cost of the project will exceed $100 million, but he won't be more specific. Results so far have been encouraging. "We sold the project on the basis of reducing total cost of ownership by 40%," he says, "I actually think we'll surpass that. Running a query—Dallas to Chicago, say—on the new system is about 80% cheaper."


And, he says, developers are getting 100% productivity gains because they are working in higher-level languages—Java and C++—and because the application architecture is so much easier to debug, change and enhance than the old mainframe assembler code.


Finally, airlines are getting the ability to put in new options and features quickly and cheaply. Last year, Sabre announced SabreSonic, a suite of services that enable airlines to tap into Sabre systems and databases in order to offer passengers new services, such as streamlined airport check-in.


"Changes are much easier to do, and much less expensive," says Gianni Marostica, president of Sabre Airline Solutions. "This allows us to implement things airlines think of on the fly."


Sabre's new ATSE architecture is based on the processing characteristics and reliability requirements of its major functions, with three modules connected by a LAN. A front-end rules engine on 16 two-way Hewlett-Packard Co. Linux servers acts as a master controller for the system, coordinating services and I/O across the LAN.


The master database, or "database of record," sits on 17 fault-tolerant 16-CPU HP NonStop S86000 servers. That's where pricing occurs. Each of the 272 processors has 4GB of memory and runs the NonStop Kernel operating system under the Unix-like Open Systems Services layer. Data from the NonStop boxes is replicated continuously by GoldenGate Software Inc.'s data synchronization software to MySQL AB databases on a server farm containing 45 four-way HP rx5670 servers running Linux.


The Linux servers, where shopping occurs, have 32GB of memory each and run 64-bit Intel Itanium processors. The farm may eventually scale out to more than 100 servers, Murphy says.


The idea is that pricing—which is necessary for booking—must have ultrahigh, if relatively expensive, reliability. Shopping, which often doesn't lead to a booking and which is more demanding on CPUs and memory, can be offloaded to powerful but relatively inexpensive servers. Murphy cites Sabre's exploitation of commodity Linux servers in a "horizontal farm" as perhaps the most noteworthy innovation in the ATSE.


At the beginning of the project, Sabre planned to put everything on NonStop, but shopping was soon migrated to Unix and finally to Linux as Sabre gained confidence in the architecture. Now, Sabre is further refining the server farm by moving to a "flower" arrangement in which the MySQL database replicas are on 64-bit Itanium boxes at the center of each flower, surrounded by "petals" consisting of cheaper, 64-bit Advanced Micro Devices Inc. Opteron machines. Each Itanium box is then a database server to its attached Opteron application servers, which can be configured more economically because they don't require the memory and resources needed for the database.


"The idea is, you can't make the application cheap enough or fast enough," explains Scott Healy, vice president for enterprise systems at Sabre. "Customers don't like waiting, and expanding into the Internet just means we get more and more volume we don't get paid for." He says it remains an open question as to just what functions are best left on the ultrareliable NonStop machines and which might safely be moved to the cheaper server farm.


Healy says he's proud of his developers' ability to move the shopping and pricing algorithms to the new system without losing performance. "Think of what the legacy environment has—fast processors, flat files, assembler language. What do you have going on your side? You've got lots of memory, and we can manage it," he says. Queries run a bit faster now, even though processing is more complicated because of the many new options, fare types and the like, he adds.


"We have to be in an environment where our cost, two years from now, is half what it is today on a per-unit basis," Healy says. "The air-shopping problem will be more complex, there will be more Internet users and there will be more [users] internationally. The only way we can meet that demand is by riding Moore's Law."


And, Murphy notes, by continuing at 25 mph through the snowstorm.












Sabre ATSE Services Architecture


Our Commenting Policies