Practical Considerations

It’s easy to become beguiled by the promise and potential of the feature sets that p2p implementations claim, especially when looking at the promotional claims coming from both the free and commercial camps in the field.

While a peer technology can be ideal for some applications of information access, it will assuredly fail miserably in others. The first requirement of any intelligent choice is at least being able to identify the general areas where a particular application might be spectacularly inappropriate.

Take for example a simple file-sharing system with files individually managed at every node. Files are probably duplicated across many nodes, which is fine for content that is unchanging. Random duplication can even help retrieval and download performance, needing nothing more sophisticated than broadcast query search.

However, such a simple system would be unsuitable for another environment where content is constantly being changed, say documentation for a project team. The overriding issue for retrieval in such a system would be: Where is the most up-to-date copy? Simple query results can’t answer that question, because the dynamic-content situation requires some form of versioning or managed metadata tracking. A better solution in this case would be a publish-oriented distributed storage. The best answer might be an ordinary server-based versioning system and to focus the p2p aspect on providing peer communication and collaboration—an IM system.

Define the goals, ask if they are appropriate or reasonable, and match the software solutions. Then check if the proposed solutions actually can deliver on the real questions in the user context, as indicated by the previous thought example.

Why Deploy P2P?

The first question about p2p deployment that should arise is “Why am I considering p2p solutions?” Other formulations with a more specific focus can also come to mind: What are the benefits? What are the risks? Is it worth it?

To adequately answer these and similar questions requires an understanding of your specific requirements in relation to what p2p in general can and can’t do, along with a feeling for the capabilities of a considered implementation.

Equally important is some kind of guiding vision of what you are embarking on. Because p2p is often as much about attitude and community as it is about technology, your users may need an articulated vision in order to understand and effectively use the new capabilities that a deployed peer system provides. In fact, you may need to actively evangelize the vision to promote usage.

We’ll recap some of the fundamental p2p principles in this analytic context.

Bit 5.1 Peer computers respond independently to requests from other peers. This is fundamental. However, the scope of requests and responses, their execution, and the degree of user involvement are all application specific.

The functionality of peer technology is built on endpoint messaging and shared resources. Direct exchanges between peer members of the p2p network manage access and the use of these resources. In other words, a peer can directly initiate messaging with other peers; request information about content stored on other peers; have content read, copied, or stored; request transfer of this content to others; request processing of information and have results sent back—all without any central control, or even awareness of the exchanges, and often without the immediate knowledge of the local users.

Bit 5.2 Peer computers normally act and respond without central control. Peer technology makes sense only if such autonomous behavior is allowed within the context of the deployed p2p network.

So one major question becomes: Do you want this kind of free exchange between individual computers in your network? Or more to the point for business deployment: Is this kind of exchange allowed within the context of current network or corporate policy? Might there be contexts where it is, and others where it isn’t?

Clearly, there are vast differences in this respect between a p2p network limited to a local intranet, a p2p deployment that allows authenticated remote access over public lines, and a solution that is open to peer clients on the Internet at large. The selection of an appropriate technology critically depends on such scope decisions.

As for the issue of context, not everything lends itself easily to decentralization and hence to redesign as a p2p system. For enterprise, service-oriented architectures are considered the most adaptable to structural change. Therefore, services are the first likely candidates for migration to peer architecture.

But all services might not be suitable. Many mission-critical services need to be carefully managed—quality-of-service ( QoS) monitored for high availability, performance, and data integrity. It’s possible that a p2p technology can be successfully deployed in such a critical environment, but it will assuredly take hard work and careful design to achieve the same goals. The more immediate objection can be that there’s little margin for experiment in mission-critical contexts.

As a group, process-oriented systems aren’t normally good candidates for p2p. They tend to be too formalized and tied to all manner of centralized decision, control, and quality assurance mechanisms. However, a loosely coupled business process, controlled overall by a workflow or business process management system, could be restructured to be delivered by autonomous p2p systems without too great an effort. Newer Web services often fall into this category.

Redesign is a nontrivial task in either case, so it must be sufficiently motivated. Avoid the critical systems unless there’s adequate margin and redundancy until the new system is verifiably functional. Instead of redesign, perhaps set a first goal to implement new services that don’t exist yet because they are really possible only in a peer environment. With a successful deployment, the experience is bound to make a proposed redesign more manageable and perhaps more acceptable to all affected.

When in doubt, let this adage be your guide: If it ain’t broke, don’t fix it! And from the pragmatic business point of view: Don’t build what you can’t manage. An even more pragmatic approach might be to apply these criteria to adoption:

The last is sometimes the only one that matters, although the necessity might not be obvious from the start.

Decentralized collaboration tools are the kind of deployments that users and managers end up finding a necessity only after adopting and learning to use them over a period of time—initial reactions from the old working methodology viewpoint are frequently expressed as “What’s the point?”

Business Considerations

An overall business analysis of the “new Internet”, in which distributed processing and peer networking seems destined to be an integral part, can be found in a special report, Internet Infrastructure & Services by Chris Kwak and Robert Fagin (Bear Sternes and Equity Research Technology, May 2001)—Appendix B for sources.

The 178-page report is well worth perusal, although like everything else in this field, the underlying situation changes so rapidly and sometimes so unexpectedly that any published material risks being outdated. The report is perhaps most interesting for the insight it gives to a number of business ventures in 1999 and 2000 that were based on distributed processing and peer technologies. Several of the visible projects based on these solutions give little or no surface indication that they are built on distributed or peer technologies, so the investigative effort published in reports like this give a better indication of what’s going on.

The advocate point is often made that p2p is less costly for enterprise than traditional centralized client-server (cC-S) solutions. The previously mentioned report makes this astute observation about probable cost savings:

cC-S systems are also high-maintenance. Servicing cC-S systems can be prohibitively expensive, much more costly than equipment and software. For example Oracle derives over 70% of its revenues from services, not its database software and applications. Microsoft derives over 30% of revenues from services; this would likely be much higher if Microsoft did not sell Windows to consumers. According to IDC, the cost of managing storage is four times the cost of storage hardware.

Aside from direct service cost, companies also feel indirect costs caused by server vulnerabilities and the costs for backup systems. Significant bottom-line pressure is therefore exerted on business to find more cost-effective solutions, and this reality explains much of the drive to try p2p in the face of cautionary factors that would otherwise be deemed prohibitive.

On the other hand, and only indirectly alluded to in the report, is the simple math that the aggregate equipment and operating cost for the entire p2p network and its resources can be much, much larger than the centralized server solution, even allowing for its greater capacity. This cost is usually not an issue because, on the one hand, most of these distributed resources already exist and are paid for, and on the other, the procurement and operating costs are equally distributed and thus relatively small for each cost accounting entity.

The Benefits

Both technical advantages and “social” benefits to using p2p technology can be identified, albeit their perceived and relative importance can vary considerably between different settings.

One bottom line seems clear for business: Networks create value. The natural extension of this is that any enhancement of digital networks will have profound economic consequences for any business operation. The enhancements can be to the pervasiveness, reach, value, or flexibility of the network; all possible with p2p.

The special feature of p2p in a business environment is a direct function of peer communication: the ability to form ad hoc groupings or peer groups based on common interests and goals. Numerous situations exist where informal groupings can be leveraged by peer technologies to make collaboration more effective. Incidentally, when considering groupings, don’t forget to include the entirely new collaboration possibilities that a peer application might provide.

Business Benefits

The business viewpoint is largely congruent with economy, but it also considers such things as QoS, adaptability, and security. Nevertheless, we can make the case that the most significant factor to determine adoption is the perceived size of the opportunity.

Some of the more specific issues that can benefit from distributed peer architectures are

• Geographic locality. Traditional server centralization has problems adapting to mobility and access from all parts of a far-flung company. Peer solutions are distributed and can thus provide data, resources, and services where they are needed.

• Server downtime. An offline server can paralyze many corporate activities across the board because of server dependencies. E-mail service is just one example. Peer solutions distribute the risks, and the network can remain functional despite a large number of nonresponsive nodes.

• Central administration bottlenecks. Not everyone can make themselves heard or have their needs fulfilled in a heavily centralized scheme. The peer approach is that users manage their own resources to fulfill their own needs, or they contact directly other nodes that can. Initial setup of peer workgroups by the participants is also easy—project groups can form and change quickly.

• Granularity issues. Solutions or services in centralized systems don’t always avail themselves to individual users at their own convenience. Peer granularity, by definition, is at the user level.

• Intermediated workflow. Critical client-server conduits must pass through centralized services. In peer systems, contact is direct, which is often better.

• Fragmentation of network. It becomes difficult for users in one area to contact resources and users in another, tied to another server. Again, peer connectivity is direct, dynamically forming virtually connected interest groups as users gravitate towards some common purpose.

• Resource bottlenecks. Network delays and service unavailability are a side effect of the fact that everyone in a centralized system must communicate through the central server instead of directly. Peer resources are distributed, and they are often replicated and made adaptive to demand.

The common factor for a lot of these issues is the way server-bound networking introduces extraneous links and components to what should be more direct connectivity, and therefore ends up being constraining and resource wasteful.

What about cost? The advantage of p2p is that existing capacity can be interconnected and used in ways impossible before. The actual cost of the processing assets (that is, procurement and operation) might be considerable, but it too is distributed and absorbed by many users. The per-unit cost is usually relatively small, and it’s covered by the normal purpose of the equipment. The assumption is that most of the time, each unit has ample idle capacity to contribute to the network.

Most PCs typically sit idle most of the time, perhaps as much as 90 percent of the potential processing capacity—its single most expensive component—unused. Large companies like Intel have successfully increased in-house distributed processing to the point where it routinely can save time and hundreds of millions of dollars on design validation projects.

Similar calculations for potential savings could be made for unused storage, bandwidth, and the ability to effect parallel distribution and processes. For example, storage on disk is significantly cheaper than the cost of using bandwidth to repeatedly transfer the data from a central server. Informal estimates suggest that enterprise PC hard disks on average use only about an eighth of their storage capacity, a figure probably decreasing as the drive capacity steadily increases year by year. This is what makes network local caching and peer distributed replication so attractive from the purely economic perspective, not to mention the boost in performance.

Technical Benefits

From a technical and performance view, a p2p solution frees users from the traditional dependence on central servers and from the associated bottlenecks—both human and machine. This is especially true in areas like content publishing.

That’s not to say bottlenecks disappear; central dependencies remain in server-mediated solutions, albeit loads on servers are light. The critical bottlenecks instead depend more on bandwidth and other constraints at each node but don’t usually affect more than the nodes currently conversing. The same goes for failure-points.

Users gain control over the services that they utilize. In addition, content and implemented services can be distributed and made automatically load-balancing. Multiple computers can share files seamlessly, no matter where they are located in the network. This can greatly erase the distinctions between home and office networks, in that, for example, an office worker telecommuting from home might transparently access files and information that reside within the “office” network—peer technology extending the office network to any number of home workers and partners. In fact, the employee can become fully roaming, able to access (and be accessed by) the network and all its resources from any workstation location, even from wireless LAN devices such as PDAs and newer cellular phones.

The distributed nature of otherwise largely idle resources confers many benefits to network members. Benefits include freely available content storage and processing power, and optimized performance. As a rule, the resulting distributed system exhibits good performance, has fault tolerance and scalability, requires little maintenance, adapts well to change, and is cost-efficient to deploy.

For enterprise, costly data center functions can sometimes be replaced by distributed services between clients. The added advantage is that content can be managed locally and updated by the people who are directly responsible for it. Similar considerations apply to distributed remote maintenance of resources through an infrastructure capable of direct access. In particular, geographically distributed parts of a far flung corporation could automatically cross-index and update inventory, project files, resource lists, personal agendas, and so on. Team members can always have the latest data at hand at any location and reach other members and staff through a wide variety of channels.

Not all content is equally suited to distribution, but the potentials make it worth investigating. In some cases, a mix of central store, distributed publishing of updates, and local access by users might be a better solution than a fully decentralized peer topology. Automatic network agents might fulfill a number of roles here.

Social Benefits

From the social point of view, p2p users can dynamically form a broad range of ad hoc “communities” (known as “ peer groups”) to efficiently and securely fulfill their own needs—albeit this scenario assumes they will actually work together in this way. Community members can form the primary web for communication, requests, collaboration, and resource sharing.

No less important are the psychological benefits gained from establishing what are sometimes expressed as edge services. Despite the term “edge” suggesting remote users at the periphery of an organization, the actual location of the users involved is immaterial. That is to say, users collectively maintain and control their own services in a local setting, independently from the central parts of an organization. Users thereby feel “in control”, free from centralized bureaucracy. Based on p2p technology, both user community and services can readily adapt to changes in the local environment.

The organization center in a network with edge services no longer needs to anticipate, investigate, or manage user needs in detail throughout the organization. Freed from such time-consuming tasks, it can instead focus on overall matters of policy and guidance, which is supposedly its main purpose anyway.

The Problems

Given these advantages and benefits, what then are the problems?

The Control Thing

Well, yes, of course: loss of control can be a serious problem.

The “autonomous edge” and “free agent” functionality might simply not be acceptable in some organization settings, as a matter of principle. This policy may be the stance of management as a whole, or IT management in particular; either way, such lack of acceptance can easily kill any attempts to deploy alternative structures of any kind, including p2p.

Notwithstanding unfavorable policy, one can still find some p2p solutions in “hostile” environments, albeit then introduced under the radar, limited in scope, and camouflage-described in “management acceptable” ways.

Security

Related to control is security. In addition, it is generally assumed that you can’t have security without control.

Peer technologies, because of the way they circumvent central control, often also circumvent various security measures. This issue is complex and is described in detail in connection with specific situations and implementations in following chapters.

Suffice it to say here that p2p deployment in most settings, not just business ones, raises significant security concerns, which must be adequately addressed with respect to the particular technical solution chosen. Ideally, security issues should guide the selection process, rather than come in as an afterthought requiring fixes.

Inappropriate Setting

Peer technologies emphasize informal cooperation and de-emphasize hierarchies. This characteristic can make p2p inappropriate from some settings that require a more formal work process or workflow model.

With an awareness of the informal aspect inherent in p2p technologies, a solution may often be deployed as a successful complement to the formal process—as organizational aid, brainstorming facilitator, team communication channel, discussion medium, preparatory collaboration tool ahead of formal meetings, background resource manager, and so on. Informal and direct-contact aspects of p2p are why people on their own initiative install messaging clients such as ICQ.

Indifferent Users

Just because a suitable technology is deployed doesn’t mean that users automatically will use it (or use it as intended). If they don’t see the point or resist changing their way of working, deployment might be a futile effort—even counterproductive.

The problem of involving users arises any time a workplace infrastructure is changed, and it can literally take years to have workflow regain normal efficiency, even without significant user resistance to the innovations. When introducing new ways of working, it’s crucial to have the users involved and open for change.

User resistance to new technologies expresses itself in two ways:

• Overt resistance, where people simply protest and refuse to use the new tools and methods, or actively sabotage the intended changes.

• Covert resistance, where people might avow, and sometimes themselves believe, that they are using the tools and methods, but where independent investigation shows that they in fact do things quite differently.

The latter effect has been documented only recently in studies of how people (especially teams) apply the formalized methodologies mandated in their work. It’s very interesting to see how the verbalized reality-views of management and teams diverge so markedly from the actuality of how people do work and get project deliverable code out the door. See, for example, Agile Software Development by Alistair Cockburn (Addison-Wesley, December 2001) for a detailed discussion relating to programming teams and collaborative methodologies.

Messaging (mainly IM and e-mail) and file-sharing applications tend to be relatively simple to deploy and have people use—typical client usage meshes well with the way people intuitively go about dealing with messages or searching for and retrieving content. These activities are often asynchronous and single-user activated, and content retrieval is highly autonomous and anonymous.

The technologies with a strong collaborative focus are the difficult ones to deploy effectively because they are inherently more invasive in the way that people are used to working. User will need to adapt to a different way of working, just like they need to learn to work in project teams or use specific methodologies. The collaborative conventions need to be explored and refined for the situation, and sometimes spelled out or supported by explicit scaffolding for newcomers.

Which Software?

The buzz popularity of p2p is, paradoxically, also a problem. By early 2001, perhaps some 200 companies were depicting themselves as p2p-solution providers. Research projects targeted business-to-business ( b2b), business-to-customer ( b2c), customer-care ( c2 or cc, meaning support), and e-commerce applications. Some also targeted consumer-to-consumer ( c2c) space—for instance, auctions (as in Firstpeer).

Some of these companies were simply exploiting the trendy p2p word from the previous year, perhaps fearing to be perceived as not with it, and on closer inspection, their solutions had little to do with any useful p2p technology. By late 2001, many of these companies had vanished from the Web, or they had p2p-related Web pages that hadn’t been updated since sometime in 2000. The situation is partly due to the general downturn and shakeout in the IT sector, where even seemingly viable p2p solutions appeared stricken. In some cases, the simple answer might be that the initial seed money ran out, and no investors were willing to provide more funding.

Anyway, the problem is not just to identify a viable implementation of p2p technology suitable for practical deployment but to identify—actually, guess—which technologies will remain viable and supported later, when your deployment is a fact and your users are dependent on the new distributed services. Many solutions available now, although interesting and workable, are proprietary, single-source offerings, which disqualifies them for many corporate settings.

Other solutions are “beta” quality or under such rapid and unpredictable development that their deployment must be seen as highly experimental. Open source implementations at least have the virtue of being maintainable in-house if someone can assume the responsibility for the deployed code.

In this book, both proprietary and open solutions are explored, so this issue is one to be mindful of with respect to the implementations discussed.