Second, most large retailers are deployed with distributed Linux systems that easily integrate with their instore Point of Sales (POS) applications and with their daily retail operations. Virtualizing a distributed architecture that spans thousands of locations in different geographies is a huge project that requires a convincing rOI for upper retail business management, which largely came up through the organization by starting as store managers with their own in-store servers. Third, multinational retailers employ distributed Linux computing because there are different server purchasing, support, and configuration standards for each country that must be followed, even on an “open” platform such as Linux.
Also very transaction-sensitive, banks and other financial institutions are accustomed to using distributed servers in local branches as failover mechanisms for mainframe-provided processing. “When a central processing unit goes down during the day or in a disaster recovery situation, the procedure at bank branches is to manually process transactions and then post the transactions afterward, when the system is up,” says one Seattle bank CIO. “This is irritating and troubling for customers, who want their financial records posted right away. Paper ledgers of transactions also invite user error.”
Because of this, most bank processing software vendors offer server-based, inbranch systems that can step in with “store and forward” transaction services when the mainframe is down. Store and forward allows bank personnel to log transactions and serve customers without using paper. The transactions are temporarily stored in local servers. Once mainframe service is restored, the transactions are then forwarded to the mainframe.
The arguments in banking for a distributed approach are similar to those of retail. Bank managers feel they are in control of their transactions and their customers with localized failover support from an in-branch server. It’s also a very serious perception issue for financial customers to see their transactions logged onto paper ledgers when the system is down, with the teller informing them that the transactions will be keyed into the system when the system is back up. Few bank managers are comfortable with “virtualization,” which they perceive as putting all their eggs in the basket of a central processor at headquarters that could fail.
The Manufacturing Floor
Automotive parts depots, airplane and automobile assembly lines, and other manufacturing applications frequently rely on distributed servers for specialized parts and drawing lookups. In these instances, a feeling of local control over critical data and the fact that access latency may be reduced by having a local server are critical driving factors. “In these cases, the factory flow simply can’t tolerate the extra network loop that communications with a central server would create,” says CA’s re. “If a manufacturer has shop floors with a lot of robotics, distributed computing with proximate physical servers is the best solution.”
One large U.S. jet manufacturer places all its engineering drawings and bills of materials on a local server in the factory. Factory staff can maintain these drawings, and the investment in a single server that factory users “own” is less expensive than a mainframe corporate resource that’s more business- than engineering-oriented, and that must be shared with other users. With the Linux operating system and open source solution sets, cost is further reduced.
Research Laboratories and Universities
The intense mathematical computa- tions and modeling performed by university science departments and public and private research labs demand separate, distributed servers that can serve as dedicated department or project “workhorses.” As separate entities, these servers, like their mainframe counterparts, can easily link into “grid” architecture in which enterprises and institutions can cross-communicate with each other and share resources.