Product Entitlements Service #
Description #
The Product Entitlements Service is designed and built to act as a read-only System-Of-Record (SOR) repository for the SpheraCloud suite for serving product entitlements to callers.
The Product Entitlements service is focused primarily on the need to be able to map a company to a list of products that they are enabled to use as part of the SpheraCloud suite. The basic functionality utilizes a corporate or company id for a given user to make the call which brings back a list of products. Some, none, or all of the returned products will have an associated license object which can be used to indicate that a particuar product is enabled for a customer (and thus their users).
A secondary ability of the Product Entitlements service is to provide user-specific mappings of products that they have previously integrated with their SSO credentials. A list of user=specific products (and their respective links) can be retrieved by either a separate API Call or part of a combined call with the primary user-case above.
The primary consumer of this service is the home screen application which displays all products available that the user can choose from.
Design and Operational Assumptions #
The following assumptions were used in the design and build of the Product Entitlements service - all requirements driven by functionality defined for the home tiles screen:
- Each user in the system (Latitude) will be associated with a single company only.
- The tiles application will show all licensed products for a given company with a live link.
- The tiles screen will also need to return/display a list of all applications regardless of whether they are registered with a marketing ink;
- A company is a single entity, NOT broken down into further sub-divisions.
- A product, for the purposes of this service is a singlar object NOT broken down into sub-modules that are entitled independently.
- Product versions are managed by creating a separate product in the system with a differnt name encompassing the version number.
UPDATE 4/17/2020
The additional requirements have been added to also allow products to be tied to a specific user based on whether they have completed SSO integration. Assumptions used in creating this functionality are:
- Users and associated products can be created/updated via the API based on external events beyond the scope of this service.
- The user-linked products will show an appropriate url link and title value for all products that have been linked.
- External sources (the applications themselves) will publish events asynchronously to when an initial SSO linking has occurred.
- The service will listen for these events and perform appropriate operations to ensure that the SOR is maintained properly.
- The external process for triggering the addition of a user has yet to be defined.
Design Principles #
This service was focused on addressing 5 basic pillars that define a well architected cloud application. Creating a software system is a lot like constructing a building. If the foundation is not solid, structural problems can undermine the integrity and function of the building.
When architecting technology solutions for the cloud, if you neglect the five pillars of operational excellence, security, reliability, performance efficiency, and cost optimization, it can become challenging to build a system that delivers on your expectations and requirements. Incorporating these pillars into your architecture helps produce stable and efficient systems. This allows you to focus on the other aspects of design, such as functional requirements.
See more information about Sphera’s 5 pillars approach to design here.
Serverless approach #
The term serverless has two distinct but related meanings:
- Backend as a service (BaaS). Back-end cloud services, such as databases and storage, provide APIs that enable client applications to connect directly to these services.
- Functions as a service (FaaS). In this model, a “function” is a piece of code that is deployed to the cloud and runs inside a hosting environment that completely abstracts the servers that run the code.
Both definitions have in common the idea that developers and DevOps personnel don’t need to deploy, configure, or manage servers. This reference architecture focuses on FaaS using Azure Functions, although serving web content from Azure Blob Storage could be an example of BaaS. Some important characteristics of FaaS are:
- Compute resources are allocated dynamically as needed by the platform.
- Consumption-based pricing: You are charged only for the compute resources used to execute your code.
- The compute resources scale on demand based on traffic, without the developer needing to do any configuration.
Functions are executed when an external trigger occurs, such as an HTTP request or a message arriving on a queue. This makes an event-driven architecture style natural for serverless architectures. To coordinate work between components in the architecture, consider using message brokers or pub/sub patterns. For help with choosing between messaging technologies in Azure, see Choose between Azure services that deliver messages.
Additional details and considerations about serverless technologies on Azure are discussed in more detail here.
Architecture Overview #
The primary architectural components that make up the Notification Service are:
| Component | Technology | Description |
|---|---|---|
| Api Gateway | Azure API Management | An API gateway that acts as a front-end to the solution APIs. Among many other benefits, the API management service provides SpheraCloud APIs with security verification, usage telemetry, documentation and rate limiting. |
| Notification APIs | Azure Functions | A single set of Function Apps are deployed to serve Sphera’s Notification APIs: send, change, and read. This API is exposed to consuming applications via the API manager and provide CRUD operations for each of Notification entities. |
| Pub/Sub | Azure ServiceBus | This service leverages Azure ServiceBus Topics and Subscriptions to manage all non-read related activities within the notification system. This provides for a completely asynchronous approach for repository writes without affecting performance for read operations. |
| Repository | Azure SQL as a Service | Acting as a fully compliant SQL Server with automated backups and redundancy handled by Microsoft Azure. |
Sphera decided to use the following criteria to determine when a certain piece of functionality is to be considered a Microservice:
- The functionality must be able to scale or be deployed independently from other parts.
- The functionality must/can be written in a separate language/technology like Node.js in case there is some certain expertise that is only available in that specific technology.
- The functionality must be isolated by a clean boundary (bulkhead).
- Circuit-breaker functionality must exist when internal components interact with each other.
High-level Logical Architecture #
The high-level architecture and decision making process in selecting technologies and approaches for this effort can be found here.
Essentially, all choices were run past the Sphera 5 Pillars approach to design to help identify the best candidate technologies to use balanced against business needs. The number one consideration, as always, when designing software is does this add business value? Whenever possible, candidate technology or competing possible approaches were weighted towards using native Azure PaaS functionality rather than self-managing or building comparable features when all other factors were equal.
Normal Operation #
The product entitlements service standard operational diagrams and workflows can be seen here.
This link provides information on the sequence of operations that service incorporates to complete a given business task.
SpheraCloud EventHub (ServiceBus) Operation #
The details as to the messaging format and behaviors for servicebus interactions with the service can be found here.
