NBA Hall-Of-Famer and 2001 league MVP Allen Iverson averaged more than 26 points a game during his career. He is recognized as one of the greatest to play his position. He is also well-known for his, “We’re Talkin’ ‘Bout Practice” rant (it’s on YouTube. Pure comedy). For multiple reasons, Iverson found little value practicing with his teammates as he felt he was “The Answer” (his actual nickname) to the team’s championship hopes. Even though it would have made the team more well-rounded, he didn’t feel the need to offload some of his offensive responsibilities to other players. Needless to say, Iverson never won an NBA title during his 17 year career.
I am seeing similar parallels with organizations which have “lifted and shifted” their legacy workloads to the cloud. While many have hit the traditional Day 1 problems such as buggy containers and the normal networking, hypervisor compatibility, security, compliance and performance issues, many are also experiencing buyer’s remorse once they get to the cloud as they have not fully embraced the risk of not making their workload stack portable from AWS to GCE or even back to private IaaS and have also overlooked the role of the existing staff of IT engineers in this journey.
In my opinion, cloud portability is a nebulous term. Products such as RightScale, Scalr, Morpheus and other cloud managers are excellent at moving workloads from one cloud to another but are actually only doing half the job. When advanced technologies such as SDN, container orchestration technologies, microservices and the constant churn of configuration updates and changes which impact the entire stack, it presents a lifecycle management nightmare. Manually updating cookbooks, manifests and automation runbooks and composing these operations in a monolithic format is an arduous chore and a huge time sink. Additionally, if the workload has been refactored for only AWS/Cloud Formation and a couple of months later consumption costs become unbearable, the customer is locked-in and any OPEX advantage hoped to be gained has evaporated. 
We are also seeing the traditional IT engineer squeezed out of the cloud movement- and they shouldn’t. While it is sensible for data centers to be consolidated (or shut down entirely) over a 3-5 year period, security, data locality, compliance and licencing are all major factors considering keeping some on-prem IaaS and physical gear. In the event in which a workload needs to be moved back to a VM cluster, private cloud or on bare metal, who is there to ensure that these important functions are addressed? While they are not coders or full-stack DevOps engineers by trade, with collaboration, intelligent automation tools which make the right provisioning and configuration decisions that follow a unified CloudOps model, IT engineers help DevOps teams focus on getting the cloud to where it needs to be and perceived CAPEX and OPEX benefits realized.
At RackN, we automatically abstract away the unknown complexities of cloud migration-to-production use cases and allow CIOs to continue to innovate, modernize and make portable their workloads and operational models. We believe the cloud and infrastructure underlay pertaining to platform portability and the traditional IT engineer are critical teammates needed to be part of a winning strategy even if Allen Iverson doesn’t think so.
About the Author:
Dan Choquette is Co-Founder/COO of RackN. With Allen Iverson as inspiration, Dan will continue to work on his jump shot (which is an effort in futility).