Abstract: The management of applications in a computing environment often involves a significant number of computing operations, such as acquiring the application, deploying data objects in various locations, and configuring the application with respect to the deployed device. Conventional computing environments may provide inadequate support throughout a typical application life cycle, especially for a computing environment distributed across many devices. Instead, the computing environment may be represented in a deployable object hierarchy that may be distributed to various devices. An application management service may therefore be provided to install representations of the application in the object hierarchy, and to support many other aspects of the application life cycle, such as application discovery, sharing, updating, and removal.

Abstract: Data services for workloads are often provided with a service level agreement specifying various performance guarantees (e.g., latency, availability, scalability, and consistency). Single-master architectures, in which updates t the data set are constrained to a single server, may limit the fulfillment of some performance guarantees. Presented herein are multi-master architectures, in which the server set is partitioned into at least two masters are permitted to update the data set and at least one non-master that is not permitted to update the data set. Non-masters that receive a request to update the data set forward the request to a master server for application to the data set. A master that receives the request applies it to the data set and propagates the update to other master and non-master servers. Conflicting updates may be resolved through a variety of conflict resolution techniques, optionally designating one master server as a conflict resolution server.

Abstract: The management of applications in a computing environment often involves a significant number of computing operations, such as acquiring the application, deploying data objects in various locations, and configuring the application with respect to the deployed device. Conventional computing environments may provide inadequate support throughout a typical application life cycle, especially for a computing environment distributed across many devices. Instead, the computing environment may be represented in a deployable object hierarchy that may be distributed to various devices. An application management service may therefore be provided to install representations of the application in the object hierarchy, and to support many other aspects of the application life cycle, such as application discovery, sharing, updating, and removal.

Abstract: A server set for a data set may designate a subset of “master” servers that update the data set in order to reduce data version conflicts involving mutually exclusive updates of the data set. Multi-master configurations may fulfill the performance constraints, and the subset of masters may detect and resolve data version conflicts. However, if multiple masters perform conflict resolution for a particular data version conflict, the resolution may produce inefficiency and redundancy (if the masters reach the same outcome) or additional data version conflicts (if the masters reach different outcomes). Instead, among the masters, a merge master may be identified that applies conflict resolution techniques to data version conflicts and forwards the conflict resolution outcome to the other masters for application to the data set to resolve the data version conflict. The other masters may temporarily store updates in a tentative update set until data version conflicts are resolved.

Abstract: Data services for workloads are often provided with a service level agreement specifying various performance guarantees (e.g., latency, availability, scalability, and consistency). Single-master architectures, in which updates to the data set are constrained to a single server, may limit the fulfillment of some performance guarantees. Presented herein are multi-master architectures, in which the server set is partitioned into at least two masters are permitted to update the data set and at least one non-master that is not permitted to update the data set. Non-masters that receive a request to update the data set forward the request to a master server for application to the data set. A master that receives the request applies it to the data set and propagates the update to other master and non-master servers. Conflicting updates may be resolved through a variety of conflict resolution techniques, optionally designating one master server as a conflict resolution server.

Abstract: The management of applications in a computing environment often involves a significant number of computing operations, such as acquiring the application, deploying data objects in various locations, and configuring the application with respect to the deployed device. Conventional computing environments may provide inadequate support throughout a typical application life cycle, especially for a computing environment distributed across many devices. Instead, the computing environment may be represented in a deployable object hierarchy that may be distributed to various devices. An application management service may therefore be provided to install representations of the application in the object hierarchy, and to support many other aspects of the application life cycle, such as application discovery, sharing, updating, and removal.

Abstract: Data services are often provided with various performance guarantees. Multi-master architectures, in which multiple master servers are permitted to update a portion of the data set, may facilitate some performance requirements, but may also lead to data version conflicts in which different masters have written different versions of one or more data items. Moreover, conflicts involving different data items may have to be resolved using different conflict resolution techniques. Therefore, various data items of the data set may be associated with a conflict resolution technique selected from a conflict resolution technique set, such as manual conflict resolution; a write order policy, such as last writer wins; a conflict resolution logic; and conflict resolution based on data types. A data version conflict may be resolved by identifying and invoking the selected conflict resolution technique that is associated with the data item, and applying the conflict resolution outcome to the data item.

Abstract: Distributed transactions are performed over a collection of servers operating as replicas of a data set, where a successful transaction involves meeting a quorum count of replicas that locally commit the transaction. However, performance constraints of data sets and consuming applications may vary (e.g., sensitivity to latency, scalability, and/or consistency), and the performance characteristics of the server set may be partly determined by the transactional commitment and quorum selection. The distributed transaction may be applied by designating the replicas as a set of followers and a leader that initiates the transaction and receives acknowledgments of local commits by each follower. On condition of the acknowledgments meeting a quorum count for the data set according to the performance characteristics of the application, the leader locally commits the transaction and delivers a result.

Abstract: The management of applications in a computing environment often involves a significant number of computing operations, such as acquiring the application, deploying data objects in various locations, and configuring the application with respect to the deployed device. Conventional computing environments may provide inadequate support throughout a typical application life cycle, especially for a computing environment distributed across many devices. Instead, the computing environment may be represented in a deployable object hierarchy that may be distributed to various devices. An application management service may therefore be provided to install representations of the application in the object hierarchy, and to support many other aspects of the application life cycle, such as application discovery, sharing, updating, and removal.

Abstract: An application on a device may interact with a document service that provides access to a document service. The interaction may occur in a variety of contexts, such as a device context (e.g., the document service and the application provided on the same device), a local context (e.g., via a LAN), and a remote context (e.g., over the Internet). It may be advantageous to adapt the interaction to the current context, while also providing a consistent application interface that alleviates the application from context-specific implementations, and also achieving this adaptation in a performant manner. These considerations may be achieved in a balanced manner by providing a set of runtimes, where each runtime mediates the application/document service interaction between the application and the document service in a contextually adapted manner. The device may automatically detect the context of the interaction and select a contextually suitable runtime to service the application.

Abstract: Data sets such as databases are often distributed over a number of servers, where each server stores a subset of records and an index that enables the server to locate the records in response to queries. However, tight coupling of indexing and storage may limit load-balancing, fault recovery, and distribution. Instead, the set of servers may be partitioned into a set of storage servers that store the records and a set of index servers of the index over the records. In a set that is decoupled in this manner, load-balancing may involve provisioning and locating index servers independently of the provisioning and locating of the storage servers in view of the particular sensitivities and tolerances of various applications. Additionally, the index servers may also utilize a data layout that is selected and adapted independent of the data layout of the storage servers and/or the schema of the data stored thereby.

Abstract: Data services are often provided with consistency guarantees of either strong consistency models, comprising uniform wall-clock consistency, or eventual consistency models, where temporary logical inconsistency is guaranteed to be resolved only after full data propagation. However, the performance characteristics of contemporary services often require an intermediate consistency model, where some aspects of the service have specific consistency expectations and other aspects of the service are flexible, such as bounded staleness (e.g., a maximum delay in reaching consistency); session consistency (e.g., individual sessions remain logically consistent, but ordering may vary across sessions); and prefix consistency (e.g., each view during a session is logically consistent, but ordering may vary between session views).

Abstract: The management of applications in a computing environment often involves a significant number of computing operations, such as acquiring the application, deploying data objects in various locations, and configuring the application with respect to the deployed device. Conventional computing environments may provide inadequate support throughout a typical application life cycle, especially for a computing environment distributed across many devices. Instead, the computing environment may be represented in a deployable object hierarchy that may be distributed to various devices. An application management service may therefore be provided to install representations of the application in the object hierarchy, and to support many other aspects of the application life cycle, such as application discovery, sharing, updating, and removal.

Abstract: Databases are often provided according to various organizational models (e.g., document-oriented storage, key/value stores, and relational database), and are accessed through various access models (e.g., SQL, XPath, and schemaless queries). As data is shared across sources and applications, the dependency of a data service upon a particular organizational and/or access models may become confining. Instead, data services may store data in a base representation format, such as an atom-record-sequence model. New data received in a native item format may be converted into the base representation format for storage, and converted into a requested format to fulfill data requests. Queries may be translated from a native query format into a base query format that is applicable to the base representation format of the data set, e.g., via translation into an query intermediate language (such as JavaScript) and compilation into opcodes that are executed by a virtual machine within the database engine.

Abstract: A data service may be distributed over a set of servers in order to provide a database with properties such as low latency, high availability, and support for various consistency levels. Presented herein is a particular architecture that promotes rapid provisioning to promote scalability and failover; adaptive load-balancing to accommodate fluctuations in demand; and resiliency in the event of various types of failure, such as network partitions or regional outages. For a service comprising a resource set, a container is provided that hosts a set of replicas of a partition, and that is assigned an allocation of computing capabilities of one or more servers. The resource set of the service may be distributed over the replicas of the container. Scalability is achieved by adding replicas to the container, and load-balancing may be provided by splitting, merging, or otherwise refactoring the partition to accommodate anticipated and unanticipated fluctuations in service demand.

Abstract: Workloads are often performed by a server set according to a service level agreement, and are often provisioned and load-balanced by dedicating selected computational resources (e.g., servers and bandwidth) for application to the workload. However, resource-based provisioning may not accurately reflect the computational resource expenditure of the workload, leading to overprovisioning or underprovisioning of servers for the workload. Instead, the workload may be evaluated according to a service unit as a measurement of a volume of computational resources consumed by a workload unit, including performance dimensions specified in the service level agreement. The service level agreement may indicate a service unit rate for the workload. The workload may therefore be allocated to a subset of servers in portions according to a service unit rate, where the sum of the service unit rates for the portions allocated to the servers satisfies the service unit rate specified in the service level agreement.

Abstract: Object-oriented application languages often provide resources to applications for accessing objects stored in the volatile application memory region, and, separately, for packaging objects for persistent storage and network transport by serialization and deserialization involving a storage format. However, this design creates discrepancies between the application language and storage format, and depends on affirmative serialization and deserialization by the application. Presented herein are techniques for providing object access to objects involving persisting the objects as documents in a document store, where such persistence occurs automatically upon object creation and updating, and where such objects are stored in a language format integral to the application language (e.g., when a JavaScript application creates an object, the objects are automatically stored as documents of the document store in a JavaScript Object Notation (JSON) format).

Abstract: A server set may provide a document service to various clients in view of considerations such as availability, fault tolerance, flexibility, and performance. Presented herein are document service architectures that involve partitioning the document set into at least two document ranges, and assigning the respective document ranges to an agent that is deployed to at least one assigned server. A request to apply an operation to a selected document may be fulfilled by identifying the document range of the document; identifying a selected server of the server set that hosts the agent to which the range is assigned; and forwarding the request to the selected server. In some variations, servers may retain detailed information about neighboring servers (e.g., according to logical and/or physical proximity) and scant information about distant servers, thereby avoiding both the extensive information exchange of highly informed network architectures and the inefficiency of uninformed routing algorithms.

Abstract: The management of applications in a computing environment often involves a significant number of computing operations, such as acquiring the application, deploying data objects in various locations, and configuring the application with respect to the deployed device. Conventional computing environments may provide inadequate support throughout a typical application life cycle, especially for a computing environment distributed across many devices. Instead, the computing environment may be represented in a deployable object hierarchy that may be distributed to various devices. An application management service may therefore be provided to install representations of the application in the object hierarchy, and to support many other aspects of the application life cycle, such as application discovery, sharing, updating, and removal.

Abstract: A distributed component model for creating a scalable and available distributed application is disclosed. The distributed component model provides for an application schema to be declaratively defined to include a module having a component. The schema includes a corresponding definition construct in a technology agnostic manner. The corresponding definition construct is declaratively defined to include metadata to control scaling and availability.