Components of a management suite: 

Problem statement: This article describes some of the salient features and best practices for the implementation of a management suite whose design was referenced here. The simplest operations manager is a single management group for a set of managed objects whose details and state are maintained in a database and managed by a single server or microservice.  

Architecture: The core components of a management server usually comprise a scan engine, a collecting server, and a user interface.   The scan engine evaluates based on policies that can be specified as conditions. Conditions are built on predicates and can be independent of one another. These predicates are simple boolean operands and can be stored in a database as a regular text column that is parsed before applying or executing the queries. The order of execution of the logic follows the listing order of the rules. Old rules can be deleted, and new rules can be added. The output of the rules evaluation determines the result of the scan. The scan engine design model can optionally provide the ability to run one rule or all rules in the listing. It can even organize the rules in suites. These suites can be created thematically depending on the type of scan to be performed.  

The user interface exposes the types of rule categories on a dashboard so that the user may select one of them to execute. The invocation of a category displays a progress bar for the scan. The evaluation of the scan results in a set of findings and results. These findings are listed based on the source data that failed the conditions associated with a check. There is a correlation between the check and the finding so it is easy to navigate between the two. Similarly, there is a correlation between the finding and the result, and it is easy to interpret the result with transitive correlation to the check which may also describe a remedial action to be performed. All the checks, findings, and result entries are stored in tables in a database, so they are flexible, dynamically updated, and specified in large numbers. The user interface can enable the view of the grouped objects. 

The remedial actions on the managed objects might be taken independent of the management suite, so it is helpful to run these scans multiple times to see improvements in their state. The repeated runs of the management suite can be seen from the new entries in the database tables.  

The operational aspect of the management suites may be exposed via a dashboard that lists the number of scans, their breakdown by successes and failures and if necessary, the execution time. These statistics can also be aggregated based on the last week or last month so that the runs and their corresponding numbers can be viewed over a period.  

Tasks and the corresponding invocations on the managed objects are left out of this discussion but they are briefly described here as asynchronous tasks that may need to be repeated over the members of a group of managed objects. A message broker helps tremendously in the tracking of asynchronous tasks, especially in a fan-out model. This message broker may also have an associated set of processors that update state in a transactional database.  The state of the managed objects can then become the source of truth for the management suited. 

Conclusion: Some of the components of a management suite are described here. The management suite can be expanded with the addition of serverless computing or microservices for added functionality.