From Silos to Services: Cloud Computing for the Enterprise

May 21 2016   11:01AM GMT

Can Enterprises Keep Up with Frequent Upgrades?

Brian Gracely Brian Gracely Profile: Brian Gracely

Cloud Foundry
Managed Services
Public Cloud

Upside-Down-Planter-285x380For many years, I worked for technology vendors in roles that involved building new products and then trying to get businesses to buy and use them. A good portion of my time was spent talking to IT organizations about all the new features we had available and why they would want to use those features to solve a problem they had. To support this effort, we made tons of PPT slides and brought out extremely detailed roadmaps of what the next 6-12-18 months would look like.

But here’s where reality used to set in:

  • About 70-80% of customers were running software that was at least 2-3 releases behind the “latest version”.
  • Regardless of what version of software the customers were running, the majority of them would only turn on about 30% of the features (mostly the defaults).
  • It was not unusual to see customers take 3-6 months, and sometimes longer, to test and validate a new release before it would go into production. And then there was the waiting period before an “outage window” was available for the update.

While this was equally frustrating for the vendors and the customers, the give and take or features vs. deployments sort of settled into a groove and the industry learned to deal with these realities.

Then software-defined-<whatever> and open source started to become more mainstream, which brought with them a completely different update model.

For example:

  • VMware hypervisor has a major release every 12 months, with a minor bug-fix release every 6 months.
  • OpenStack has a major release every 6 months.
  • Docker has updates every 1-2 months.
  • Technologies like Kubernetes and Mesos are releasing updates every 1-2 months.

Houston….we might have a problem.

The good news is that these newer technologies bring with them lots of tools and best-practices to adjust to the increased pace of updates. Stuff like:

  • Continuous Integration and Continuous Deployments (CI / CD) – tools like GitHub and Jenkins and JFrog and others to help send new software into a pipeline of tests and have them get deployed into Dev, Test, Staging and Production.
  • Automation – lots of tools like Docker, Chef, Puppet, Ansible, SaltStack to help automate deployments.
  • DevOps – the cultural phenomenon where Devs and Ops groups (or integrated into one group) work more closely together to collaborate around deployments.
  • Blue / Green Deployments  – the model where updates are deployed to a small % of the available resources to validate if the changes work in production – and then if things are good then the updates can be deployed to more / all the resources.

The bad news is that IT organizations will need to learn all these new techniques and tools if they want to take advantage of these new technologies.

…or they can look to various vendors and cloud providers that will deliver those technologies as a service.

…or they can just use public cloud services and not worry about maintaining any of them (updates included).

So before IT organizations start evaluating these new technologies, they need to evaluate how well they can introduce a very rapid learning curve of new operational models into their organization. Just figuring out upgrades might be enough to make them think twice about an DIY projects.

1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Blueturtle
    There is reason why people use caution before upgrading. What might be a more modern OS, might be more frustrating to use, more bugs and sometimes can cause the death of a computer.
    45 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: