CumuLogic Architecture
The internal architecture of the CumuLogic platform is a robust framework for application deployment orchestration and modular service management. With a variety of deployment options available for advanced deployment configurations, the system can scale to meet the needs of any cloud operator or application team.
The CumuLogic controller includes the following core components:
Web-Based Console
The web-based console is an easy-to-use interface, supporting both CumuLogic administrators and the application owners using CumuLogic services.
The administrative interface provides:
- User administration
- Target cloud administration
- Service configuration
- Plug-in management
The user interface provides:
- Service catalog-style selection of pre-configured modular services
- Advanced instantiation and configuration of modular services
- Access to the Elastic WebStack composition tool for web applications
- Account management for setting or changing target cloud credentials
API Server
The API layer for CumuLogic includes a set of RESTful web service endpoints for instantiating and managing all applications and services controlled by the CumuLogic platform. It also provides administrators with APIs to control and configure all aspects of the CumuLogic platform.
Control Plane
The control plane is the heart of CumuLogic’s orchestration capabilities, owning all job initiation and monitoring functions for the platform. It takes inputs from the API (based on user driven requests for action), as well as the autoscaling and health monitoring services. It is also responsible for ensuring that pre-scheduled jobs like database backups are performed at the expected times.
The health monitoring service is responsible for tracking all application and service instances deployed by CumuLogic platform, and directing the controller to take the appropriate remediate actions when problems arise. The autoscaling service tracks monitoring data as well, but is responsible for triggering scale-up and scale-down operations within the environment. The usage tracking service tracks all change events, and allows operators to use this data to perform chargeback and billing functions.
Persistent Storage for the Controller
While the CumuLogic platform does not operate in the data path of any user applications or services, it does need to persist several different artifacts in order to achieve its goals.
Controller Database
The controller relies on a MySQL (or compatible) relational database for its configuration and activity tracking. In simple deployments, this can be a single MySQL server installed on the same VM as the controller. For higher availability or performance, this database is typically separated from the controller itself and configured as a cluster.
Snapshot Storage
The CumuLogic controller, by default, will store all service snapshots on locally mounted storage. This can be either a local drive, or a remote NFS mount. Additionally, the controller is able to use S3 compatible object storage services for this data.
Repository
The repository is the location that all software requires to instantiate modular services (database software, message queue broker software, etc). This repository needs to be available as a storage mount point on the controller’s host operating system.
CumuLogic Instances
CumuLogic “instances” are virtual machines that have been requested by the controller from a target cloud. They are typically sourced from a single “master” template on that target cloud, and are the basic unit of deployment for any node of an application or modular service provisioning process. Since the CumuLogic controller communicates with the target IaaS environment on behalf of the user requesting the service, each instance is deployed within that account in the IaaS environment.
Tenant isolation relies on the isolation method of the underlying IaaS, but the use of virtual machines instantiated on behalf of the requesting user provides flexibility in how applications are constructed. It is possible, for example, to have a database service be instantiated by the CumuLogic platform, while the application itself is provisioned manually onto virtual machines created by the user within their IaaS environment.