4 ms·

What's this talk about "no vendor lock-in"? i though that(lock-in) was the idea behind AWS's many services.

• qntmfred 11y ago
  it is. at the AWS Summit NYC in July you heard them say "All In" about a billion times
• fweespeech 11y ago
  Its a tech journalist that doesn't understand AWS is built around being the vendor you are locked into.
• airza 11y ago
  not really, everything i've used so far is pretty interoperable with whatever. The exception I guess would be their metaservices that do logging and auditing of AWS services, but the SDK is pretty developed to let you shove, say, S3 into whatever you want. I'm open to be corrected on this but I don't think it's good to confuse "our different offerings have lots of interoperable synergy" with "it's fucking impossible to migrate off this"
  • adamc 11y ago
    Personally, I don't think lock-in means "it's fucking impossible to migrate off this". It just means it will be sufficiently painful that it is a strong deterrent. A service can be great and still come with a lot of lock-in; it's just another trade-off to consider.
    • airza 11y ago
      Okay, what do you think is painful about migrating off of AWS that is unique to their design? Or painful about it at all?
      • adamc 11y ago
        I don't have the right experience to answer that.
  • rsync 11y ago
    "but the SDK is pretty developed to let you shove, say, S3 into whatever you want." I can attest to this: ssh user@rsync.net s3cmd get s3://rsync/mscdex.exe Works as you'd expect it to.
• choppaface 11y ago
  In this context, lock-in is a function of the size of the AWS user's engineering team, and I don't think the NYT Author thoroughly understands this aspect of the problem. It wouldn't be infeasible to, say, move from S3 to OpenStack Swift, but that project is much more feasible for either a large team or a small team with very little data. Similarly, one could use say RabbitMQ instead of AWS SQS, but that takes a bit of effort. The availability of Docker images (and, eventually, k8s- or Swarm-orchestrated cloud apps) helps here too. While AWS might have proprietary APIs, the semantics of those APIs (e.g. 'enqueue this blob') don't entail very much proprietary magic. Instagram's post about moving off AWS is enlightening here: http://instagram-engineering.tumblr.com/post/89992572022/migrating-aws-fb http://instagram-engineering.tumblr.com/post/89992572022/mig... The problem isn't as bad as, say, writing your app in Objective-C or CUDA only to later find you don't want to ship to iOS or NVIDIA cards.