5 ms·

Lift and shift is a cloud migration strategy which involves moving your applications to the cloud with little to no modification. For example, you have an appli

Lift and shift is a cloud migration strategy which involves moving your applications to the cloud with little to no modification. For example, you have an application running on a server in your data-centre, you then deploy a VM in the cloud with a similar spec and install the application. It's usually done to avoid the engineering cost of making the services more cloud native. What tends to happen a lot is that after a considerable portion of the migration is completed, the cost of the lift-and-shift effort start to overtake the savings, and the projected costs, dwarf the future savings. I suspect this is what happened with Linkedin.

Agingcoder 3y ago
which savings ? It’s never been obvious to me that cloud was cheaper if you’re a large company
- lobsterthief 3y ago
  It’s easier to scale cloud infrastructure.
  - jvm___ 3y ago
    Even if you never need to scale it's cheaper to not have to physically maintain your own data center. If all the broken server, building power, building internet, access control, real estate costs... are all handled in the cloud there's savings there as well.
    - NegativeK 3y ago
      But those costs don't go away -- the cloud provider is going to charge you for them, along with a premium for profit? I'm used to organizations moving out of the cloud when they realize that it's more expensive if you don't have very peaky load demands.
    - vidarh 3y ago
      Very few people who don't use cloud use their own data centers. The dominant alternative to cloud is colo or managed servers. And it's difficult to make that as expensive as a cloud deployment.
  - marcolussetti 3y ago
    But that's somewhat negated if you lift and shift, because your application is not designed to leverage that capability in that way.
- campbel 3y ago
  Compute is at a premium, but you can shift opex/capex around which might be more suitable. It can also be cheaper in headcount since you need fewer operators and less expertise in datacenter operations.
  - adolph 3y ago
    > you need fewer operators and less expertise in datacenter operations Because you are paying someone else for them. This is considered rational because those operators are presumably more productive in a pool of people using similar skills to support many customers rather than just one. It is similar to hiring a cleaning service rather than employing individual cleaners in a department of cleaning because cleaning things is not a core competency of business. It might be less irrational if some amount of compute is part of the core competency of the business. Since "software is eating the world," compute is a core competency of all businesses except for the ones that don't realize it yet.
    - campbel 3y ago
      I think there is a difference in competency between using Cloud Compute and running your own Datacenter. Perhaps some companies have the overlap, but I suspect this is an additional skillset they need to cultivate to achieve the savings.
  - wharvle 3y ago
    > It can also be cheaper in headcount since you need fewer operators and less expertise in datacenter operations. I've not really seen this work out well. I think it might be true for simple set-ups, letting a tiny developer team also handle infra and support without going nuts doing it, if they set it up that way from the beginning, but more-complex setups always seem to have so damn many sharp edges and moving pieces that support ends up looking similar to what a far more DIY approach (short of building one's own datacenter outright) would, in terms of time lost to it. ... and so does downtime, for that matter.
  - vidarh 3y ago
    When I've done devops consulting, clients with cloud deployments invariably spent more money on devops because of the often significantly more complex environments.
- _cenw 3y ago
  It's at least more predictable. You don't pay for staff with datacenter skills (sort of in short supply) and you don't need to make large investments early on to build the datacenter and you don't have a huge headache if you need to scale up or down operations.
- hibikir 3y ago
  It really depends on workloads. Imagine you need massive spikes of compute for, say, flash sales, or people watching the superbowl in your streaming service. Buying all that hardware for just the spikes might not make sense vs just scaling up vms in a cloud provider and scale them down. In the real world, for baseline load, the big advantage for many large companies isn't price, but the massive lack of alacrity of many inhouse ops teams. If it takes me 3+ months to provision compute for the simplest, lowest demand services (as is the custom in many large companies full of red tape and arguments about who bears costs), letting teams just spin up anything they want and get billed directly is often a winner, even if it's more expensive. Having entire teams waste months before they can put something in prod is a very different kind of expense in itself.
- maccard 3y ago
  The simplest example is if you have on-prem hardware, you need to have capacity for your peak load. In a lift and shift, you would replace your fleet of 96 core xeons with a fleet of 96 core xeons in AWS. The cloud native approach would be to modify your app so that it can be scaled up and down so you keep a few machines always running, and scale up and down with your traffic so you only run at capacity when you need it.
  - wredue 3y ago
    This doesn’t demonstrate anything about the savings. Anecdotally, when my previous company was looking at costs, cloud unequivocally came out significantly more expensive, and that wasn’t even a large company (only 2,000 or so employees). I will grant that we did not have globalization problems to solve (but I’d also wager that lots of businesses prematurely “what if” this scenario anyway).
    - maccard 3y ago
      > This doesn’t demonstrate anything about the savings. If you neeed 4 CPUs for your peak load for 4 hours per day, and only 1 of them for the other 20 hours a day, you can save by scaling down to 1 cpu for 85% of the day.
      - vidarh 3y ago
        This assumes a lot about the cost of those CPUs and related resources in the respective environments. Cost per equivalently performing unit on a managed server vs. cloud instances is often vastly different. It's also extremely uncommon to have loads that spiky. And when you do, hybrid is often a solution (use a provider that can provide colo or managed servers for your base load and cloud instances for your peaks, or scale across providers).
        maccard 3y ago
        It's pretty hard to capture the nuance of any possible solution in 2 paragraphs without someone coming along and picking it apart. The guy I replied to didn't know even the most basic information. Even at that, you said yourself that you can use "cloud" to scale into your spikes.
bee_rider 3y ago
Although, it must be unusual, right? This is not one company porting their service to the cloud, this is Microsoft porting their LinkedIn service from whatever servers came along with LinkedIn, to their own servers, on which they also run a cloud business. Which… isn’t to say anything about which way we should expect that to swing things. But it seems quite unusual, as most companies have not been bought by a cloud provider. Yet…
- random42 3y ago
  > this is Microsoft porting their LinkedIn service from whatever servers came along with LinkedIn, to their own servers Nope, LinkedIn executes completely independently.
  - manquer 3y ago
    That is not really true, if it was then Linkedin would have evaluated all the clouds in fair process and gone with AWS as the best fit in 2019 if they wanted to move in the first place. The pressure to move to a cloud and to Azure specifically both comes entirely from MS. Linkedin was perfectly happy then and now running its own setup, this 4 years of trying to move is because of MS ownership.
hinkley 3y ago
If your architecture is chatty enough, you will be sharding things so that most traffic stays in one rack, room, or data center. If you treat us-west-1 as a single data center, you may find you are spending a lot on traffic between AZs. A lift and shift might treat us-west-1 like a single data center. A more sophisticated strategy might treat it as three.

Agingcoder 3y ago

which savings ? It’s never been obvious to me that cloud was cheaper if you’re a large company

lobsterthief 3y ago
It’s easier to scale cloud infrastructure.
- jvm___ 3y ago
  Even if you never need to scale it's cheaper to not have to physically maintain your own data center. If all the broken server, building power, building internet, access control, real estate costs... are all handled in the cloud there's savings there as well.
  - NegativeK 3y ago
    But those costs don't go away -- the cloud provider is going to charge you for them, along with a premium for profit? I'm used to organizations moving out of the cloud when they realize that it's more expensive if you don't have very peaky load demands.
  - vidarh 3y ago
    Very few people who don't use cloud use their own data centers. The dominant alternative to cloud is colo or managed servers. And it's difficult to make that as expensive as a cloud deployment.
- marcolussetti 3y ago
  But that's somewhat negated if you lift and shift, because your application is not designed to leverage that capability in that way.
campbel 3y ago
Compute is at a premium, but you can shift opex/capex around which might be more suitable. It can also be cheaper in headcount since you need fewer operators and less expertise in datacenter operations.
- adolph 3y ago
  > you need fewer operators and less expertise in datacenter operations Because you are paying someone else for them. This is considered rational because those operators are presumably more productive in a pool of people using similar skills to support many customers rather than just one. It is similar to hiring a cleaning service rather than employing individual cleaners in a department of cleaning because cleaning things is not a core competency of business. It might be less irrational if some amount of compute is part of the core competency of the business. Since "software is eating the world," compute is a core competency of all businesses except for the ones that don't realize it yet.
  - campbel 3y ago
    I think there is a difference in competency between using Cloud Compute and running your own Datacenter. Perhaps some companies have the overlap, but I suspect this is an additional skillset they need to cultivate to achieve the savings.
- wharvle 3y ago
  > It can also be cheaper in headcount since you need fewer operators and less expertise in datacenter operations. I've not really seen this work out well. I think it might be true for simple set-ups, letting a tiny developer team also handle infra and support without going nuts doing it, if they set it up that way from the beginning, but more-complex setups always seem to have so damn many sharp edges and moving pieces that support ends up looking similar to what a far more DIY approach (short of building one's own datacenter outright) would, in terms of time lost to it. ... and so does downtime, for that matter.
- vidarh 3y ago
  When I've done devops consulting, clients with cloud deployments invariably spent more money on devops because of the often significantly more complex environments.
_cenw 3y ago
It's at least more predictable. You don't pay for staff with datacenter skills (sort of in short supply) and you don't need to make large investments early on to build the datacenter and you don't have a huge headache if you need to scale up or down operations.
hibikir 3y ago
It really depends on workloads. Imagine you need massive spikes of compute for, say, flash sales, or people watching the superbowl in your streaming service. Buying all that hardware for just the spikes might not make sense vs just scaling up vms in a cloud provider and scale them down. In the real world, for baseline load, the big advantage for many large companies isn't price, but the massive lack of alacrity of many inhouse ops teams. If it takes me 3+ months to provision compute for the simplest, lowest demand services (as is the custom in many large companies full of red tape and arguments about who bears costs), letting teams just spin up anything they want and get billed directly is often a winner, even if it's more expensive. Having entire teams waste months before they can put something in prod is a very different kind of expense in itself.
maccard 3y ago
The simplest example is if you have on-prem hardware, you need to have capacity for your peak load. In a lift and shift, you would replace your fleet of 96 core xeons with a fleet of 96 core xeons in AWS. The cloud native approach would be to modify your app so that it can be scaled up and down so you keep a few machines always running, and scale up and down with your traffic so you only run at capacity when you need it.
- wredue 3y ago
  This doesn’t demonstrate anything about the savings. Anecdotally, when my previous company was looking at costs, cloud unequivocally came out significantly more expensive, and that wasn’t even a large company (only 2,000 or so employees). I will grant that we did not have globalization problems to solve (but I’d also wager that lots of businesses prematurely “what if” this scenario anyway).
  - maccard 3y ago
    > This doesn’t demonstrate anything about the savings. If you neeed 4 CPUs for your peak load for 4 hours per day, and only 1 of them for the other 20 hours a day, you can save by scaling down to 1 cpu for 85% of the day.
    - vidarh 3y ago
      This assumes a lot about the cost of those CPUs and related resources in the respective environments. Cost per equivalently performing unit on a managed server vs. cloud instances is often vastly different. It's also extremely uncommon to have loads that spiky. And when you do, hybrid is often a solution (use a provider that can provide colo or managed servers for your base load and cloud instances for your peaks, or scale across providers).
      - maccard 3y ago
        It's pretty hard to capture the nuance of any possible solution in 2 paragraphs without someone coming along and picking it apart. The guy I replied to didn't know even the most basic information. Even at that, you said yourself that you can use "cloud" to scale into your spikes.

bee_rider 3y ago

Although, it must be unusual, right? This is not one company porting their service to the cloud, this is Microsoft porting their LinkedIn service from whatever servers came along with LinkedIn, to their own servers, on which they also run a cloud business. Which… isn’t to say anything about which way we should expect that to swing things. But it seems quite unusual, as most companies have not been bought by a cloud provider. Yet…

random42 3y ago
> this is Microsoft porting their LinkedIn service from whatever servers came along with LinkedIn, to their own servers Nope, LinkedIn executes completely independently.
- manquer 3y ago
  That is not really true, if it was then Linkedin would have evaluated all the clouds in fair process and gone with AWS as the best fit in 2019 if they wanted to move in the first place. The pressure to move to a cloud and to Azure specifically both comes entirely from MS. Linkedin was perfectly happy then and now running its own setup, this 4 years of trying to move is because of MS ownership.

hinkley 3y ago

If your architecture is chatty enough, you will be sharding things so that most traffic stays in one rack, room, or data center. If you treat us-west-1 as a single data center, you may find you are spending a lot on traffic between AZs. A lift and shift might treat us-west-1 like a single data center. A more sophisticated strategy might treat it as three.