Public Cloud's Dirty Little Secret

Lifecycle Management

Moving your applications to the cloud is a great way to eliminate technical debt and relieve yourself from needing to do infrastructure lifecycle management (LCM) – right?

You would have to dig deep to find any words to the contrary.

Your Responsibilities

The reality is that if you are re-deploying any of your applications to an Infrastructure as a Service (IaaS) cloud model, the responsibility for important pieces of infrastructure LCM is still yours!

Let’s look at what you must do if you have anything deployed on Centos 6 in Google Cloud Platform (GCP) as an example. Centos 6 is going End-Of-Life (EOL) (kind of a big story if you follow operating systems).  You need to:

1. Review the operating systems lifecycle and support policy (sounds ominous)

2.  If you will need to create VMs that use these Centos 6 images after the EOL date, make copies of the images in all of your projects

3. Plan and migrate your CentOS 6 workloads and applications to CentOS 8 before the EOL date. (No wiggle room here)

It sure doesn’t sound like you are out of the infrastructure LCM game. The same kind of procedures are needed for Ubuntu 16.04 LTS EOL, etc.  You have the same set of responsibilities with Amazon Web Services (AWS), and node types also get deprecated forcing you to do migration planning and execution.

The LCM issue that you are avoiding by moving to IaaS in the cloud is capital acquisition and deployment, but as you can see that is not the end of the story. 

What Next?

At PTS, we are working with clients on a daily basis in the depths of current and future LCM rollouts. We want to make sure that they don’t miss what their responsibilities in the cloud are going to be, and make sure that they continue to have synergy between their on-prem, cloud and MSP infrastructure lifecycle programs. 

Arrange a free workshop with our consultants via the link below to discuss your Cloud strategy.