What is Lift and Shift, also known as rehosting? What alternatives are there to this method? And above all, what are the dangers and disadvantages of a migration approach focused only on one "layer" (IaaS)?
Many paths lead to the cloud
Rehosting (Lift and Shift)
In very simplified terms, this involves moving virtual machines from your data center to the cloud. Tools like Azure Migrate help map your infrastructure. In short, the application is hosted in a different hardware environment, namely that of the respective cloud provider, without any changes to its architecture. Migration is quick and relatively inexpensive, but it can be costly afterward because the cloud's efficiency is not being exploited.
Refactoring
With cloud-native tools such as Cloud Foundry or Open Shift
Classified under Platform as a Service (PaaS): Tools such as Cloud Foundry are used, which already force to adhere to the principles of the 12-Factor app.
The goal is to bring the application to "cloud native" status. (Glossary) to hoist.
Offline First
First, existing applications are modernized by changing or extending the code, then migrated to the cloud with rehosting or refactoring via Cloud Foundry / Openshift. Disadvantage here as well: In contrast to refactoring with Cloud Foundry, for example, there is a risk that refactoring will be necessary in the end if the launch does not run as smoothly as expected because the services do not meet the requirements of the 12-factor app.
Rearchitecturing
You may be forced to redesign some systems so they can be migrated. Elephant databases and heavily glued, monolithic code may need to be re-tailored to become cloud-native and to leverage techniques like containers and microservices.
Rebuild (Greenfield)
If the costs of rearchitecting are too high, it may be advisable - after a make or buy consideration (see next point) - to make a fresh start.
Replace (through SaaS)
After the make-or-buy consideration mentioned in the last paragraph, you may find that third-party apps can completely replace your custom apps.
A good acquaintance is CTO for an e-commerce company. He himself is a business information scientist with a lot of experience in the retail industry. When we met recently and I told him about my focus (cloud migration starting at the IaaS level) he replied succinctly:
„Your PaaS stuff is still too time-consuming for me, too, and I don't want to bother with it. If possible, I'll only use SaaS. I can use my developers better in the core business than training them to be PaaS guards.“
I could not object much to that, because he is right.
Whereas with PaaS he still needs relatively few "guards", with lift-and-shift he needs a whole colony of guards who monitor, SIEM, report and usually also have to stand toe-to-toe for 24 hours. In the project requests, this is always referred to as "Pickett".
„The option you choose should take into account business motivation, budget and schedule. It may be better to spend more time and money on restructuring services upfront to save money and achieve greater flexibility in the long run.“ Brett Hargreaves. Exam Ref AZ-304 Microsoft Azure Architect Design Certification and Beyond (Kindle-Positionen 4862-4863). Packt Publishing Pvt Ltd.
I am of the same opinion.
By catapult into the cloud
How does Lift & Shift work?
As already outlined above, L&S moves an application and the associated data to a cloud platform without touching the architecture of the application. Everything takes place at the IaaS level (Infrastructure as a Service).
What is IaaS?
With IaaS, the cloud provider takes care of all matters relating to the provision of the hardware and network infrastructure.
This includes power supply, cooling, capacity management, backup and fault clearance in the event of hardware defects, and firmware updates and patching. {Not of the operating system}
The availability and fault clearance times of the infrastructure are regulated via service level agreements (SLAs) between users and the cloud provider.
The user is responsible for the operating systems, the applications, data storage, possible encryption, user and rights management (IAM) and security aspects such as firewall configuration or compliance with data protection requirements.
Now you can guess three, no, only once (the answer is very simple, so three guesses would be too many), which of the XaaS models involves the greatest effort for the user.
The phases of a migration
Broadly speaking, any successful migration consists of the following steps:
Analyze / Evaluate
Migrate
Optimize
Supervise (Monitoring)
Dhe fact that actual migration is not the final step may seem strange to some.
But the reason for this should be obvious:
Every company has its own infrastructure fingerprint, unique, distinctive.
And its own set of motives.
X wants to move to the cloud to save money, company Y is essentially concerned with rapid scalability, while company Z is exposed to competitive pressure.
That means there's no one-size-fits-all solution for migration, and once it's done, it's impossible to accurately predict whether and how your uplifted systems will work in the cloud. As in the waterfall model (which I don't prefer in software development), once you've hoisted it up, you first have to test, monitor, and almost always post-optimize.
I've had a few SaaS permanent hire requests lately. Almost without exception, it was about L&S projects exploding in cost after migration because the rehosting approach didn't deliver the savings we had hoped for. On the contrary. Often, high-performance VMs are really expensive in continuous operation, and because on-premise bare metal and the cloud landing zone were often still running in parallel, the IT controller saw red.
Understandably so.
I hope that the hint with the fence post did not go unnoticed. If it did, I'll summarize again - a bit more metaphorically:
At L&S, the elephant is catapulted toward the cloud. And if it lands there - safe and sound - a helicopter squadron is sent after it to see how it's doing up there.
Analyze and evaluate
What is there to research, analyze and evaluate?
A hell of a lot!
Few applications run in isolation on a single server. Most are distributed across multiple servers; for example, web applications may consist of a web server frontend and a backend database.
And then we have the "messy dishes from the shared kitchen".
Shared Resources.
Want a real-world example?
At one customer, I was involved in the development of operational business application systems as an architect and developer. At this customer, system A spit out a file that was stored on a file server (a bit old-fashioned, I know, but this is still common practice). This file was then picked up by PLM systems B and C. And if the file ended up getting corrupted somewhere along the way, someone had to play Sherlock Holmes and follow the digital trail. But without his friend and assistant Dr. Watson, because monitoring in the form of logging existed only rudimentarily.
Extremely rudimentary.
What does that tell us?
It is not enough to just map, inventory the servers, databases and services, but also to create a dependency matrix and examine how the individual building blocks communicate with each other.
Firewalls, routers and their rules must be captured to ensure that they can still interact after migration.
IP addressing and DNS must also be taken into account.
How is subnet mapping done? Is the local network transferred to Azure as a flat network (a single subnet) or is it transferred fragmented into multiple subnets?
And what about Eddie end users?
At some point there will be a disruption of service, and depending on the complexity, more than one system may be affected if you and your crew are vigorously rehosting.
If Eddie Endnutzer is an investment banker with a focus on high-frequency trading, then it's recommended that his system not be down for too long.
Is there nothing from Ratiopharm?
Yes, but only when all other tools have failed.
Which would be (not conclusive, just the ones I know):
• Azure Migrate • movere.io (recently acquired by Microsoft) • Cloudamize • CloudPilot von UnifyCloud • ATADATA from Deloitte
Migrate
Now, I could explain this for Azure Migrate.
Also:
Create an Azure Migrate Server Assessment project in the azure Migrate blade of the Azure portal.
…
Stop.
My page is called "The Big Pictures" and not "The biggest details".
Besides, such a step-by-step guide is already outdated before I published it, especially since Azure (and certainly AWS and Google) are regularly tweaking the GUI.
So, I'll leave it at that.
The knowledge is best obtained from the provider directly.
The aforementioned tools already take a lot of work off your hands here, but without basic network knowledge and SQL basics, you'll be at a loss when it comes to error messages.
A propopos Tooling: What should be mentioned in this context is the recommendation to include the Azure Total Cost of Ownership (TCO) calculator {of course only if you decide to use Azure}.
While the azure Migrate report provides an estimate of the cost of ownership for each virtual machine, the TCO calculator provides detailed information about all your workloads. It also spits out an itemized estimate of what a comparable service might cost in Azure. The TCO calculator is free and available at this URL: https://azure.microsoft.com/en-us/pricing/tco/calculator/
If you like it more British, replace "en-us" with "en-gb" in the URI. But it only works during the Queen's tea time.
Optimization and monitoring
In Azure, these would include:
• Azure Monitor
• Azure Cost Management
• Azure Advisor
Changes will then be made based on the knowledge gained through monitoring.
AWS and Google will offer the same services. At least I think so. They are fighting each other for every meter of market share (Google and Telekom now want to calm down the German regulatory mickey and allow factory tours of the data centers; let's see whether AWS will then make private audiences with Jeff Bezos possible....on Mars...).
Lift and Shift = Lift and Pray?
Based on the project requests and tenders I'm confronted with as a freelancer, I have the impression that L&S is still the method preferred by the majority.
But until object orientation took hold, the majority of programmers also wrote procedural code. Based on the project requests and bids I get as a freelancer, I get the impression that L&S is still the method preferred by the majority.
But until object orientation took hold, the majority of programmers also wrote procedural code.
Opportunity cost
With rehosting, you can't always take full advantage of the portfolio of native cloud features. Accordingly, this migration path may not always be the most cost-effective.
Gartner estimates that without cost optimization processes, enterprises will overspend on public cloud by 40% on average by 2020 (Ed Anderson, 2018).
Former system houses dominate the cloud migration market
It was significant that the courses I took to obtain the AZ 303 and AZ 304 certificates (each from 5 pm - to 1 am because of the time difference, a US provider) were each led by a different instructor. At the AZ 303 course (very IaaS-heavy) the likeable Dale Hill was my sensei. When I asked him if he was also leading AZ 304 (very PaaS- and therefore architecture-heavy), I got the answer that he had only rudimentary knowledge in that area.
That is typical. And understandable. I don't know everything either.
It's just that it can become a problem when "admin-heavy" IT pros like Dale Hill are asked to perform cloud migrations on their own (or with like-minded people).
Again, I can speak from real-world experience. In one of my first jobs, I was surrounded by excellent programmers. TDD, clean code, thoughtful architectures. I learned a lot there.
One in particular:
Cobbler, stick to your last!
There was the position of Configuration Manager (CM in the following), who had to take care of a squadron of on-premise hosted VMs connected to a CI/CD pipeline. Jenkins was also interposed. All integration and acceptance testing (including UI testing) ran on the VMs.
All colleagues who held this position before quit and left the company. Together with me, this tradition has continued. Although this was not the reason. Anyway, we developers were hopelessly overwhelmed with all the server stuff, the 200 Powershell scripts, the DevOps pipelines and before each release, the CM was the one who had to swallow one heart pill after the next.
I held the post for more than 1 year. In the early days, I solved everything in a code manner. Even more scripts, even more adjustments on code side, even more clicki-bunti on TFS (now azure Devops). And one test run after the next.
Only later did I realize that I had to completely change my way of thinking.
The situation is similar with cloud migration.
Especially companies in Germany that have grown out of system houses and are familiar with network technology are the pioneers when it comes to the cloud. It is clear that these people first work with the tools they are familiar with, and that is Lift and Shift.
Network infrastructure experts are head and shoulders above me - as software architects - when it comes to administration, no question about it, and these people also do a great job. But they often don't know how to tailor software systems. And cross-functional teams, as required by Scrum, are not put together due to a lack of suitable specialists. That would be ideal. Architect and infrastructure expert at the same (digital) table.
But the reality is different.
And in my opinion, this contributes significantly to the fact that people only look at IaaS solutions.
„He who has only a hammer as a tool sees a nail in every problem." Paul Watzlawick (allegedly)
But the cloud is not a hypervisor ++!
The manhunt is on
Namely, the rest of the infrastructure not scanned by Azure Migrate, for example. Remember, the first step is to take stock of the customer's infrastructure and map it. In practice, this is the most difficult part.
„Oh yes, the server 12a that Kuddel has set up. Two machines are virtualized with VirtualBox, I had forgotten all about that one. "Well, no one at our company can confirm whether you have recorded everything, we are simply too big for that. The overall view? I don't think anyone has that." "Oh yes, the Hyper-V VMs 289 and 290 are only booted up via Powershell when the integration tests run at night, of course they won't find them if you only scan during the day. „The real life
Of course it's an advantage to have a vampire in your team...
An advantage becomes a disadvantage
Just as the foresight of some politicians only extends to the next legislative period, the foresight of some project managers (in the following PM) only extends to the next balance sheet date.
In almost all cases, L&S is the fastest way to catapult one's software into the cloud. It's an undeniable advantage, especially when the timeline is tightly crocheted.
But as with any shot with a catapult, you don't always hit the mark.
The PM's boss is thrilled, all the software is in the cloud. No expensive (PaaS) architects that had to be pulled off and/or bought in, the (often equally expensive) admins got it done.
Super.
The fact that the admins have pointed out to the PM a few times that there is a lot of metrics and logs accumulated during monitoring that indicate extensive readjustment measures is wiped off the table.
The app is in the cloud and that's that.
And above all, the boss is happy.
Still.
The Ferrari stops, we take the bike
There is no doubt that the cloud already offers many advantages at the IaaS level.
Very easy to scale.
Can be operated completely without own hardware.
Low initial investment.
But the advantages added at PaaS level are often unconsciously not taken along. Don't get me wrong, I don't want to convert anyone who consciously decides that L&S is the best choice for him. But anyone who chooses L&S as the migration path because they are unaware of the other options and/or because the PM wants to shine in front of the boss by being fast should have it whispered in their ear that they are leaving the Ferrari in the garage even though the key is in it.
In the case of a PaaS-tailored solution:
No operating system administration required.
This allows the focus on the development of the actual application.
The PaaS provider takes over maintenance and support of the hardware and software. Security updates are therefore applied without the intervention of the development team.
Since PaaS is not directly connected to the on-site network structure, it also avoids the rapid spread of any malware that may be present.
Depending on the size of the development team, PaaS can save costs in the millions. Large applications that rely on equally large tests do not have to be simulated in large networks.
This also brings a scheduling (time-to-market) advantage: The development of applications via PaaS begins immediately after the first project design, since everything necessary for development is ready.
Of course, PaaS also brings disadvantages, which I will not conceal here:
The application must support the architecture concept of the platform and if this is not the case, it must first be "modeled" there, which could eat up the time-to-market advantage again. In the long term, however, this is not a disadvantage for me, because who, if not the cloud providers, knows best which architecture has proven itself in the cloud? All 3 major players have a gigantic wealth of experience here and encounter a variety of projects, so that one can assume that tailoring one's own software to their architecture can only be advantageous in the long term.
Only the offered infrastructure services can be used.
Conclusion
The decision for L&S can be the right one for the customer. If the customer has been informed about alternatives beforehand, if the PM does not want to make a name for himself with the boss (through quick results), if the most important stakeholders have given their opinion, if software architects have also been consulted and not just infrastructure experts.
In short: If the decision was made consciously in knowledge of the alternatives and risks.
However, this often does not seem to be the case to me. I rather experience a Wild West atmosphere in which - in Lucky Luke fashion - a lot is shot from the hip. And while Lucky Luke is still accurate in this case, many other cowboys and cowgirls are not.
As mentioned earlier, the cloud is more than just a pimped hypervisor.
It would be a shame to let the many benefits beyond the IaaS level go unrealized.