Service orientation is a design approach that focuses on the linkage between services and service-based development and the outcomes of those services. It is referred to as service-oriented architecture (SOA). A service does the following:

• Logically represents a repeatable business activity that has a specified outcome (for example, check customer credit, provide weather data, consolidate drilling reports)
• Is designed to be self-contained
• Is often composed of multiple different services
• Has its technical details abstracted from the service consumer

Cloud applications are organized as a service, or a set of services, and may use other services. Their most common characteristics include the following:

• Stable interfaces: Cloud application interfaces should not vary over time. Any variations should be backward-compatible. Component interface changes could require significant re-integration with other components, which could negatively affect lifetime cost.
• Described interfaces: Cloud application interfaces must be human- and machine-readable and describable. Human-readability is needed to support component acquisition and integration. Machine-readability is needed for dynamic service discovery and composition.
• Use of marketplaces: Application marketplaces afford easy and rapid access to cloud-based products and services. Using a marketplace, high product quality and consistent device compatibility are assured. They also provide user freedom of choice between competing products and reinforce application and data portability and interoperability.
• REST: Representational State Transfer (REST) uses uniform interfaces to provide cacheable, stateless, and layered client-server interactions. Using REST, every client-to-server request contains all the information needed to execute the request. It also enables robust, scalable, and loosely coupled services that contain stable interfaces.
• Base transactions: Cloud applications are usually designed to perform transactions with BASE properties: basic availability, soft-state, and eventually consistent. Traditional transactions follow ACID properties: atomicity, consistency, isolation, and durability. This means that transactions are reliable, but consistency is not possible without sacrificing availability. With BASE, replicated resources are allowed and at least one copy is available but other copies are temporarily in different states. Synchronization will, however, drive them eventually into consistency. Some applications require ACID transactionality. In others, components providing parts of the transaction can use BASE transactionality for interoperability with other components: