• Abstract and Figures
• Public Full-text

Customizable and Extensible Deployment for Mobile/Cloud Applications Irene Zhang Adriana Szekeres Dana Van Aken Isaac Ackerman Steven D. Gribble∗ Arvind Krishnamurthy Henry M. Levy University of Washington Abstract between application requirements and deployment de- cisions leads programmers to mix deployment decisions Modern applications face new challenges in manag- with complex application logic in the code, which makes ing today’s highly distributed and heterogeneous envi- mobile/cloud applications difficult to implement, debug, ronment. For example, they must stitch together code maintain, and evolve. Even worse, the rapid evolution of that crosses smartphones, tablets, personal devices, and devices, networks, systems, and applications means that cloud services, connected by variable wide-area net- the trade-offs that impact these deployment decisions are works, such as WiFi and 4G. This paper describes Sap- constantly in flux. For all of these reasons, programmers , a distributed programming platform that simplifies phire need a flexible system that allows them to easily create the programming of today’s mobile/cloud applications. and modify distributed application deployments without Sapphire’s key design feature is its distributed runtime needing to rewrite major parts of their application. system, which supports a flexible and extensible deploy- ment layer for solving complex distributed systems tasks, This paper presents Sapphire, a general-purpose such as fault-tolerance, code-offloading, and caching. distributed programming platform that greatly simplifies Rather than writing distributed systems code, program- the design and implementation of applications spanning mers choose deployment managers that extend Sapphire’s mobile devices and clouds. Sapphire removes much of kernel to meet their applications’ deployment require- the complexity of managing a wide-area, multi-platform ments. In this way, each application runs on an underlying environment, yet still provides developers with the fine- platform that is customized for its own distribution needs. grained control needed to meet critical application needs. A key concept of Sapphire’s design is the separation of 1 Introduction application logic from deployment logic. That is, deploy- ment code is factored out of application code, allowing the In less than a decade, the computing landscape has programmer to focus on the application logic. At the same undergone two revolutionary changes: the development time, the programmer has full control over deployment of small, yet remarkably powerful, mobile devices and decisions and the flexibility to customize them. the move to massive-scale cloud computing. These changes have led to a shift away from traditional desktop Sapphire’s architecture facilitates this separation with applications to modern mobile/cloud applications. a highly extensible distributed kernel/runtime system. As a consequence, modern applications have be- At the bottom layer, Sapphire’s Deployment Kernel come inherently distributed, with data and code spread (DK) integrates heterogeneous mobile devices and cloud across cloud backends and user devices such as phones servers through a set of common low-level mechanisms, and tablets. Application programmers face new chal- including best-efforts RPC communication, failure lenges that were visible only to designers of large-scale detection, and location finding. Between the kernel and distributed systems in the past. Among them are coordi- the application is a deployment layer – a collection nating shared data across multiple devices and servers, of pluggable Deployment Manager (DM) modules offloading code from devices to the cloud, and integrating that extend the kernel to support application-specific heterogeneous components with vastly different software deployment needs, such as replication and caching. DMs stacks and hardware resources. are written in a generic, application-transparent way, To address these challenges, programmers must make using interposition to intercept important application numerous distributed deployment decisions, such as: events, such as RPC calls. The DK provides a simple yet powerful distributed execution environment and API for • Where data and computation should be located DMs that makes them extremely easy to write and extend. • What data should be replicated or cached Conceptually, Sapphire’s DK/DM architecture creates a • What data consistency level is needed seamless distributed runtime system that is customized These decisions depend on application requirements – specifically for each application’s requirements. such as scalability and fault tolerance – which force diffi- cult performance vs. function trade-offs. The dependency We implemented a Sapphire prototype on Linux servers and Android mobile phones and tablets. The ∗Currently at Google. prototype includes a library of 26 Deployment Managers 1 supporting a wide range of distributed management tasks, Shared such as consistent client-side caching, durable transac- Durable Store Backend tions, Paxos replication, and dynamic code offloading Services between mobile devices and the cloud. We also built 10 Cloud Server-side Sapphire applications, including a fully featured Twitter Frontend Application clone, a multi-player game, and a shared text editor. Servers Code Our experience and evaluation show that Sapphire’s extensible three-layer architecture greatly simplifies Mobile Client-side Client Application the construction of both mobile/cloud applications Devices Code and distributed deployment functions. For example, a single-line application code change – switching from one Figure 1: Code for today’s applications spans cloud servers DM to another – is sufficient to transform a cloud-based and mobile devices. Client-side code runs on varied mobile multi-player game into a P2P (device-to-device) version platforms, while server-side code runs in the cloud, typically that significantly improves the game’s performance. The using shared backend services like distributed storage. division of function between the DK and DM layers REST [25] and SOAP [62] or libraries like Java RMI and makes deployments extremely easy to code; e.g., the Thrift [3] for distributed communication, load-balanced DM to support Paxos state machine replication is only servers for scalability, client-side caching for lower 129 lines of code, an order of magnitude smaller than wide-area latency, and systems for notification [1], a C++ implementation built atop an RPC library. We coordination [9, 33], and monitoring [18]. also demonstrate that Sapphire’s structure provides Sapphire provides a flexible environment whose fine-grained control over performance trade-offs, deliv- extension mechanism can subsume the functions of many ering performance commensurate with today’s popular of these systems, or can integrate them into the platform communication mechanisms like REST. in a transparent way. Programmers can easily customize The next section provides background on current the runtime system to meet the needs of their applications. mobile/cloud applications and discusses related work. In addition, programmers can quickly switch deploy- Section3 overviews Sapphire and its core distributed ment solutions to respond to environment or requirement runtime system. Section4 presents the application changes, or simply to test and compare alternatives during programming model. Section5 details the design of development. Finally, Sapphire’s Deployment Manager the Deployment Kernel, while Section6 focuses on framework simplifies the development or extension of Deployment Managers, which extend the DK with distributed deployment code. custom distributed deployment mechanisms. Sapphire’s prototype implementation is described in Section7 and 3 Sapphire Overview evaluated in Section8, and we conclude in Section 10. Sapphire is a distributed programming platform designed 2 Motivation and Background for flexibility and extensibility. In this section, we cover our goals in designing Sapphire, the deployment model Figure1 shows the deployment of a typical mobile/cloud that we assume, and Sapphire’s system architecture. application. Currently, programmers must deploy appli- 3.1 Design Goals cations across a patchwork of user devices, cloud servers, and backend services, while satisfying demanding We designed Sapphire with three primary goals: requirements such as responsiveness and availability. For 1. Create a distributed programming platform span- example, programmers may need to apply caching tech- ning devices and the cloud. A common platform in- niques, perform application-specific code splitting across tegrates the heterogeneous distributed environment clients and servers, and develop solutions for fast and and simplifies communications, code/data mobility, convenient data sharing, scalability, and fault tolerance. and replication. Programmers use tools and systems when they match 2. Separate application logic from deployment logic. the needs of their application. In some cases an exist- The application code is focused on servicing client ing system might support an application entirely; for requests rather than distribution. This simplifies pro- example, a simple application that only requires data gramming, evolution, and optimization. synchronization could use a backend storage service 3. Facilitate system extension and customization. The like Dropbox [23], Parse [53] or S3 [58]. More complex delegation of distribution management to an exten- applications, though, must integrate multiple

Load more

  16

Copy Link