The design of a management suite over MDM   

Problem statement:  

Management of monitored agents and devices is a critical aspect of many software products. They are referred to as operations manager or system center and provide a single console to view and edit the inventory. Additionally, tasks can be performed on the managed objects in the local management group by specifying them on the console.  Objects may be grouped, and actions can be taken collectively on this group so that they need not be repeated on one member after another.  

This article describes some of the salient features and best practice for the implementation of a management suite. 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 of a scan engine, a collecting server, and a user interface. The server imports collected scan data from all the managed objects into a database. The user interface allows that data to be studied and the issues to be resolved by performing tasks on the managed objects. The argument we make here is that this datastore is best replaced by an MDM. Furthermore, web applications and services that do not have transactional semantics access storage that is conducive to an object store. A management suite has specific separation of concerns between the read-writes performed for state management versus the read-only reporting stack. An MDM with its family of RESTful API services, is well suited for utilization as management offering over the inventory of managed objects and devices. MDM has traditionally proven effective in organization of inventory. For example, a product catalog stores details on items sold by a business such as Name, Code, Category, Sub-Category, Standard Cost and ListPrice. Since large businesses have a lot of merchandise differing in categories, styles, color, grade, model, make, serial code, the catalog needs a lot of organization to properly access an item.  Such catalogs often require storage upwards of terabytes of data and were previously stored in relational databases. 

Yet the nature of access on this data has traditionally been read-only.  Moreover, since the catalog is large, their browsing is more filtered than a retrieval of all items.  The catalog operations involve searching, grouping, and sorting based on criteria that look remarkably like SQL queries. These queries, the massive catalog of products and the organizational requirements are challenges that do not necessarily need the encumbrance of a relational database management system and can be exclusively handled and better served with an object store. 

Object Storage is a limitless storage. The storage is elastic, and the addition of capacity is as trivial as adding nodes to a cluster. The object storage does not differentiate between the nodes because the storage pool virtualizes all the storage. Therefore, a product catalog can grow to any size while the physical storage array lends itself for easy maintenance.  

An Object Storage offers better features and cost management than most competitors such as relational databases, document datastores and private web services. The existence of catalog in the market on a variety of stacks and not just the Master Data Management software providers indicate that this is a lucrative and a commercially viable offering. From database servers to an appliance, the catalog is viewed as a web accessible storage, but it provided with form of constraints to its access. Object storage not only facilitates its access but also provides no restraints on its access. It does not treat the catalog as a mere content and provides redundancy as a content distribution network.