Why 'Lift and Shift'​ becomes 'Crash and Burn'​.

Most motivational speakers, except Deepak Chopra who after all this time is probably still trying (and desperately failing?) to explain the connection between Quantum Physics and consciousness*, have an extra-ordinary skill: they use simple language to paint vivid relationships between animate and inanimate objects. For example, Norman Vincent Peale told us to "shoot for the moon and at worse, you land in the stars". Pure linguistic wizardry. Alas, such pearls of wisdom are abstract and their realization varies from person to person and even profession to profession - I doubt any astronaut would think "shooting for the moon" and "landing in the stars" is sage advice.

Moving an existing infrastructure from on-premise to cloud is one of those endeavors, where if you shoot for the moon, you pray hard that you land there, otherwise, you WILL end up over budget, beyond frustrated, and ultimately not be able to extract the benefits you hoped for.

*Note to Mr. Chopra: give it up already.

"Want to move to the cloud? Just Lift and Shift. Easy as pie. Right?"

Wrong.

The intentions behind deciding to move to the cloud are always noble: system resilience, infrastructure scalability, financially sensible, etc. These grand aims however mask a glaring concern: the significant difference in the way work is managed in the cloud versus on-prem.

For instance, let's start with the applications you intend to move to the cloud. Are you going to shift all the moving parts of your systems to the cloud or is there a sensitive database that has to stay on-premise? If yes, what are the acceptable limits for latency for the interactions between the on-prem database and in-cloud middleware? If there are performance monitors that balk at the users when the system functions slower, do you tweak them to scream later or do you disable them completely (because AWS promised you the best in class throughputs on data transfers?)

How do you intend to run a 'good enough' system integration test every time either the database or the application middleware code changes? What's 'good enough' anyway for cloud deployment? Is it 107 use cases for payment processing (because Interac APIs ask for additional headers for every raw payment being sent for verification) or 449 use cases for data security (because now you have to think about the man-in-the-middle when transactions leave a safe zone and travel back to the cloud)? When all is said and done and its time for deployment, do you move the source code or artifact items to the repository in the cloud (adding yet more surface area for security to monitor) or keep them on-prem because the configuration changes necessary for deploying to cloud from within are complicated?

Another big concern I faced when moving an application to the cloud had to do with auditing. Logs from a cloud deployment differed in structure from those we required for our homegrown auditing library (and a pretty strong one at that). The questions making the round had no easy answer: should we dismantle our tried and working approach and use the cloud log data as our ONLY source of information or should we add another data cleaning layer between cloud logs and our data stores? If we did that, are we going to ask all the other non-cloud systems to adopt the new cloud format for their logs because who knows, they will be moving to the cloud as well in a year? What happens to audit integrity and standardization if some of them won't? Typically, cloud applications have a different profile of events to track and monitor than on-premise deployments. Would we have to add these cloud-specific events in our audits replacing some other logs? Decisions decisions!

The only thing we control is the illusion that we have it.

With the cloud, you will lose some control of your environment. Accept it and better yet, get used to it. Your organization's operating model WILL change. Roles will evolve and responsibilities will be different and if anyone reading this knows a mildly painful yet extremely effective way of changing old habits in a workplace, please contact me to get free delivery of your unicorn.

If you fail to plan a move to the cloud, you plan to fail at it.

Getting swayed by bold claims of how easy it is to shift your work to the cloud is no one's fault (at least to an extent). That's the genius of marketing. They want us to underestimate the difficulty of the tasks that drive a successful cloud migration. Its only personal experience that lays bare the struggle organizations face with people not willing to give up control, planning and testing the process for migration, and then asking the support teams to accept the context switch they have to deal with every time an on-prem system with in-cloud tentacles has a problem.

Take your time, think through the challenges, bring your team along (old and young alike), and prepare to start small and end big.

I write to remember and if in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.