Despite its disadvantages, modularity is a fundamental structuring technique with a long and successful history in system design. From early work on layered operating systems and networking architectures [44, 114], to more recent advances in stackable systems [88, 49, 46, 108], modularity has played a central role in managing complexity, isolating failure, and enhancing configurability. Clearly, it is not something that can be discarded lightly. So the question is whether it is possible to avoid the disadvantages of modularity without giving up on its strengths. It is our contention that this is indeed the case: we propose a new abstraction, called path, that is complementary to, but equally fundamental as layering in a modular system. Whereas layering is typically used to manage complexity, paths are applied to modular systems to improve their performance and to solve problems that require global context.
Paths have many faces and we defer a detailed description to Chapters 2 and 3. For now, we appeal to the reader's intuition that a path is a vertical slice through a layered system that provides the context that is ordinarily unavailable in a modular system. For example, a path could represent the dataflow that occurs when transferring a file from a disk to a network adapter through the Internet file-transfer protocol (FTP). In a sense, paths are like small, or localized, vertically integrated systems. With this view, purely modular systems and purely vertically integrated systems represent extreme cases in the design spectrum illustrated in Figure 1. With the addition of paths, it becomes possible to pick intermediate points in this spectrum: those parts of a system that are not performance critical can be realized in a purely modular fashion, whereas performance critical parts can be realized as optimized paths, giving performance close to that of a vertically integrated system, but keeping cost and complexity down as only performance sensitive parts need to be verticalized. Furthermore, with a well-designed path architecture, it should be possible to carry out this verticalization in a structured and mostly automatic fashion. Ideally, a system designer could specify in a declarative manner what parts of the system are performance critical, and the path infrastructure would use this specification to automatically translate modular code into an optimized path implementation. If the critical path has particular resource-management needs, such as a specific quality-of-service requirement, the same declarative specification could be used to associate appropriate resource-management policies with the path.
The degree to which this ideal case can be achieved will of course vary from appliance to appliance and also depends on the quality of the tools that are available in the path infrastructure. Realistically, a system with paths will always require slightly more effort to build than a purely modular system and is unlikely to completely reach the performance or resource-management potential of a fully vertically integrated system. But paths provide the ability to start out quickly with an almost purely modular system and then optimize performance for the parts that warrant the extra effort. In this sense, paths provide an additional degree of freedom: the set of modules in a system and the manner in which they are connected determine the functionality of an appliance, where as the degree to which optimized paths are employed controls the performance, quality-of-service, and predictability attainable in the system.