6 ms·

I'm obviously not going to comment on anything internal, and I'm obviously speaking for myself and not the company, but it's worth bearing in mind that this mig

I'm obviously not going to comment on anything internal, and I'm obviously speaking for myself and not the company, but it's worth bearing in mind that this migration was not from "on-prem" in the traditional sense. LinkedIn has its own internal cloud, complete with all the abstractions you'd expect from a public cloud provider, except developed contemporaneously with all the rest of the "clouds" everyone is familiar with. It was designed for, and is tightly coupled to, LinkedIn's particular view on how to build a flexible infrastructure (for an extreme example, using Rest.Li[1], which includes client-side load balancing). There was no attempt to "lift-and-shift" anything. There are technologies that overlap and technologies that conflict and technologies that compliment one another. As with any huge layered stack, you have to figure out which from the "LinkedIn" column marry well with those in the "Azure" column. I personally appreciate LI management's ability to be clear-eyed about whether the ROI was there. [1] https://linkedin.github.io/rest.li/ https://linkedin.github.io/rest.li/

dfxm12 3y ago
Yeah, based on my own experience with AWS and Azure (that has nothing to do with Linked In), my immediate reaction to the headline was, "well, you can be keen on Azure, but "stuck" on AWS for a myriad of other reasons". Reading the article pretty confirmed it.
- whoknew1122 3y ago
  I'm not sure how this has anything to do with AWS. But I guess you can use it to confirm your idea about vendor lock-in if you're bound and determined to convince yourself you're right. For what it's worth, working at AWS, I see a lot of companies who use Entra for AD and then federate into AWS using that.
  - ajcp 3y ago
    I think you misunderstood OPs anecdote and took it a little personally? They were simply saying that much as you can love one platform there are many valid reasons why your deployment on another makes it hard to shift that and recapture that configuration. Nowhere did they intimate it was a fault of the current platforms capabilities...
- grepfru_it 3y ago
  this describes github to a tee. think very hard before you start building your cloud-native application on a specific cloud
foobarian 3y ago
Oof, I'm twitching just reading that because we're in exactly the same boat. The problem with the ROI is that any kind of not-self-run cloud is guaranteed to be more expensive in direct costs. This has been shown time and time again for any reasonably large enterprise. However, there is a long list of things that are hard to express in money that support a cloud move, mostly to do with keeping up with modern tech, hiring, DR, better resiliency, etc. and so the decision can be quite dependent on the particular execs in the chain of command and their subjective values.
- sargun 3y ago
  This is based on the assumption that Azure has modern tech, hires well, DR, and better resiliency than LinkedIn's "cloud" for LinkedIn's needs. There's a bit of a problem around incentives here, where Azure is built to sell to Azure's customer base, whereas LinkedIn has evolved their own stack over the years. The questions become: 1. Does it make sense to dump our special features in the stack, or move them to a higher level in the stack? 2. Does Azure have comparable capabilities for the LinkedIn stack? 3. Is LinkedIn worth it to Azure to sell to? --- Often times, "at scale", you can support custom solutions outside of cloud providers that are purpose-built, and often times more resilient and efficient than the cloud providers. AWS has taken a very interesting approach of building an incredibly wide set of solutions to support every customer under the sun, and their approach to being "customer obsessed" leads to them building super niche solutions if the deal is worth it. I'm not sure how Google and Azure handle these engagements.
  - alphager 3y ago
    Google doesn't acknowledge that the customer exists or has wishes. Microsoft will allow you access to the PM of the product if you are big enough, but his answer will be a not-exactly-committing "in 3 years" because their roadmap is full.
    - vasco 3y ago
      Every once in a while Google acknowledges the customer exists, but usually for a brief moment, either to close their account, or to tell them they are using the product wrong. They promptly go back to work after such brief outings, so as to not fall into the mistake of actually listening.
hasty_pudding 3y ago
> I personally appreciate LI management's ability to be clear-eyed about whether the ROI was there. Kind of confusing statement as they threw away tens of millions of dollars in a failed attempt to migrate.
- richbell 3y ago
  At least they canceled the project when it became apparent things weren't going to work out as expected. I've seen massive projects that have been train wrecks since day one pushed through until the bitter end because management can't admit failure.
  - magicalhippo 3y ago
    We have that going on in Norway right now. Our state hospitals are switching several aging systems to some Epic-based monstrosity, and so far it's been a complete shit-show[1]. A major hospital has been running it for a year with lots of issues, some which has certainly affected patients gravely. It was rolled out despite heavy protests from doctors and nurses who had seen or experienced the new system at the smaller pilot hospitals. Yet management is pushing on, and just decided the next big hospital should get the new system this spring, despite the many severe issues that are still unsolved. [1]: https://www.nrk.no/emne/helseplattformen-1.15838445 https://www.nrk.no/emne/helseplattformen-1.15838445
  - hasty_pudding 3y ago
    That's not good management though. Recognizing you fucked up and only cost the company tens of millions instead of hundreds of millions is "Not Terrible" management.
    - prepend 3y ago
      It’s not perfect, but it’s good. Or better than spending more.
      - hasty_pudding 3y ago
DeathArrow 3y ago
If anything, this highlights the dangers of building your app around the details of a particular clod infrastructure.
- PeterStuer 3y ago
  I guess in this case it was the other way around: building the cloud architecture specific to the needs of the app.
  - alephnan 3y ago
    It’s not a good cloud if they built the wrong abstractions that aren’t generic
junto 3y ago
From that repo: > At LinkedIn, we are focusing our efforts on advanced automation to enable a seamless, LinkedIn-wide migration from Rest.li to gRPC. gRPC will offer better performance, support for more programming languages, streaming, and a robust open source community. There is no active development at LinkedIn on new features for Rest.li. The repository will also be deprecated soon once we have migrated services to use gRPC. Refer to this blog for more details on why we are moving to gRPC.

dfxm12 3y ago

Yeah, based on my own experience with AWS and Azure (that has nothing to do with Linked In), my immediate reaction to the headline was, "well, you can be keen on Azure, but "stuck" on AWS for a myriad of other reasons". Reading the article pretty confirmed it.

whoknew1122 3y ago
I'm not sure how this has anything to do with AWS. But I guess you can use it to confirm your idea about vendor lock-in if you're bound and determined to convince yourself you're right. For what it's worth, working at AWS, I see a lot of companies who use Entra for AD and then federate into AWS using that.
- ajcp 3y ago
  I think you misunderstood OPs anecdote and took it a little personally? They were simply saying that much as you can love one platform there are many valid reasons why your deployment on another makes it hard to shift that and recapture that configuration. Nowhere did they intimate it was a fault of the current platforms capabilities...
grepfru_it 3y ago
this describes github to a tee. think very hard before you start building your cloud-native application on a specific cloud

foobarian 3y ago

Oof, I'm twitching just reading that because we're in exactly the same boat. The problem with the ROI is that any kind of not-self-run cloud is guaranteed to be more expensive in direct costs. This has been shown time and time again for any reasonably large enterprise. However, there is a long list of things that are hard to express in money that support a cloud move, mostly to do with keeping up with modern tech, hiring, DR, better resiliency, etc. and so the decision can be quite dependent on the particular execs in the chain of command and their subjective values.

sargun 3y ago
This is based on the assumption that Azure has modern tech, hires well, DR, and better resiliency than LinkedIn's "cloud" for LinkedIn's needs. There's a bit of a problem around incentives here, where Azure is built to sell to Azure's customer base, whereas LinkedIn has evolved their own stack over the years. The questions become: 1. Does it make sense to dump our special features in the stack, or move them to a higher level in the stack? 2. Does Azure have comparable capabilities for the LinkedIn stack? 3. Is LinkedIn worth it to Azure to sell to? --- Often times, "at scale", you can support custom solutions outside of cloud providers that are purpose-built, and often times more resilient and efficient than the cloud providers. AWS has taken a very interesting approach of building an incredibly wide set of solutions to support every customer under the sun, and their approach to being "customer obsessed" leads to them building super niche solutions if the deal is worth it. I'm not sure how Google and Azure handle these engagements.
- alphager 3y ago
  Google doesn't acknowledge that the customer exists or has wishes. Microsoft will allow you access to the PM of the product if you are big enough, but his answer will be a not-exactly-committing "in 3 years" because their roadmap is full.
  - vasco 3y ago
    Every once in a while Google acknowledges the customer exists, but usually for a brief moment, either to close their account, or to tell them they are using the product wrong. They promptly go back to work after such brief outings, so as to not fall into the mistake of actually listening.

hasty_pudding 3y ago

> I personally appreciate LI management's ability to be clear-eyed about whether the ROI was there. Kind of confusing statement as they threw away tens of millions of dollars in a failed attempt to migrate.

richbell 3y ago
At least they canceled the project when it became apparent things weren't going to work out as expected. I've seen massive projects that have been train wrecks since day one pushed through until the bitter end because management can't admit failure.
- magicalhippo 3y ago
  We have that going on in Norway right now. Our state hospitals are switching several aging systems to some Epic-based monstrosity, and so far it's been a complete shit-show[1]. A major hospital has been running it for a year with lots of issues, some which has certainly affected patients gravely. It was rolled out despite heavy protests from doctors and nurses who had seen or experienced the new system at the smaller pilot hospitals. Yet management is pushing on, and just decided the next big hospital should get the new system this spring, despite the many severe issues that are still unsolved. [1]: https://www.nrk.no/emne/helseplattformen-1.15838445 https://www.nrk.no/emne/helseplattformen-1.15838445
- hasty_pudding 3y ago
  That's not good management though. Recognizing you fucked up and only cost the company tens of millions instead of hundreds of millions is "Not Terrible" management.
  - prepend 3y ago
    It’s not perfect, but it’s good. Or better than spending more.
    - hasty_pudding 3y ago

DeathArrow 3y ago

If anything, this highlights the dangers of building your app around the details of a particular clod infrastructure.

PeterStuer 3y ago
I guess in this case it was the other way around: building the cloud architecture specific to the needs of the app.
- alephnan 3y ago
  It’s not a good cloud if they built the wrong abstractions that aren’t generic

junto 3y ago

From that repo: > At LinkedIn, we are focusing our efforts on advanced automation to enable a seamless, LinkedIn-wide migration from Rest.li to gRPC. gRPC will offer better performance, support for more programming languages, streaming, and a robust open source community. There is no active development at LinkedIn on new features for Rest.li. The repository will also be deprecated soon once we have migrated services to use gRPC. Refer to this blog for more details on why we are moving to gRPC.