Nagios forked by Icinga, GroundWork’s POV

May 6, 2009 – 8:34 pm by David Dennis

Since the recent announcement of the Icinga fork of the Nagios project, a number of customers, community members, analysts, and journalists have asked what this means for GroundWork.

As most of you are probably aware, Nagios is an important component of GroundWork Monitor, and one of the many valuable pieces of open source software used in various manners across the GroundWork Monitor product family, along with GroundWork’s own code.

First and foremost: GroundWork has no intention of taking sides in whatever feud(s) might exist between Nagios and Icinga.

GroundWork has a history of working with multiple open source projects (such as RRDtool, Cacti, Ganglia, BIRT, and many others). Whatever developments might be forthcoming from the Icinga team shouldn’t conflict with that philosophy and, in fact, may lead to new avenues of cooperation and sponsorship.  In the area of Nagios plugins, in particular, there may be much mutual common interest.

Some other questions that have been asked:

If I decide to use Icinga, will I be able to then migrate to GroundWork, as I currently can with Nagios?

The short answer: Until Icinga is released, we won’t really know for sure.

The slightly-less-short answer:  If Icinga achieves its stated goal of being completely compatible with Nagios, it has a decent chance of working in one fashion or another.  What we don’t know yet is if the process would be the same as migrating from vanilla Nagios, or would require some extra steps.

Will GroundWork be including some or all of the Icinga project into the GroundWork Monitor family?

At this juncture, it’s way too early for us to know or say.

If there is something in the Icinga project you’d also like to see in GroundWork Monitor, let us know.

If there are other questions we didn’t answer, feel free to ping us, either in the comments below, on Twitter @davidpdennis or email ddennis at gwos dot com.

Thanks,

David

Farewell Cassatt, Lessons Learned

April 27, 2009 – 6:10 pm by David Dennis

Bill Coleman, BEA founder and CEO of Cassatt, said in a Forbes interview today that Cassatt is “close to an end” after burning through nearly $100MM in funding.  The Register has followed up with their own commentary.

Having followed (and sometimes positioned against) Cassatt for years, watching its unraveling has been an educational experience. Despite technology that was perhaps too far ahead of its time, Cassatt’s business practices often seemed the opposite: an old school 20th-century big dollar enterprise software model trying to compete in the 21st-century world of asymmetrical business and technology tactics.

So with a bit of melancholy (I’ve been in their shoes and know their pain), I bid farewell to Cassatt and am drawn to lessons we can learn from their demise:

1. Rip and replace doesn’t work. Boiling the ocean doesn’t work. The combination of the two really doesn’t work.

It didn’t work for HP’s cancelled Utility Data Center, it hasn’t really worked for IBM’s Autonomic Computing, and now it hasn’t worked for Cassatt.

If your product’s main value proposition depends upon people jettisoning wholesale what they’re using now (and incurring switching costs), with no way to get ROI incrementally, it’s a near impossible sale.

2. Corollary to #1: You need to play nicely with what people have.  Especially if you’re a startup trying to penetrate the enterprise data center.

Integrating to other IT operations management systems in the data center is key here, and one way to deliver incremental value.

Open source solutions need to pay particular attention to this, as there is often a religious conviction against integrating with proprietary systems.  Get over it.

3.  IT departments and sys admins won’t change their (buying, tool, technical) habits just because you invented something neato.  Doubly true if it’s neato but expensive.

4. In the 21st century, people expect to try your software, use it, and then (maybe) buy something.  Big paid proof of concepts as a way to get hands-on product experience is going the way of the dodo.

Despite having $100MM in funding, Cassatt couldn’t get beyond “about a dozen very large customers”.

I suspect Cassatt was probably too large and complex to easily make into a downloadable product.  But doing something to get it into the hands of the masses and get some grass roots traction could have done wonders.

5. If you need to make a Hail Mary, try going open source.

Where might Cassatt have been if they had released their product as open source a year or two ago?  Where might they go in the future if they do so now?

In addition to the comments below, you can tweet me @davidpdennis or mail me at ddennis at gwos dot com.

David

The Open Source Honey Blender

April 24, 2009 – 6:23 pm by David Dennis

Thanks to the thoughtful posts of Roberto Galoppini About the Open Source Whole Product Concept, I’ve just finished reading the latest, version 2 of James Dixon’s The Bees and the Trees.

Over a great dinner at the Water Bar with Roberto after the Open Source Think Tank last March, I remarked to him that the creation of open source taxonomies can turn into an intellectual game that is mostly followed by pundits, becomes a bit silly if taken to extremes, and is of questionable relevance to customers.

So now, after reading The Bees and the Trees, I’m going to do the very thing I was skeptical about last month and sketch out another open source business model taxonomical distinction. (I’m sure there will be those among the readership who think we need this about as much as we need yet another Linux distro).

I think there is another model between James’ Beekeeper (single vendor) model of commercial open source and the Dixon/Aslett Honey-Gatherer (services/support) model of commercial open source.

I call it the Honey Blender.

[Warning: the commentary below assumes you've read The Bees and the Trees.]

Like a blended scotch whiskey, a “whole product” offering can be made by combining the honey made by domesticated bees (a la the Beekeeper model) and by gathering wild honey (a la the Honey Gatherer).

GroundWork follows this model, although we’ve tended to call it the ‘amalgamation strategy’, while Roberto has referred to it as a ‘hybrid production model‘.

Red Hat is also a Honey Blender, combining code made in their own beehive with code developed in the GNOME, GNU, etc beehives into a whole product.

In this model, the customer still gets honey and the honey ‘comes in a jar’ (per Dixon). However, because the honey comes from many different sets of bees (domesticated and multiple wild beehives), the Honey Blender needs to be able to interface with and nurture many different bee populations.

This is definitely more complicated than the Beekeeper approach, but it does yield a wider mix of honey/code flavors that can be combined to make the whole product.

Also, because not all of the bees are domesticated, it allows for leaner business operations and more efficient engineering, the savings of which can be passed along to the commercial customers.  In fact, in the monitoring space, one can argue that a single vendor approach is going to have a hard time reinventing the wheel from scratch in a way that can compete cost-effectively with the sunk costs of code and breadth of features already written (often over decades) by the likes of HP OpenView, IBM Tivoli, and the other ‘Big 4′ systems management vendors.

For complex categories like enterprise data center management (encompassing monitoring, asset management, trouble ticketing, provisioning, etc) the Honey Blender approach may be the only realistic option.

Feedback? In addition to the comments below, you can tweet me @davidpdennis or mail me at ddennis at gwos dot com.

David

GroundWork Adds Tap In Cloud Management

April 19, 2009 – 10:42 am by David Dennis

GroundWork is pleased to announce the availability of Tap In System’s Cloud Management Service via the GroundWork Exchange.

Tap In’s CMS option adds Amazon EC2 cloud management features to the core monitoring functions of GroundWork Monitor 5.2.1 or higher:

  • Monitors cloud infrastructure status
  • Measures cloud-specific instance metrics
  • Maps and tracks dynamic host name and IP address changes
  • Itemizes Amazon EC2 billing
  • Allows cloud-based systems to be managed alongside traditional systems

GroundWork will also be holding a webinar featuring an overview of Tap In’s CMS and a live demo.

Date: Tuesday, April 21

Time: 9:00 AM Pacific

You can go here for more details and to register.  We hope to see you!

Survey Results: Community Edition (GWMCE) Downloaders Do More with Open Source

April 10, 2009 – 10:29 am by Tara Spalding

GroundWork conducts an ongoing community edition downloader survey that provides a better understanding of how GWMCE is used and how GWMCE can be improved.

Here are some of the monitoring trends reported from our first round of results.

The IT environments that GWMCE monitors are complex, heterogeneous, and require a high level of functionality and reliability from GWMCE. This competency is valued more than accessibility to tools and libraries.

  • Almost half of the GWMCE installers monitor a significant percentage (over 25%) of their environment with GWMCE.
  • 63% of the monitored nodes are servers, 24% are network nodes and 13% are other devices
  • As organizations have a higher monitored node count (over 300 devices), the network nodes gain a greater share (35%) of monitored devices, and servers reduce to 49%.

Surprisingly, the most monitored OS by GWMCE is Windows at 52.6%, second is Linux at 38.9%. Other OS like Unix, Solaris and others account for the remaining 9%.

Looking at the community’s ranked product values – accessibility to libraries for monitoring diverse environments are less important (ranked #9 out of 12) as product working as advertised and easy custom monitoring techniques (#1 and 2 out of 12).

This datapoint can be interpreted that the ability to customize and amply do the monitoring competently outweighs the accessibility of external resources such as libraries and tools.

Would you agree?

This survey is managed by Matt Lawton of Sample Analytics.If you have downloaded GWMCE, you may participate in the survey – by starting here.

New GroundWork Monitor 5.3 Community Edition VMware Appliance

March 30, 2009 – 5:32 pm by David Dennis

GroundWork is excited to announce that the recently released GroundWork Monitor 5.3 Community Edition is now available as a VMware Virtual Appliance. The is a perfect opportunity for new users to try out the latest version of GroundWork Monitor Community Edition without the hassle of configuring a dedicated machine.

Why the GroundWork Monitor Community Edition 5.3 VMware instance?  Compared to the earlier version of the virtual appliance, users get:

  • Increased Scalability: Approximately 50% increase in out-of-the-box box throughput compared to GroundWork Monitor 5.2
  • Nagios 3 Support: GroundWork Monitor Community Edition 5.3 now includes Nagios 3 built-in.
  • Updated Open Source Packages: GroundWork Monitor 5.3 includes updates to key Open Source projects including, RRDTool, MySQL, BIRT and PHP. These updates add functional improvements and bug fixes and security improvements as part of our ongoing security improvement process.
  • Network Service Notification: The new Network Service feature provides alerts about software updates and patches directly to administrators within the GroundWork Monitor interface.

And there’s more: check out the complete range of GroundWork Monitor Community Edition features.