Containerized Architecture
Architecture Summary
The following diagram depicts the high-level architecture of the Capacity Private Cloud containerized platform. It shows how client applications can integrate with speech and voice biometrics products through the available APIs.
The following sections discuss the different components of this diagram in more detail:
- APIs
- Required external software (including persistent storage)
- Other recommended external components (monitoring, logging, and access control)
- Licensing service
- Containerized microservices
The admin portal and communication protocols are covered in their respective articles.
APIs
These public APIs are exposed by the platform's containers to enable applications to utilize the available services.
- Speech API — Used for all speech product functionality. This collection of APIs can be used to consume the speech products: ASR, Transcription ASR, TTS, CPA, and the NLU gateway.
- Biometrics API — Used for voice biometrics products. It is used to perform active voice biometrics enrollment and verification transactions.
- Management API — A REST API that provides external access to the Deployment, Configuration, and Engine Resource services. Used to manage configuration and deployment parameters, which can also be managed via the Admin Portal and the Deployment Portal.
- Reporting API — Used to extract session and transactional data from the platform. There is a Reporting API for speech and a Reporting Bio API for voice biometrics. The Reporting API for speech is a REST API that connects via gRPC to the reporting service and databases.
For more information on the APIs and how client applications can interact with them, visit the API documentation at developer.lumenvox.com.
External Service Prerequisites
The following external software components are required. These components have been selected as prerequisite solutions supporting complete functionality, scalability, and resiliency in the containerized architecture. They are available as open-source or as cloud-managed services from major public cloud providers. Partners or clients are required to implement these as a prerequisite.
In a production environment, a distributed cluster for each is recommended (as opposed to a singular instance) to ensure high availability, scalability, and disaster recovery.
RabbitMQ — Message Queuing
This message queuing component, to be implemented independently by the client or partner, is used for all internal messaging between the microservices — including the queuing of all transaction, audit, and management information. Once a service processes the data requests, the messages are removed from the queue. These messages are proprietary to the platform's internal services and should not be used by clients.
Redis — In-Memory Cache
This in-memory data structure store acts as a database cache. It holds the session, audio, interaction, and other proprietary metadata used when processing interactions. It is used for caching session and transaction information throughout the architecture for the duration of its processing by the various internal services. This metadata is proprietary and should not be used by clients.
MongoDB — Database
A document-oriented database used as a repository for session binary data. The platform stores audio, grammars, and SSML files in a binary, encrypted format. This information is stored for audit and troubleshooting purposes and is used to determine and refine product performance using the Analysis tool. Audio file storage is configurable. The data stored in this service is proprietary and should not be accessed by clients.
PostgreSQL — Database
A SQL-compliant relational database used as a repository for persistent metadata, licensing, and reporting data. The platform stores all transactional data here. The data stored in this service is proprietary and should not be accessed by clients.
Persistent Storage
In addition to the required components above, customers should provide persistent storage (1 TB recommended) from a provider of their choosing. This is required for storing ASR and TTS models as well as grammar files. Data stored on this service is proprietary and should not be accessed by clients.
Other Recommended External Components
Monitoring Tool — such as Prometheus
Prometheus is a time-series database used throughout containerized and cloud environments and is the de facto standard for metrics tracking. It can be visualized using graphical interface tools like Grafana. Prometheus is commonly used for monitoring overall system performance (e.g., CPU status). You can set up alerts to send messages or emails and access its dashboard at a pre-configured URL.
Prometheus has the advantage that managed versions are available from most major cloud hosting providers, such as Amazon, Google, and IBM.
The platform has out-of-the-box support for Prometheus. A list of available metrics can be obtained from Technical Support.
Logging Tool
Customers are required to supply their own logging tool to retrieve and analyze container logs. All containers log information in a standard format that can be consumed by your logging tool of choice.
Access and User Management
Customers must provide their own access management interface. The platform does not provide user identification (authentication) or permission checking (authorization) for access to the APIs used to access the containerized products — this is managed by the security systems the client has in place.
Licensing Service
To use the platform's products, the containers are required to communicate with the cloud licensing service to submit information on product utilization. This outbound connection is made using secure HTTPS, typically once per day, and contains no user-identifiable information (only license usage metrics).
Customers need to ensure that external firewall rules are configured to allow this outbound connection.
Containerized Microservices
At the heart of the platform are the microservices in a containerized architecture. For more information about the microservices, visit developer.lumenvox.com.