Flying high with open source

"It's always peak hour somewhere" on the Sabre Holdings network, but open source software helps the company meet its demanding uptime requirements

Sabre Holdings' IT department supports the Travelocity Web site, the Sabre Travel Network and Sabre Airline Solutions, and the company has been using open source tools for some 10 years, according to CTO Robert Wiseman.

To say Sabre Holdings is a believer in open source technology is an understatement. Its IT department supports the Travelocity Web site, the Sabre Travel Network and Sabre Airline Solutions, and the company has been using open source tools for some 10 years, according to CTO Robert Wiseman. Cost certainly factors into the reason, but it's Sabre's ability to control its own destiny by making whatever changes it deems necessary that's the real motivation. Along with Kevin Bomar, Sabre's senior principal of middleware services, Wiseman explains how open source software and the community that supports it help Sabre deliver solutions that meet its demanding uptime requirements.

Can you give me a sense of the scale of your operation? We have about 5,000 servers across the world, probably two-thirds running open source. Close to 100% of our requests go through a server using open source technology at some point, primarily Linux.

Robert Wiseman:

Do you use other, non-open source operating systems? We've standardized on Red Hat Linux, but our mainframe runs a mainframe operating system, and we have some legacy Unix systems running various proprietary operating systems, but we're starting to phase those out as we move to a standard Linux environment.

RW:

What other open source technologies do you employ? We use a lot of them, from Apache and Tomcat [Web servers] to open source ESBs [enterprise service bus], test tools, open source databases, Terracotta for caching, and so on.

RW:

What are the key benefits? Certainly cost is an attractive aspect, which is probably one of the first reasons that everyone starts to look at open source. Another is the ability to have access to the code, to have control of your own destiny. At Sabre we're a 24/7 environment, and we run 32,000 transactions per second across our systems at peak. We can never afford to be down because we support airlines and travel agencies across the world and, as we say internally, it's always peak hour somewhere. If we run into problems -- which thankfully is very rare -- we have the ability to go in and take a look at the code ourselves and make fixes if necessary. With a commercial, off-the-shelf solution, you're pretty much dead in the water. You have to fall back [to a previous revision], if that's even feasible, or wait for a vendor release.

RW:

Kevin Bomar: In some cases, support is also a benefit. A lot of times, the support you can get for open source products -- the developer help and so on -- is better than you get for commercial, off-the-shelf software.

How important was access to that developer community in your decision to use open source tools? Very important. Vendors are traditionally very responsive; it's one of the things we pay them for. But it's also good to have a community that can help you address things that maybe even some of the vendors haven't seen.

RW:

Profile of Robert Wiseman

KB: It's important to see how current, large and active the community is. If you're considering a certain open source solution and it hasn't had an update in a year, that probably means the community is not very active and you should probably reconsider.

What kind of things do you rely on the community to help with? For developer knowledge-bases and, depending on the size of the community, fixes and patches. In some cases, we go after third-party support for this; in others, the community is good enough.

KB:

How do you determine whether the community is good enough? If it's component-level, it's probably OK to rely on the community. If it's in the middleware space, you need to determine how broad and active the community is -- looking at things like how fast patches get out and how tightly the ship is run for that community. In some cases in the middleware space, we're able to rely on the community; in others where we decided we wanted more of a guarantee of 24-hour support, fast turnaround time on patches and so forth, we've gone with third-party support.

KB:

Does use of open source tools make it easier to recruit and retain good IT people? Certainly as the IT world expands globally, open source is more accessible to people who are just getting into the industry. So, in sheer numbers, there are a lot more people across the world who have access to open source. And open source is an attractive proposition to people coming into our company because it's seen as a people's technology. It's something people can get access to and learn themselves. They very quickly get a comfort level. There are different camps on this, but I think that's largely the case.

RW:

KB: I don't know that it helps to retain developers. It certainly drives the excitement factor among developers. A lot of our developers are involved in different open source projects. They see they can do their jobs much faster.

Why? With open source you have a lot more components and building blocks, standard template libraries, and things like that. If you go to TheServerSide.com on any given day and look at the amount of open source tools being released, it's phenomenal. There's also a lot of social networking between developers around different open source technologies.

KB:

Would you say you've reached the point where the decision comes down to, 'buy, build or open source?' We would go for open source first, buy next and build third, as a general rule. But because of the uptimes we have to support, price alone isn't good enough. I could never go to my boss at the end of a terrible year in terms of uptime and say, 'Well, it was cheap.' We've got to make sure our products are very stable. Often we do pay for support contracts. Those prices creep up, and to some extent become comparable to commercial products. But we also have a strategic mantra that we should be vendor agnostic. Whatever product we use -- whether open source or commercial, off-the-shelf -- we develop abstractions in our code against that product, so we don't tie ourselves to any product. And one of the aspects we take into consideration when we select an open source product is to make sure more than one vendor supports it. So, should we have to go to a different vendor because we're not getting the right service or the right service at the right price, we have that capability. Because we take the effort of building abstractions between our logic and that product, we're able to move pretty quickly.

RW:

How does that work? Say you have a certain database and you're not happy with your support. What happens? Let's take Java as an easy example. We're starting to deploy Hibernate, which is a relational mapping product. So, the Java services themselves don't actually see the underlying proprietary SQL calls of the database. That's converted in the abstraction layer we built, so if we make a change from, say, one database to another, the services themselves are actually unaware that the changes are made. The only place we have to make that change is in the relational mapping product itself.

RW:

Are there any projects you've undertaken using open source technology that could not have been implemented any other way -- from either a technical or practical perspective? There are certainly projects that might not have been practical without access to open source solutions, for proof of concept or prototyping. One of the benefits of open source in the early stages of a project is you don't have to buy the licenses. You don't necessarily really care about support if you're just doing a proof of concept or a prototype. So, having access to a range of open source products for some of our resource and development groups spread across the world allows them to get fairly mature and fairly well-baked solutions without spending an awful lot of money.

RW:

What have been the biggest challenges you've faced in deploying open source technologies? I think the biggest thing is that a lot of developers have never met a download they didn't like. One of the good things about open source is easy access to the open source technology and products. One of the downsides to it is the easy access to the wide range of products and technologies. I suspect a lot of companies are using open source that actually aren't even aware of it. We go through a lot of effort to control our use of any product, whether open source or commercial, because there is a tendency for developers to download a solution and just start to deploy it. That can start to get out of hand.

RW:

How do you keep them from doing that? Education, governance, management. We look at their code, we know what the builds are that are going in.

RW:

KB: Sometimes there are multiple open source solutions for the same problem, whether it's rules engines or ESBs. At that point, you need to evaluate which one is the best because you don't want to have two open source solutions for the same problem. So, that gets into bake-offs, benchmarking, looking at stability and level of support -- that type of thing. As Robert said, it's educating the developers and getting a level of maturity in the developers of how they use open source, and also having some governance and standards around certain technologies.

Have you encountered any dangers from using open source technologies? One of the things you have to pay attention to with open source, with a [commercial, off-the-shelf] solution the vendors have product road maps and business plans. You have to keep it evergreen with open source and watch the road map more. That's why having layers of abstraction is important. If an open source solution starts to lose active community, you need to have a migration path in mind.

KB:

Have you ever had to swap out a product because the community was faltering? I can't think of an instance where that has happened. There have been times where we've seen one open source solution start to rival another and maybe take the lead. Rules engines seem to leapfrog each other fairly often. ESBs are a fairly active area as well. You've got Mule, ServiceMix, the Apache ESB. So, you need to just watch those areas to see which is going to be best-of-breed a year down the road.

KB:

What advice can you give to others who are looking to employ open source technologies? If you're going to use it in a critical environment, you need to make sure you've got support. I think abstraction is an important piece whether you're using open source or not, so you have the ability to move quickly should you need to. Training is another aspect. If you're going from one product to another, you have to bake that into the cost/benefit analysis. There are a lot of things that come with changing products: training, support, abstractions to make sure you don't couple yourself to any technology, making sure the community is mature, that there are openly available benchmarks. You ideally want to choose a mature product. You don't want to be one of the first guys out.

RW:

What do you think the future holds for the role of open source in the enterprise? As open source becomes more mature, there's going to be a fine line between how people view commercial products and open source products. When you look at the more mature open source products, there often isn't a lot of difference in price compared to commercial products -- in some cases because vendors have brought down the price of commercial products in order to compete. But the other benefits we mentioned -- access to the code, the maturity of and access to the community -- tip the scales in favor of open source.

RW:

Desmond is events editor for Network World and president of PDEdit, an IT publishing company in Southborough, Mass. Reach him at paul@pdedit.com.

Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies