Distributing processing without DPEs: design considerations for public computing platforms
EW 9 Proceedings of the 9th workshop on ACM SIGOPS European workshop: beyond the PC: new challenges for the operating system
| Hi-index | 0.00 |
In this paper, we describe the Wrens framework for rapidly evolvable network services. The goal of Wrens is to provide the abstractions and the infrastructure that facilitate rapid development, extension and deployment of network services. The design of Wrens is based on four principles. First, the communication structure of services should be specified explicitly in a form that can be understood by the infrastructure. This allows the infrastructure to automatically instantiate complex services, detect many kinds of failures and (in many cases) automatically repair them. In addition, it allows service designers to rapidly prototype services by plugging together existing service components. Second, complex services should be constructed as a collection of interacting service modules that communicate via named channels. Service modules written in this manner are easier to plug together since the interactions between such modules are limited to explicitly named channels. Third, the level of interaction between end-user applications and the communication infrastructure should be raised -- instead of being limited to asking for a communication channel to a specific server, applications should be able to request a named service. This facilitates service evolution as the structure and the implementation of a service can be changed without changing the requesting application. Furthermore, this provides an opportunity for the infrastructure to transparently handle many kinds of faults. Finally, the specification and implementation of services should use symbolic names wherever possible. Symbolic names provide a level of indirection that allows the infrastructure to transparently adapt a service to varying levels of resource availability with relative ease. We describe our prototype implementation of the Wrens framework and report our experiences with developing and deploying a diverse suite of services. Our experience has been positive. We were able to develop these services in a short time. We were also able to develop useful extensions for several of these services in the matter of a few hours. We also present an evaluation of the overheads introduced by the Wrens framework and the costs of end-to-end operations.