7 ms·

> LinkedIn was having a hard time taking advantage of the cloud provider's software. Sources told CNBC that issues arose when LinkedIn attempted to lift and shi

> LinkedIn was having a hard time taking advantage of the cloud provider's software. Sources told CNBC that issues arose when LinkedIn attempted to lift and shift its existing software tools to Azure rather than refactor them to run on the cloud provider's ready made tools. I think I need this translated back into tech-speak.

aldarisbm 3y ago
[flagged]
asylteltine 3y ago
That is tech speak. They tried to redeploy existing architecture into azure and it failed
- ghaff 3y ago
  The headline notwithstanding, this doesn't seem like anything particularly Azure specific. They'd likely have had many of the same issues trying to mostly lift and shift to any of the big public cloud providers.
eitally 3y ago
ELI5: For any sufficiently complex enterprise system (e.g. LinkedIn, or Google), any plain vanilla architecture is infeasible for lift & shift. Moreover, the vanilla services may not comply with internal security requirements, or play nicely with internal CI/CD tools, or internal databases / data structures / data processing pipelines / analytics.
- mecsred 3y ago
  No five year old is going to understand a single sentence of that.
  - calvin 3y ago
    ELI40YO Engineer
    - that_guy_iain 3y ago
      Still need it dumbed down a bit /s
  - maronato 3y ago
    You spend a week building a castle with legos, and suddenly your mom asks if you can change some parts to use the new <lego competitor>. You can try to make the old and new parts fit together, but it isn’t going to be easy most of the time, and you can’t be certain that the lego competitor will have the same pieces or do the same things as your lego version. By the time you are done redoing those parts, you’ll end up having to recreate large portions of your castle to make everything work together again, and even then you might miss something important that breaks a functionality of your castle.
  - mypetocean 3y ago
    Maybe in this case "ELI5" stands for "Explain it like I have 5 yrs experience in software development but gave up in year two"?
  - eitally 3y ago
    Arguably, if the five year old was reading hacker news, they might. :) Point taken, though, but honestly this doesn't seem like the place to simplify things to quite to 5Yo level.
- _cenw 3y ago
  That's all correct in theory, but in my experience these things still happen and are usually outgrowths of bad engineering culture / shadow IT / not wanting to be reliant on your cloud infra / platform team (often for irrational reasons, sometimes not). They get built with entire teams taking responsibility on paper, but then before you know it, nobody from that team still works at the company or on that team. Usually these systems are also GDPR nightmares if they contain user data, because these people don't understand when you tell them they need to have a plan for deleting user data. They don't even consider it a legal barrier, they think you're putting stones in their way. I've been on enough Cloud Archeology expeditions into the land of VMs where nobody knows what they do, it might as well be my job title now.
- _rutinerad 3y ago
  My five-year-old loves her complex enterprise system.
sqeaky 3y ago
Is that supposed to make it seem better? If refactoring is too hard for a Microsoft owned company what am I to think about my tech stack?
- bostik 3y ago
  Beyond ludicrously small systems, refactoring of live 24/7 production systems is never easy. Reality has a surprising amount of detail, and any non-trivial, customer-facing system will have accumulated weird code paths to account for obscure but nonetheless expensive edge cases. A codebase built across >20 years, scaled to support millions of concurrent users is going to be absolutely filled to the brim with weird things. When you add the need for live migrations with zero downtime, done every few years to account for next order of magnitude loads, you end up with a proper Frankenstein's monster. It's not called "rebuilding an airplane while flying" for a lark. Every round includes a long, complex engineering effort of incremental live migration. With parallel read/write patterns between old and new systems, and all their annoying semantic differences. And then, to add insult to injury, while your core team was going through the months-long process of migrating one essential service, half a dozen upstream teams have independently realised they can depend on some weird side effects of the intermediate state and embedded its assumptions to a Critical Business Process[tm] responsible for a decent fraction of your company's monthly revenue. Breaking their implicit workflow will make your entire company go from black to red, so your core team is now saddled with supporting the known-broken assumptions. Then you get to add wildly differing latency profiles to the mix. While you were running on your own hardware, the worst-case latency was rack-to-rack. Implicit assumptions on massive but essential workloads may depend, unknowingly, on call-to-call latencies that only rarely exceed 100 microseconds. In a cross-AZ cloud setting you may suddenly have a p90 floor of 0.2ms. A lot of software can break in unexpected ways when things are consistently just a little bit too slow. Welcome to the wonderful world of distributed systems and cloud migrations. At some point the scars will heal. Allegedly.
Raed667 3y ago
I think this is an awkward way of saying they tried to add an abstraction on top of their AWS dependencies so that their services would work on Azure without a refactor.
- b112 3y ago
  They don't use AWS, but primarily baremetal.
  - b112 3y ago
    Also, this reminds me of the time Microsoft bought Hotmail, and couldn't port it to WinNT. They had to leave it on its BSD variant for a long time, NT couldn't handle it.
    - cplusplusfellow 3y ago
      I'm surprised it can today.
    - Scoundreller 3y ago
      Arstechnica forum discussion on the topic in 2001: https://arstechnica.com/civis/threads/i-thought-hotmail-was-completely-off-freebsd.968201/ https://arstechnica.com/civis/threads/i-thought-hotmail-was-...
wharvle 3y ago
“Lift and shift” is a term for when you move to “the cloud” but really just replace your physical servers with clones in cloud VMs. It’s a relatively cheap (in terms of effort) way to get on “the cloud” but gains you basically zero of the benefits. The term’s in wide use, talk to anyone involved with cloud-anything and they’ll be familiar with it. I’m not sure what else needs to be translated? Nothing, I think?
- mmcgaha 3y ago
  Lift and shift is a sales term to make it sound like the internal team is trying to over-complicate the migration. The sales guy will normally phrase it as "just lift and shift."
  - neilv 3y ago
    I love it. I could totally believe the etymology starts as slick sales persuasion trying to downplay the implementation difficulty of something that's being sold. And then people also pick it up for non-persuasion, because it also sounds like a catchy name for an engineering approach we already had. Of course it can still be used for persuasion for awhile, but will grow baggage over time, as efforts linked to the term don't play out that way.
- neilv 3y ago
  Thanks for the explanation, but no need to imply that someone is out of the loop if they didn't know it. The term didn't sound familiar to me (though the concept was), and the term might not have been familiar to some others. People might not want to contradict an assertion because of language like "The term’s in wide use, talk to anyone involved with cloud-anything and they’ll be familiar with it. [...] I’m not sure what else needs to be translated? Nothing, I think?"
  - wharvle 3y ago
    > People might not want to contradict an assertion because of language like "The term’s in wide use, talk to anyone involved with cloud-anything and they’ll be familiar with it. [...] I’m not sure what else needs to be translated? Nothing, I think?" > > LinkedIn was having a hard time taking advantage of the cloud provider's software. Sources told CNBC that issues arose when LinkedIn attempted to lift and shift its existing software tools to Azure rather than refactor them to run on the cloud provider's ready made tools. The only other terms I can see that are jargon are "cloud provider" and "refactor", and those are already technical (more or less) so don't need to be translated into technical language. As for the other bit, I just meant that it's a widely-used term so one may continue to encounter it in these contexts. It truly is ubiquitous in discussion of and around "enterprise transformations" to the cloud, and among cloud practitioners more generally, so anyone connected to that space will know what it means. It's also kinda already a technical term, in that developer/devops and SRE sorts throw it around and do mean a specific thing by it, which doesn't need to be translated for other technical folks in that area.
vergessenmir 3y ago
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.
mdeeks 3y ago
There is no such thing as "lift and shift". It is something Azure account reps like to say to make it sound like moving is easy. It sounds like you're picking up some boxes from one side of the room and moving them to the other. When in reality you're rewriting your infra code mostly from scratch. When we were acquired by MSFT we had the same project. We had to move from AWS to Azure. I made them all stop saying "lift and shift" because in reality it is "throw away all of your provisioning code and rewrite it using Azure primitives which don't work the same way as AWS ones". It is more akin to writing an iOS app to work on Android.
- axus 3y ago
  I'm gonna bet that many Azure customers had no such thing as "provisioning code".
- _cenw 3y ago
  To be fair, AWS also used the exact term when we moved a project out of a tiny expensive to operate (though lack of scale) datacenter that only hadn't been retired because we had a 30+ year old COBOL app suite on a z system.
- arielcostas 3y ago
  But lift and shift is not that, is it? It's having applications running directly on OSs (without containerisation or separation of dependencies like the database or physical disks) and moving it to "the cloud" to be ran on a VM in the same fashion. I mean, if you're already with AWS using their services (besides EC2 for hosting) such as RDS or S3; moving to Azure SQL (or DB for MySQL or whatever) and Blob Storage is not just lift-and-shift anymore, since you are actually changing from a cloud provider to a different one. AFAIK an actual migration to the cloud would involve rewriting some parts of the application to be cloud-native, such as using Service Bus for queues instead of a local Redis/RabbitMQ instance, using GCS instead of local disks, and using RDS instead of hosting your own single MySQL server.
  - oasisbob 3y ago
    There's no formal definition of "lift and shift", certainly nothing that would dictate specific virtualization strategies. I've always read it as being roughly analogous to "like for like," and dependent on the specific circumstances and status quo.
ben_jones 3y ago
It could mean multiple things. My guess is they used vendor specific services that don’t translate as well as the basic build blocks like vanilla S3/ec2
deleted 3y ago
[deleted]

aldarisbm 3y ago

[flagged]

asylteltine 3y ago

That is tech speak. They tried to redeploy existing architecture into azure and it failed

ghaff 3y ago
The headline notwithstanding, this doesn't seem like anything particularly Azure specific. They'd likely have had many of the same issues trying to mostly lift and shift to any of the big public cloud providers.

eitally 3y ago

ELI5: For any sufficiently complex enterprise system (e.g. LinkedIn, or Google), any plain vanilla architecture is infeasible for lift & shift. Moreover, the vanilla services may not comply with internal security requirements, or play nicely with internal CI/CD tools, or internal databases / data structures / data processing pipelines / analytics.

mecsred 3y ago
No five year old is going to understand a single sentence of that.
- calvin 3y ago
  ELI40YO Engineer
  - that_guy_iain 3y ago
    Still need it dumbed down a bit /s
- maronato 3y ago
  You spend a week building a castle with legos, and suddenly your mom asks if you can change some parts to use the new <lego competitor>. You can try to make the old and new parts fit together, but it isn’t going to be easy most of the time, and you can’t be certain that the lego competitor will have the same pieces or do the same things as your lego version. By the time you are done redoing those parts, you’ll end up having to recreate large portions of your castle to make everything work together again, and even then you might miss something important that breaks a functionality of your castle.
- mypetocean 3y ago
  Maybe in this case "ELI5" stands for "Explain it like I have 5 yrs experience in software development but gave up in year two"?
- eitally 3y ago
  Arguably, if the five year old was reading hacker news, they might. :) Point taken, though, but honestly this doesn't seem like the place to simplify things to quite to 5Yo level.
_cenw 3y ago
That's all correct in theory, but in my experience these things still happen and are usually outgrowths of bad engineering culture / shadow IT / not wanting to be reliant on your cloud infra / platform team (often for irrational reasons, sometimes not). They get built with entire teams taking responsibility on paper, but then before you know it, nobody from that team still works at the company or on that team. Usually these systems are also GDPR nightmares if they contain user data, because these people don't understand when you tell them they need to have a plan for deleting user data. They don't even consider it a legal barrier, they think you're putting stones in their way. I've been on enough Cloud Archeology expeditions into the land of VMs where nobody knows what they do, it might as well be my job title now.
_rutinerad 3y ago
My five-year-old loves her complex enterprise system.

sqeaky 3y ago

Is that supposed to make it seem better? If refactoring is too hard for a Microsoft owned company what am I to think about my tech stack?

bostik 3y ago
Beyond ludicrously small systems, refactoring of live 24/7 production systems is never easy. Reality has a surprising amount of detail, and any non-trivial, customer-facing system will have accumulated weird code paths to account for obscure but nonetheless expensive edge cases. A codebase built across >20 years, scaled to support millions of concurrent users is going to be absolutely filled to the brim with weird things. When you add the need for live migrations with zero downtime, done every few years to account for next order of magnitude loads, you end up with a proper Frankenstein's monster. It's not called "rebuilding an airplane while flying" for a lark. Every round includes a long, complex engineering effort of incremental live migration. With parallel read/write patterns between old and new systems, and all their annoying semantic differences. And then, to add insult to injury, while your core team was going through the months-long process of migrating one essential service, half a dozen upstream teams have independently realised they can depend on some weird side effects of the intermediate state and embedded its assumptions to a Critical Business Process[tm] responsible for a decent fraction of your company's monthly revenue. Breaking their implicit workflow will make your entire company go from black to red, so your core team is now saddled with supporting the known-broken assumptions. Then you get to add wildly differing latency profiles to the mix. While you were running on your own hardware, the worst-case latency was rack-to-rack. Implicit assumptions on massive but essential workloads may depend, unknowingly, on call-to-call latencies that only rarely exceed 100 microseconds. In a cross-AZ cloud setting you may suddenly have a p90 floor of 0.2ms. A lot of software can break in unexpected ways when things are consistently just a little bit too slow. Welcome to the wonderful world of distributed systems and cloud migrations. At some point the scars will heal. Allegedly.

Raed667 3y ago

I think this is an awkward way of saying they tried to add an abstraction on top of their AWS dependencies so that their services would work on Azure without a refactor.

b112 3y ago
They don't use AWS, but primarily baremetal.
- b112 3y ago
  Also, this reminds me of the time Microsoft bought Hotmail, and couldn't port it to WinNT. They had to leave it on its BSD variant for a long time, NT couldn't handle it.
  - cplusplusfellow 3y ago
    I'm surprised it can today.
  - Scoundreller 3y ago
    Arstechnica forum discussion on the topic in 2001: https://arstechnica.com/civis/threads/i-thought-hotmail-was-completely-off-freebsd.968201/ https://arstechnica.com/civis/threads/i-thought-hotmail-was-...

wharvle 3y ago

“Lift and shift” is a term for when you move to “the cloud” but really just replace your physical servers with clones in cloud VMs. It’s a relatively cheap (in terms of effort) way to get on “the cloud” but gains you basically zero of the benefits. The term’s in wide use, talk to anyone involved with cloud-anything and they’ll be familiar with it. I’m not sure what else needs to be translated? Nothing, I think?

mmcgaha 3y ago
Lift and shift is a sales term to make it sound like the internal team is trying to over-complicate the migration. The sales guy will normally phrase it as "just lift and shift."
- neilv 3y ago
  I love it. I could totally believe the etymology starts as slick sales persuasion trying to downplay the implementation difficulty of something that's being sold. And then people also pick it up for non-persuasion, because it also sounds like a catchy name for an engineering approach we already had. Of course it can still be used for persuasion for awhile, but will grow baggage over time, as efforts linked to the term don't play out that way.
neilv 3y ago
Thanks for the explanation, but no need to imply that someone is out of the loop if they didn't know it. The term didn't sound familiar to me (though the concept was), and the term might not have been familiar to some others. People might not want to contradict an assertion because of language like "The term’s in wide use, talk to anyone involved with cloud-anything and they’ll be familiar with it. [...] I’m not sure what else needs to be translated? Nothing, I think?"
- wharvle 3y ago
  > People might not want to contradict an assertion because of language like "The term’s in wide use, talk to anyone involved with cloud-anything and they’ll be familiar with it. [...] I’m not sure what else needs to be translated? Nothing, I think?" > > LinkedIn was having a hard time taking advantage of the cloud provider's software. Sources told CNBC that issues arose when LinkedIn attempted to lift and shift its existing software tools to Azure rather than refactor them to run on the cloud provider's ready made tools. The only other terms I can see that are jargon are "cloud provider" and "refactor", and those are already technical (more or less) so don't need to be translated into technical language. As for the other bit, I just meant that it's a widely-used term so one may continue to encounter it in these contexts. It truly is ubiquitous in discussion of and around "enterprise transformations" to the cloud, and among cloud practitioners more generally, so anyone connected to that space will know what it means. It's also kinda already a technical term, in that developer/devops and SRE sorts throw it around and do mean a specific thing by it, which doesn't need to be translated for other technical folks in that area.

vergessenmir 3y ago

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.

mdeeks 3y ago

There is no such thing as "lift and shift". It is something Azure account reps like to say to make it sound like moving is easy. It sounds like you're picking up some boxes from one side of the room and moving them to the other. When in reality you're rewriting your infra code mostly from scratch. When we were acquired by MSFT we had the same project. We had to move from AWS to Azure. I made them all stop saying "lift and shift" because in reality it is "throw away all of your provisioning code and rewrite it using Azure primitives which don't work the same way as AWS ones". It is more akin to writing an iOS app to work on Android.

axus 3y ago
I'm gonna bet that many Azure customers had no such thing as "provisioning code".
_cenw 3y ago
To be fair, AWS also used the exact term when we moved a project out of a tiny expensive to operate (though lack of scale) datacenter that only hadn't been retired because we had a 30+ year old COBOL app suite on a z system.
arielcostas 3y ago
But lift and shift is not that, is it? It's having applications running directly on OSs (without containerisation or separation of dependencies like the database or physical disks) and moving it to "the cloud" to be ran on a VM in the same fashion. I mean, if you're already with AWS using their services (besides EC2 for hosting) such as RDS or S3; moving to Azure SQL (or DB for MySQL or whatever) and Blob Storage is not just lift-and-shift anymore, since you are actually changing from a cloud provider to a different one. AFAIK an actual migration to the cloud would involve rewriting some parts of the application to be cloud-native, such as using Service Bus for queues instead of a local Redis/RabbitMQ instance, using GCS instead of local disks, and using RDS instead of hosting your own single MySQL server.
- oasisbob 3y ago
  There's no formal definition of "lift and shift", certainly nothing that would dictate specific virtualization strategies. I've always read it as being roughly analogous to "like for like," and dependent on the specific circumstances and status quo.

ben_jones 3y ago

It could mean multiple things. My guess is they used vendor specific services that don’t translate as well as the basic build blocks like vanilla S3/ec2

deleted 3y ago

[deleted]