Ten years ago, legacy management software vendors were busy building Franken-Monitors. Those Franken-Monitors now consist of legacy management offerings that are neither well integrated, nor in any way able to keep up with pace of innovation in the industry. In order to survive your transition to the software-defined data center and the cloud, you will need a management software strategy and a management software architecture that will allow you to keep up with the pace of change without buying or building a Franken-Monitor.
The History of the Franken-Monitor
Before there were the Internet, n-tier applications, client/server, and the PC, there was a computing industry that consisted of mainframes and minicomputers. To give you some idea of how much things have changed, the following companies are no longer in the mainstream computer business: Burroughs, Unisys, NCR, Control Data, and Honeywell have all exited the mainframe business, and DEC, Wang, Data General, Prime, and Datapoint were all minicomputer companies that now cease to exist.
But there were management software vendors back then. And when the PC and client/server (Windows on both the desktop and on an Intel-based server) came along, management software had to grow up and adapt in a hurry. Tivoli was actually a hot management software startup that was established to address both Windows and Unix-based client/server architectures. And as we all know, IBM acquired Tivoli. And the first Franken-Monitor was born. It took IBM years (decades) to fully integrate Tivoli with its mainstream systems management offerings. As new things came along, like the Web, Java, service-oriented architectures, and now the cloud and a whole bunch of new languages, IBM and the other major systems management companies (BMC, CA, HP, Compuware) all acquired more and more startups to address new trends in systems and applications architecture. So, over time, the frameworks from the major systems management companies all became horribly complex Franken-Monitors. Modern Franken-Monitors have two huge problems. Their pre-existing components are not well integrated, and they cannot keep up with the pace of innovation in the industry. They are both horribly complex and always behind. Which means that Franken-Monitors create serious problems for the customers that rely upon them.
Building Your Own Franken-Monitor
Even if you have managed to avoid having a management framework (Franken-Monitor) inflicted upon you by your executives when they bought one on the golf course and jammed it down your throat, you may still have managed to get one. This is because the failure of frameworks to meet the needs of the people who support various elements of the hardware and software stack lead many different groups in companies to buy their own tools. Even in companies that had no framework, the decision on what tools to purchase was often distributed throughout the IT organization, allowing many different groups to purchases tools independently of each other—tools that were, of course, in no way integrated with each other.
The need for departments in companies that have frameworks to buy tools that really meet their needs, and for departments in companies that don’t have frameworks to buy tools that really meet their needs, results in the Build Your Own Franken-Monitor case. The real issue here is that the way in which most enterprises buy management tools almost guarantees that they end up with a Franken-Monitor.
Are We About to See Franken-Monitor, The Sequel?
We are at an unprecedented place in the history of the management software industry. In the past as new requirements emerged, startups emerged to address those requirements, and those startups got acquired by larger publicly traded software vendors, leading to the first generation of Franken-Monitors. The new requirements for management software are so different than the old ones that we have already seen two significant new management software companies go public: SolarWinds and Splunk. SolarWinds has already done a series of acquisitions (Hyper9 for Virtualization, Confio for Database Performance, Tek-Tools for Storage Monitoring) and has as of yet done a very poor job of integrating anything new into what they already have. Therefore, if SolarWinds continues on its current path, it might become the first new vendor of a Franken-Monitor in the last fifteen years. Splunk just made its first acquisition, BugSense. Splunk is in the unique position to avoid the Franken-Monitor problem, because it already has a big data back end into which all of the data from all of its partner products and its own products can be consolidated.
Where this will get interesting is that it is rumored that both AppDynamics and New Relic will go public next year. New Relic has a program like Splunk that allows third-party vendors who collect various kinds of monitoring data to put their data into New Relic’s back end and surface it in New Relic’s console. Similarly, AppDynamics has a program that also allows complementary vendors in the ecosystem to integrate their data into AppDynamics. Splunk, New Relic, and AppDynamics all have tremendous opportunities to replace legacy frameworks (and Franken-Monitors) with their ecosystem-based offerings, but they are going to have to be very careful not to build new Franken-Monitors in the process.
VMware faces similar challenges and opportunities. vCenter Operations is a mashup of CapacityIQ (internally developed) and Integrien, ConfigureSoft, and N-Layers (all acquired). VMware also has to rationalize the role of Log Insight in its management suite. As of right now, VMware deserves credit for having integrated the source technologies behind vCenter Operations to a reasonable degree. But there is a long way to go, as vCenter Operations still has too many databases and too many consoles as a part of the offering. VMware has the advantage of being great at managing its own platform, but it is therefore nowhere close to vendors like Splunk, AppDynamics, and New Relic, which are running effective ecosystem strategies. The great opportunity and challenge for VMware is to leverage Log Insight into a multivendor ecosystem play that gives Splunk, AppDynamics, and New Relic a run for their money.
Avoiding the Franken-Monitor
All of this results in a very interesting question. How do you put together a monitoring strategy (and yes, you do need a monitoring strategy to properly capitalize upon the software-defined data center and the cloud) that allows you to keep up with the ever-accelerating pace of innovation in the industry and which results in an integrated approach to solving problems in your enterprise? The following approach is suggested:
- You need a monitoring strategy and a monitoring architecture. You need to have a plan for how you are going to monitor new things as they arrive (and arrive they will) without creating either an out-of-date monitoring system or a completely disjointed and unintegrated Franken-Monitor.
- You need to recognize that no single vendor is going to be able to monitor your entire stack consisting of all of your software and all of your hardware. This is the great failure of the management frameworks. They promised this to customers and were unable to keep that promise because no single vendor could ever keep up with the pace of innovation across the entire computing industry. Any vendor that makes this promise today is lying, since the pace of innovation is both very high and accelerating.
- Given that no single vendor is ever going to be able to meet your needs, you need to be able to buy specific products that monitor specific things.
- These specific products cannot be management silos. They cannot just put their data in their own database and make it accessible only via their own user interface or console.
- You need to recognize that due to the diversity, distribution, scale, and rate of change in your environment, monitoring will have to be done with high fidelity (monitor everything) and great frequency. This turns monitoring into a big data problem.
- Therefore, your monitoring strategy and architecture needs to be anchored by a vendor with a big data back end and an ecosystem strategy that allows third-party vendors to put their data into that back end.
- Only with a common big data back end which is used for mutual benefit by all of your management software vendors will you be able to manage your future environments, which are going to consist of rapidly changing and highly distributed software-defined data centers that you own and clouds that you rent.
Avoiding the Franken-Monitor with the Reference Architecture for the SDDC and the Cloud
The best way to avoid the Franken-Monitor is to adopt a reference architecture for your management stack that is identical or similar to the one below.
The key attributes of this architecture are that all of the management products in the architecture put their data into one common back end, and that every product can query and reuse the data from every other product. This allows you, the customer, to plug new management products into your management architecture as new requirements arise. This is the only known and viable strategy for ending up with an integrated solution to monitoring that can easily adapt to the pace of innovation and change in the industry.
You can read more about this reference architecture in the following posts:
- Building a Management Stack for Your Software Defined Data Center
- The Big Data Back End for the SDDC Management Stack
- SDDC Operations Management
- SDDC Infrastructure Performance Management
- SDDC Application Performance Management
- Software Defined Data Center Analytics
- Software Defined Data Center Cloud Management
- SDDC Automation and Orchestration
- The New Management Platforms for the SDDC Management Stack and the Cloud
- Management Frameworks Will Die
- What Is Going to Replace the Legacy Management Frameworks?
If you have a Franken-Monitor, you should get rid of it. If you do not have a Franken-Monitor, you should avoid buying or building one at all costs. The correct approach is to use a strategy and an architecture like the one shown above to procure a set of best of breed solutions that can easily be integrated into a common big data back end datastore.