Architecting Manageability

Systems that people build are inherently manageable, device builders always provide at least a simple UI or a set of CLI commands. Unfortunately, the question of "how manageable" is rarely asked except through requests for functionality from customers. I figured I would brainstorm some facets of manageability and what it means to me as I've approached from the bottom -> up (building a NAS-like appliance) as well as the top down (attempting to build a higher level management application that devices can plug into).

Consider the following management components of a device or application:


  • Management User Interface - Does it manage one instance of a device, or many? Can new functionality be plugged into it without a forklift upgrade or is it a monotlithic software package? Is there centralized access management for all of the devices in the network? What about for all of the management user interfaces (if you require more than one), can you configure security for the network or do you have to deal with security for each installation?
  • Management API - Is there one available for the device or application? What aspects of the device or application can be accessed for management, here are some categories: health, capacity, security. Is it a read only management API or can characteristics of the device or application be modified?
  • Standard Protocol for the API - Is a standard protocol like XML over HTTPS (REST) or SOAP used so people that want to use the API don't need your protocol libraries? How high up does your standard protocol go, to XML, to a special comma delimited format over XML that you use? If you are a device vendor, do you use SNMP to deliver traps so your events can be integrated with most management tools?
  • Standard Management Model - Can a vendor well-versed in standard management models for your domain interact with your device or software at a "basic" level without even picking up an API document? Can a tool that leverages standard protocols and models for your domain "automatically" manage your device or software? To access your "value added" functionality in your device or software, does someone have to learn an entirely new "theory of operations" or can they use a basic theory that is common in a standard (such as the "Recipes" and "Models" used in SNIA's SMI-S)

I split the categories of manageability up like the above for a specific reason. The "resistance" to each of those categories is substantial in engineers and in architects. Whereas one engineer or architect may easily recognize the need for a management API, only a select few recognize the value of a standard protocol. Even fewer recognize the value of the standard management model.

A second reason for the category separation from above is the barrier to entry. An engineer or architect can "create" more and spend less time learning and adopting the lower they stay on the manageability scale. It is fundamentally easier to create a user interface (the first time) if I am not negotiating a (perceived to be) bloated standards-based model of management. Unfortunately, this "ease" of creation and unwillingness to research and use off the shelf standards is only an illusion. As a device or software component matures and becomes weaved into a management ecosystem, anything that was originally done in a proprietary way slowly evolves to carry the characteristics identified above (if its going to be truly successful, especially in enterprise datacenters).

I've blogged about the benefits of adopting standards early in development before.

In smaller businesses, those that are trying to run a start up, it may make sense to gradually move up the scale of manageability. This is especially the case if you are part of a start-up trying to navigate the waters of small business where there may be no large, deployed management ecosystem.

For larger companies that build applications and devices, having a high level of manageability for their devices shows a maturity in understanding that their devices will have to play well with others. This maturity often implies a heavy amount of work on "non datapath" engineering efforts. User Interface maturity, planned event handling and codes fired off through SNMP traps, a well-planned management API so the device or software can be plugged into management applications, an accessible CLI so those crazy script loving (IT'S A JOKE) system admins can integrate the device and software with their existing "simplifying" scripts, the list goes on.

Increasingly we should be looking at how to ensure devices and software play well with a single access management solution. Having a proliferation of NAS devices, each with their own user id's and passwords can start to get unwieldy. If each software element and each hardware element in a datacenter requires separate management of credentials, separate roles, separate concepts of access rights, something is broken. There are different people managing differing things in a datacenter and they have different rights to what they manage or look at. But why should security have to be configured for every single device and software element? Access management can help create a more secure (through simplifying management) environment. Treat it as part of architecting manageability as well. Access management can be applied to agent tiers, management APIs, user interfaces as well as to datapath.

Gotta run!

Comments:

Post a Comment:
Comments are closed for this entry.
About

pmonday

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today