Análisis del Programa de Electrificación Rural Ministerio de Energía

Wherever possible, a new service should be built around an architecture that usesopenprotocols and file formats. In particular, we’re referring to protocols and file formats that are documented in a public forum so that many vendors can write to those standards and make interoperable products. Any service with an open architecture can be more easily integrated with other services that follow the same standards.

By contrast aclosedservice uses proprietary protocols and file formats that will interoperate with fewer products because the protocols and file formats are subject to change without notice and may require licensing from the creator of the protocol. Vendors use proprietary protocols when they are covering new territory or are attempting to maintain market share by preventing the creation of a level playing field.

Sometimes, vendors that use proprietary protocols do make explicit licensing agreements with other vendors; typically, however, a lag exists between the release of a new version from one vendor and the release of the compatible new version from the second vendor. Also, relations between the two vendors may break down, and they may stop providing the interface between the two products. That situation is a nightmare for people who are using both products and rely on the interface between them.

❖The Protocol versus the Product SAs need to understand the differ- ence between the protocol and the product. One might standardize on Simple Mail Transfer Protocol (SMTP) (Crocker 1982) for email trans- mission, for example. SMTP is not a product but rather a document, written in English, that explains how bits are to be transmitted over the wire. This is different from a product that uses SMTP to transmit email from one server to another. Part of the confusion comes from the fact that companies often have internal standards that list specific products that will be deployed and supported. That’s a different use of the word

standard.

The source of this confusion is understandable. Before the late 1990s, when the Internet became a household word, many people had experience only with protocols that were tied to a particular product and didn’t need to communicate with other companies, because com- panies were not interconnected as freely as they are now. This situation gave rise to the notion that a protocol is something that a particular software package implements and does not stand on its own as an

5.1 The Basics 105

independent concept. Although the Internet has made more people aware of the difference between protocols and products, many vendors still take advantage of customers who lack awareness of open protocols. Such vendors fear the potential for competition and would rather elim- inate competition by locking people in to systems that make migration to other vendors difficult. These vendors make a concerted effort to blur the difference between the protocol and the product.

Also, beware of vendors thatembrace and extend a standard in an at- tempt to prevent interoperability with competitors. Such vendors do this so they can claim to support a standard without giving their customers the ben- efits of interoperability. That’s not verycustomer oriented. A famous case of this occurred when Microsoft adopted the Kerberos authentication system, which was a very good decision, but extended it in a way that prevented it from interoperating with non-Microsoft Kerberos systems. All the servers had to be Microsoft based. The addition that Microsoft made was gratuitous, but it successfully forced sites to uproot their security infrastructures and replace them with Microsoft products if they were to use Kerberos clients of either flavor. Without this “enhancement,” customers could choose their server ven- dor, and those vendors would be forced to compete for their business.

The business case for using open protocols is simple: It lets you build better services because you can select the best server and client, rather than being forced to pick, for example, the best client and then getting stuck with a less than optimal server. Customers want an application that has the features and ease of use that they need. SAs want an application whose server is easy to manage. These requirements are often conflicting. Traditionally, either the customers or the SAs have more power and make the decision in private, surprising the other with the decision. If the SAs make the decision, the cus- tomers consider them fascists. If the customers make the decision, it may well be a package that is difficult to administer, which will make it difficult to give excellent service to the customers.

A better way is to select protocols based on open standards, permit- ting each side to select its own software. This approach decouples the client- application-selection process from the server-platform selection process. Customers are free to choose the software that best fits their own needs, biases, and even platform. SAs can independently choose a server solution based on their needs for reliability, scalability, and manageability. The SAs can now choose between competing server products rather than being locked in

to the potentially difficult-to-manage server software and platform required for a particular client application. In many cases, the SAs can even choose the server hardware and software independently, if the software vendor supports multiple hardware platforms.

We call this the ability to decouple the client and server selections. Open protocols provide a level playing field that inspires competition between ven- dors. The competition benefits you.

For comparison, the next anecdote illustrates what can happen when the customers select a proprietary email system that does not use open protocols but fits their client-side needs.

Hazards of Proprietary Email Software

A New Jersey pharmaceutical company selected a particular proprietary email package for its PC user base after a long evaluation. The selection was based on user interface and features, with no concern for ease of server management, reliability, or scalability. The system turned out to be very unreliable when scaled to a large user base. The system stored all messages from all users in a single large file that everyone had to have write access to, which was a security nightmare. Frequent data-corruption problems resulted in having to send the email database to the vendor across the Internet for demangling. This meant that potentially sensitive information was being exposed to people outside the company and that the people within the company could have no expectation of privacy for email. It also caused long outages of the email system, because it was unusable while the database was being repaired.

Because the package was not based on open protocols, the system support staff could not seek out a competing vendor that would offer a better, more secure, and more reliable server. Because of the lack of competition, the vendor considered server management low priority and ignored the requests for server-related fixes and improvements. If the company had selected an open protocol and then let customers and SAs independently select their solutions, it would have realized the best of both worlds.

Open protocols and file formats typically are either static or change only in upwardly compatible ways and are widely supported, giving you the max- imum product choice and maximum chance of reliable, interoperable prod- ucts. The other benefit to using open systems is that you won’t require gate- ways to the rest of the world. Gateways are the “glue” that connects different systems. Although a gateway can save your day, systems based on a common, open protocol avoid gateways altogether. Gateways are additional services that require capacity planning, engineering, monitoring, and, well, everything else in this chapter. Reducing the number of services is a good thing.

5.1 The Basics 107

Protocol Gateways and Reliability Reduction

In college, Tom’s email system was a proprietary system that was not based around Internet standard protocols, such as SMTP. Instead, the system was sold with a software package to gateway email to and from the Internet. The gateway used its proprietary protocol to communicate with the mail server and SMTP to communicate with the rest of the world. This gateway was slow, unreliable, and expensive. It seemed that the vendor had engineered the gateway with the assumption that only a tiny fraction of the email traffic would go through the gateway. The gateway was yet another thing to manage, debug, do capacity planning for, and so on. The vendor had little incentive to improve the gateway, because it let customers communicate with systems that were considered to be the competition. The mail system had many outages, nearly all of which were gateway outages. None of these problems would have arisen if the system had used open protocols rather than requiring a gateway.

History repeated itself nearly a decade later when Microsoft’s Exchange mail server was introduced. It used a nonstandard protocol and offered gateways for communicating with other sites on the Internet. These gateways added to the list of services that SAs needed to engineer, configure, plan capacity for, scale, and so on. Many of the highly publicized Exchange bugs were related to the gateway.

These examples may seem outdated, since nobody would now sell an email system that is ignorant of the Internet. However, it is important to re- member these lessons the next time a salesperson tries to sell you a calendar management system, directory service, or other product that ignores Internet and other industry standards but promises excellent gateways at an extra (or even zero) cost. Using standard protocols means using open standards, such as Internet Engineering Task Force (IETF) and Institute of Electrical and Electronic Engineers (IEEE), not vendor-proprietary standards. Vendor- proprietary protocols lead to big future headaches. A vendor that offers gate- ways is probably not using open standards. If you are unsure, directly ask what open standards the gateways interoperate with.