In all of life, we try to avoid the difficult things and handle the easy things first. Sometimes, leaving the hard things is a good idea. We sometimes realize there is an easy way to deal with the hard problem, or someone else deals with it. Sometimes it’s a bad idea. Leaving a sore tooth until it needs a root canal is a bad idea that causes lots of pain.
In my last cloud dependency article, I reviewed the need for ubiquitous networking. In this article, I look at the need for automated upgrades. I do not mean the need for automation in general, but specifically the need to automate any upgrade or update behavior. There are two sides to every cloud story: what the tenant does and what the cloud service provider does. In both of these stories, there is a need for well-planned, automated upgrades. Also needed is very good documentation on how to upgrade if the automation fails or if there is no easy way to automate. Upgrades should be bulletproof. We trust, but verify. Continue reading Cloud Dependency: Automated Upgrades
Let me start out by saying that I see more discussions about greenfield deployments of products than I do of migration/integration by vendors. Personally, I think there is no such thing as a greenfield deployment unless the organization is just starting out, creating a brand new data center, or perhaps has money to waste. In most cases, what is defined as greenfield is really just a grain of sand on an island of technology that still needs to integrate into the greater organization. As such, that integration should be the foremost thought when products are developed. But instead, it is not, and effort goes into becoming that island or into a replacement install that is still an island.