How Linux Makes Companies Smarter
Two perspectives exist regarding Linux's success in the enterprise: one from the inside and one from the outside. Insiders credit the organization's intelligence, resourcefulness and expertise. Outsiders credit vendors with the same qualities. Credit is due to both, of course, and to some degree each side gives some credit to the other. But the press generally takes the outside view, giving the lion's share of credit to vendors. As a result, little credit goes to the qualities that really account for successful use of Linux in the enterprise.
No two inside stories are the same. Every vendor-side story basically is about how products solve problems—that's why vendors love to call their products “solutions”. But Linux isn't about “solutions”. That's a vendor word. Linux is about resourcefulness and intelligence. Those are customer words. Linux succeeds in the enterprise by helping smart companies make themselves smarter. With Linux and open source, the primary supply and demand sides of the marketplace both reside inside the company.
This coexistence is a hard development for many of us to understand. It's hard for vendors because they're used to a marketplace where the supply side is in control and wide profit margins are the ideal, even if they are no longer the norm. It's hard for the press to understand, because so many of the news stories they write are vendor-vs.-vendor sportscasts, in which the marketplace is a playing field and customers are prizes. It's hard for corporate leadership to understand, because they're so used to playing the prize role in vendor playoffs.
The people who don't find it hard to understand are the people who use Linux to make their companies more efficient, more reliable and more effective. Take the case of LSI Logic, the semiconductor maker. Roland Smith is the director of Global Operations there, running one of four groups that report to the company's CIO. The company's big switch to Linux happened a while back when Smith's team recommended replacing HP-UX with Linux, increasing performance five- or sixfold and cutting costs by two-thirds. Now, Smith says, “Whenever somebody comes in and wants to talk to the CIO about a new application, or a project or anything new, the CIO's question is, 'Does it run on Linux?”'
This environment has some interesting effects on the flow of help. Smith provides an excellent case of help flowing from customer to vendor:
In our SAP environment, we recently decided we wanted to begin inserting Linux application servers. So we went out and talked to both Dell and HP. We told them what we wanted from each of them was an eval server—one they think is best suited to run Linux. We wanted four processors and a gig of memory.
A couple of interesting things happened. One was HP fumbled around and took two weeks to come back and say, “What do you really need?” The other was that Dell took three days and shipped us a server. They said, “Here. You've got it for three months. Go tell us what you can do with it.” That was kind of wonderful.
So, then we went to SAP and said, “What do you recommend?” And SAP said, “Well, we think SuSE 8 runs okay. And we think that Red Hat 7.1 runs okay. But we don't really know.” Then we went and talked to Red Hat and they said, “We think it'll run nicely on our Advanced Server 2.1, but we don't really know. So how about you go try it out and tell us?”
So, we built it. We bought the Red Hat application server, built it, loaded SAP on it and put it in our test environment. And it's running incredibly well. We're very happy with it. But it's interesting to me that, of all the vendors out there, only Dell said, “We'll happily give you hardware to try it out on, but we don't know anything more than that.”
Where LSI is concerned, most of the intelligence and leadership is located on the customer side.
Another smart customer is Orbitz, the on-line travel company owned by five major airlines. Leon Chism, chief internet architect for Orbitz, says this about how the company applies its own intelligence internally:
Our developers are very good at leveraging open-source tools to improve our design, build and software management process. On their own they have built a number of tools that parse logs, store them in a PostgreSQL database and do ex post facto analysis to find errors and opportunities for improvement. The first I heard of one tool was after it had been used to do analysis and improve some sections of the code successfully several times. We also have a number of developers and engineers using tools like Perl, Python and Jython (we employ an official Jython developer) for their own ad hoc tools to help them monitor site behavior. All of this is in addition to the official production management infrastructure. Generally, after a tool has been developed, tested and proven useful, we migrate it into the rest of the management infrastructure our Network Operations Center uses.
He also sees the use of Linux and open source as competitive advantages for Orbitz:
Orbitz is a company that leverages open-source projects in its production environment and isn't afraid to be public about it. We currently use over 750 Linux machines in our production environment. Our web servers are Apache running on Linux, our application servers are proprietary servlet engines running on Linux and the back-end “booking engine” is comprised entirely of Java services running on Linux. Lastly, the software that does the low fare searching that is one of the key differentiators between Orbitz and our rivals also is running on Linux.
Companies have found ways to make money by providing services to open-source-software users or by packaging this free software with products they sell. With the profit motive driving its promotion, free software is cropping up all over corporate and government computers.
Why is it most important that “companies have found ways to make money”? Is that more important than the actual work that gets done?
Why does he say “companies” when he means “vendors”? Aren't customers companies too?
And let's face it: Linux users are tough customers. Here's Leon Chism again:
On the relationship front, there is a vendor that we have and are still considering replacing with an open-source solution. For the most part, the application works, but when we find bugs in it the resolution process leaves a lot to be desired. Escalation procedures, arguments about root cause, long discussions about “supported configurations” all lead to muddling the process rather than focusing on the solution.
When we have issues or questions with Linux or Apache, these things aren't at issue. We simply use the customer service application to end all customer service applications—www.google.com—and start researching. Or we start perusing source code. Orbitz is a customer that typically pushes the limits of the products we use. Some vendors are up for the challenge and are willing to make efforts to support that need. Some aren't. And we don't know who is who until, as they say, push comes to shove. Using open-source products removes that issue. We have an engineering and software development staff that is fully capable of paddling its own canoe, and the support we get from authors, list servs and Google is more than enough in most cases.
Yet the tough vendor story gets played while the tough customer story does not.
Doc Searls is Senior Editor of Linux Journal
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?