Everything about Web and Network Monitoring

Dependence on Vendors

Every tool we use on our websites makes us dependent on the creator and supplier of that tool. Examples:

  • If our website uses HTML/CSS, we are dependent on the World-Wide Web Consortium.
  • If our website uses PHP, we are dependent on The PHP Group.
  • If our website uses Red Hat Linux, we are dependent on Red Hat, Inc..
  • If our website uses Apache, we are dependent on The Apache Software Foundation.
  • If our organization uses MySQL, we are dependent on Oracle Corp.

This is a very short list and it does not list all the dependencies for each tool, but it does illustrate the point – we are dependent on the creators and suppliers of the tools we use (including tools that are incorporated into other tools in a dependency hierarchy).

Effects of Dependence

Dependence is unavoidable, but it does affect our website. Here are a few effects to consider:My Way or The Highway- If the tool we use could serve us better in some other way, we can suggest a change, but there is no guarantee that the controlling organization will do what we want. The needs of the community of users take priority over our needs. If we cannot work within those confines, we cannot use the tool.Likewise, if the controlling organization decides to change the interface or functionality of the tool, we mustadopt those changes. If this means rewriting code, then that is what we must do. Fortunately, controlling organizations recognize this, and try to avoid changes that affect previous standard usage. They do not always succeed.Scheduling Updates – Pretty well every tool requires updates, some more often than others. If the updates are scheduled by someone else, they may happen at times we find inconvenient. Many controlling organizations now allow us to schedule our updates, which helps, but we cannot delay them for too long because of security concerns.Training – Updates may change the interface or functionality of the tool, which means our people will need to be retrained. “Our people” obviously includes those who provide content or initiate transactions, but also includes our end users and our technical specialists. Ideally, training should occur before we update the tool.

Loss of Control – Performance, security, confidentiality, and scalability may be important to us, but if the tool provider does not share our concern to the same degree, it may only pay lip service to these requirements or may provide limited functionality.

Sudden Loss of Supplier – If a supplier disappears (e.g., bankruptcy, loss of community support), the impact can be sudden and severe, or merely a nuisance. Measure the impact on this scale:

  1. Immediate Loss of Functionality – As the supplier disappears, so does its website. If the tool won’t run without that website, we lose use of the tool immediately and our website no longer works properly.
  2. No More Modifications – The tool does not require the supplier’s website, but the tool cannot be modified or updated because we do not have the source code or permission to modify it. [This is one reason open-source software is gaining popularity over closed-source.]
  3. No More Updates – We have the source code and permission to modify it, but we must make the changes ourselves. As long as it’s working the way we want, we’re okay, but we won’t be receiving any more updates.
  4. No Impact – The tool works and we require no change to it, even in the long run.

Conclusion

Websites depend on a myriad of tool suppliers. Tools can be programming languages, markup languages, content management systems, database management systems, code libraries, data libraries, cloud-based processing, network components, operating systems, hardware, and on and on.Before committing to a tool, research the supplier’s long-term sustainability. Go with tools that have lots of users rather than obscure tools that no one has heard of. In this case, #1, #2, and #3 are probably better than #22 or #1099.To no one’s surprise, I recommend monitor.us and Paid Monitor for cloud-based website monitoring. They’ve proven themselves in the past, and seem to be viable in the long-run. Not only that, but their system allows us to monitor anything.
Post Tagged with

About Warren Gaebel

Warren wrote his first computer program in 1970 (yes, it was Fortran).  He earned his Bachelor of Arts degree from the University of Waterloo and his Bachelor of Computer Science degree at the University of Windsor.  After a few years at IBM, he worked on a Master of Mathematics (Computer Science) degree at the University of Waterloo.  He decided to stay home to take care of his newborn son rather than complete that degree.  That decision cost him his career, but he would gladly make the same decision again. Warren is now retired, but he finds it hard to do nothing, so he writes web performance articles for the Monitor.Us blog.  Life is good!