Architecture

YaaS Architecture

The following content describes a high-level overview about the architecture of SAP Hybris as a Service (YaaS) and the fundamental principles upon which it is built.

Services in YaaS

The core design principles of YaaS are based on the microservice architecture style, which enables you to build a flexible API on the SAP Hybris scalable platform, and then publish it.

Software is often bundled into components that use various technologies. The microservice architecture is another method of partitioning software into smaller and independent manageable artifacts. With this approach, you can develop a single application as a suite of microservices. The advantages of using the microservice architecture is that each application can do the following:

• Run its own processes
• Communicate with standardized, lightweight HTTP mechanisms
• Expose its functionality through a RESTful API

In addition, traditional microservices have the following features that are also beneficial to YaaS users:

• They serve only a well-defined functional scope.
• They have a small and easy-to-understand code base.
• They have a separate life cycle, so they can be managed and evolve independently.
• They are loosely coupled, which decreases the impact of failures on the whole system.
• They are built with a technology stack that meets the business requirements.
• They are easy to scale, replace, and deploy.

The microservices architecture style is based on standards, widely-accepted technology, and design principles for the interaction between services. The style provides the flexibility to use any technology to implement each specific microservice. Therefore, there is no learning curve for developers to learn new technologies. Instead, every provider of a microservice has the freedom to choose the technology, programming language, and development tools to fulfill their business requirements and find the best fit for their application domain. The anatomy of a microservice consists of three simple layers, as described below:

• RESTful APIs – Implementation that exposes business functionality as a web resource
• Business Logic – The actual implementation of your business requirement
• Integration Logic – Used when the service needs to interact with databases or other services

Service Design

When it comes to the design of these services, SAP Hybris strictly follows the Twelve-Factor methodology. The SAP Hybris [y] Factors document explains organizational, architectural, and other service design topics.

Service types

The YaaS architectural approach defines two technical types of services, as described below:

Independent Services – These services may still maintain their own backing services, such as native databases. The backing services are not shared across multiple services and are operated by the same team operating the service. These are self-contained services and do not have any dependencies on other services:

Dependent Services – These services leverage other services to provide high-level services. To function correctly, these services depend on those other services:

On a larger scale, the service ecosystem of YaaS provides a set of building blocks to create a wide range of applications in an efficient and flexible manner. They are categorized into three clusters:

1. The core functionality cluster, shown in the bottom layer, provides a wide range of reusable services, such as an email service or document repository service. The services in this cluster provide general purpose functionality and are independent from any business domain.
2. The domain cluster, shown in the middle layer, provides services focusing on a specific domain, business, or commerce functionality, such as the product, catalog, or pricing services.
3. The orchestration cluster, shown in the top layer, provides high-level services to build domain-specific applications by leveraging and orchestrating the services from both of the other clusters.

From a technical perspective, all services in the YaaS ecosystem are categorized into multiple types of services, as described below:

• Core services – A set of core services are provided to implement basic functionality, such as a repository, search capabilities, and messaging. All of these services are ready for the cloud and help you speed up your project implementation because you reuse the existing functionality instead of developing your own.
• Domain-specific business resource services – Every business domain has a well-defined set of domain objects. In the commerce world, these are objects such as carts, products, and prices. Each business domain resource service handles a specific domain entity. These services mostly implement basic CRUD functionality, as well as providing basic functionality related to a domain object.
• Domain-specific business services – A pure business service focuses on an actual implementation of some concrete business functionality, such as calculation of taxes and shipping price. It’s valid for a business service to also act as a CRUD service.
• Domain-specific business mashup services – A service that aggregates information from multiple other services, such as a service that relays data to a customer’s browser, or a service that orchestrates a business process across multiple services, such as a checkout process that uses cart, price, and tax services.

Service Communication

Services in YaaS use two mechanisms to communicate with each other:

• Synchronous HTTP/ REST requests
• Asynchronous message-based communication

HTTP/REST

The primary communication channel used in YaaS is pure HTTP. Each service exposes its web resources through well-defined RESTful APIs.

All of these APIs are described with RAML in a natural and intuitive way. In addition to the web resources that implement its API, each service also exposes its own RAML API definition through HTTP. It also exposes a RAML API console, which enables API consumers to browse through the API documentation and interact with the service API directly.

The exposed API of a service is not directly accessible by a service consumer. Instead, there is always a component called an API proxy in front of it, as shown in the diagram below with the Document service:

Each request reaches the API proxy, which analyzes and verifies certain request parameters and headers. Then, the API proxy forwards the request to the service implementation. The API proxy serves the following purposes:

• Enforces security
• Enables central logging and tracing
• HTTP header rewriting
• Ensures platform resiliency by implementing the rate-limiting and circuit-breaker mechanisms

In order to work with YaaS, you should fully understand how the API proxy changes incoming requests and how they are received at the service implementation side. Detailed technical information can be found in the security documentation.

Messaging

In addition to synchronous HTTP communication, services in YaaS can also communicate asynchronously using the central Publish and Subscribe (PubSub) messaging infrastructure service. Services can publish information to specific topics being managed in the central messaging infrastructure, and other services can subscribe to those topics. When a message is published to a specific topic, it is automatically available to subscribers. The messaging provides a high-level and cross-boundary exchange of asynchronous events, which is a fundamental requirement for building flexible, loosely coupled, and highly-saleable solutions.