CA Technologies and "cloud choice"
Cameron Sturdevant is the executive editor of Enterprise Networking Planet. Prior to ENP, Cameron was technical analyst at PCWeek Labs, starting in 1997. Cameron finished up as the eWEEK Labs Technical Director in 2012. Before his extensive labs tenure Cameron paid his IT dues working in technical support and sales engineering at a software publishing firm . Cameron also spent two years with a database development firm, integrating applications with mainframe legacy programs. Cameron's areas of expertise include virtual and physical IT infrastructure, cloud computing, enterprise networking and mobility. In addition to reviews, Cameron has covered monolithic enterprise management systems throughout their lifecycles, providing the eWEEK reader with all-important history and context. Cameron takes special care in cultivating his IT manager contacts, to ensure that his analysis is grounded in real-world concern. Follow Cameron on Twitter at csturdevant, or reach him by email at cameron.sturdevant@quinstreet.com.
Email
Print
A sticky note diagram of CA's July 27th "cloud choice" product announcement shows a great deal of overlap between a couple of Automation Suites.
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 csturdevant@eweek.com.
