Before You Do That 'Lift & Shift'​ Cloud Migration...

'Lift Shift' migration is to cloud architects as Mjolniris to Thor;indispensable and used often at whim. Lift and Shift migration is the cloud migration strategy that involves moving an application to a cloud platform almost exactly as it runs on-premises. This often means you are moving a bunch of virtual machines and try and stitch the inter-dependencies that existed on-premises in a cloud platform. Read on and we'll explore why this is one of the most popular migrationstrategies and why you should try and move away from this model and explore newer options. The popularity of this model is deeply rooted in the fact that this probably is the easiestcloud migration approach.Consider almost any monolithic application, you can break it down into itsmultiplelayers like;web tier, app tier and the database tier. Oversimplifying this comes down to identifying stateless and state-full components that make up the application. A load-balancer takes care of stateless components; say a web server farm. And, a cluster takes care of state-full components; like your database. Replicating this to cloud as is, is what gets described as a successful lift and shift. This is the average cloud architect's answer to Gillette's engineer adding the fifthblade to the Mach5Turbo-whatever razor, because five is the number after four. There is nothing new in this approach, and hence you get almost the same result that you would have gotten on-premises.It totally works! But, since when is 'just works' enough? How do we do the next gig? The cloud migration talent pool is categorized into infrastructure architects (IT pros) and application architects (developers).Most of the cloud migration projects are dominatedby infrastructure architects, this means they talk the language that is familiar to them; which is VMs, networks, load-balancers and the likes. The irony is, radical breakthrough innovation that comes about in the most of the popular cloud platforms come in the form a managed/packaged PaaS service, and the infrastructure side of cloud platforms go through mere incremental innovation. Take the case of Azure HDInsight;a managed Hadoop environment that can scale to handle petabytes of data. From the view of an IT pro familiar with managingserver nodes of a Hadoop cluster, its storage, networking and associated virtualizationwill envision a ton of VMs stitched together in a cloud platform when a cloud migration opportunity arises, which is a lift and shift migration. But a developer or an application architect couldn't care less for those VMs, networks and theSAN devices. The language of managed and packaged services is closer to a developer, and is natural to adopt such services, like HDInsight from this example or Amazon's RDS or Event Hubs or SQL Azure etc. This makes a drastic difference in the benefits you'll get from your cloud solution; like the time to market, the operational expenditure, the need for manageability, lock-in, ROI etc. Most of the managed services available in cloud platformsis a wrapper that focuses on providing immediate value to the customer using theapplication. All of theaspectsof setting up and managing underlying core infrastructure is taken care of by the cloud provider. Leveraging such services gives you access to some of the coolest engineering feats at a marginal cost. Next time you're tasked with a migration project, consider breaking the application down to its physical components, which is almost how it is running on-premises. Further this by breaking it down to logical components to explore PaaS alternatives to perform the same or similar function; like say consider betweena mail server VM and SNS in Amazon. The former is too predicable and expensive, the later is cheaper, easier to manage and setup. In a cloud world, the customer is paying for every bit of resource being consumed for, this means a heavier object like a virtual machine that contains the operating system is costlier than a PaaS alternative. There are options like containers or Microservices that could be an alternative that consumes much lesser CPU and memory in comparison to a full-blown VM. The key takeaway is that the line between infrastructure architects and developers isthinning; it should and will continue so. There should be a conscious effort to learn and discover every opportunity, features and components to get rid of those VMs for a more advanced, cheaper, more value oriented packaged cloud service. With every solution you build; ask if thatis truly the best acustomer can get?. Or, is it justanother blade accompanied byan aloe strip? We are limited by what we know and our solutions should not get crippled by traditional datacenter problem solving approaches. AsMaslow pointed out "If a hammer is the only tool you have , everything will look like a nail" Even if that's Thor's Mjolnir.