eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
[WP_IMAGE]
Last week CA announced ten new or updated products as part of a”cloud choice” product release. Over the coming weeks, I’ll be taking a first look at several of the new releases and sharing my initial findings here at the eWEEK Labs blog.
One of the things I’ve discovered already is that some of the announcement covers actual products, and some of the announcement covers “sausage casing.” By “sausage casing” I mean that CA Automation Suite for Data Centers 12.5 and CA Automation Suite for Cloud 1.0 are agglomerations of four other CA products. The chief difference between the two products is that “for Cloud” also contains CA Service Catalog, while “for Data Centers” does not. As I wade through the CA cloud-connected product onslaught, I’ll attempt to sort out the genuinely new or significantly enhanced products and features from those that may have been given a cloud gloss. I’ll also be taking a stab at the licensing details and implementation considerations of each of the product components. In particular, for mature products, I’m interested in what significant, technical changes have been made to make the product now cloud worthy.
Here are some of my assumptions about what these changes might be. 1. Before, “machine non-responsive” or “heartbeat not received within specified time parameter” equals machine down and a red dot on the management interface. Now, “machine non-responsive” requires an interrogation of vCenter or an equivalent virtualization manager. Is the virtual machine in shutdown in compliance with resource use policies or did it crash? Is the virtual machine here or was it moved to a different location?
2. Before, “network interface non-responsive” kicked off a set of timers to see if the interface was flapping, actually not responding or downstream of a known failed connection. This type of “root cause” analysis suppressed error message flooding by pinpointing the actually failed interface while ignoring sympathetic error messages from downstream network devices that were likely still up and running but blocked by the failed device. Now, “network interface non-responsive” requires an interrogation of the virtual distributed switch or equivalent virtual network environment to augment root cause anaylsis.
3. Before, systems, operating systems, applications, and networks came up and stayed up until they died. The time and cause of death was usually unambiguous. Log files that come to a screeching halt are second only to the first telephone call from a complaining user in determining when a system went down. Because support contracts usually mandated that a single server be dedicated to a single application, determining the cause of death was also a relatively uncomplicated affair. Now, systems, operating systems, applications, and networks are balled up into a “workload.” Workloads can be running or not running for a number of reasons, almost all of which can be traced back to capacity needs or human forgetfulness. Measuring service level compliance is a more complicated matter in this environment.
If you have other ideas on what to look at in comparing and contrasting traditional vs. cloud-connected management systems, please comment here or send me a note at [email protected].