5 ms·

For me, my main problem with "vendor lock-in" is not the switching cost. I'm not planning to switch vendor any time soon. For me it's more about the black-box n

by janpot 7y ago

For me, my main problem with "vendor lock-in" is not the switching cost. I'm not planning to switch vendor any time soon. For me it's more about the black-box nature of their solution. It's usually proprietary, closed-source solutions that put you at their complete mercy when things go wrong. It's not debuggable, I can't run it on my laptop, I can't look inside how it works, I can't make changes to it, I can't run my own, slightly modified version of it, etc...

skohan 7y ago
Yeah I am currently working on a project which leans pretty heavily on AWS components, and can be very time consuming when something doesn't work the way it should. Even the paid support isn't that great either: a lot of times you end up chatting with someone who provides you the same links you just googled which didn't solve your problem, and more often than not the end result is a ticket being created somewhere, which will be addressed in who-knows-how-long if ever.
scarface74 7y ago
Out of all the open source code you use, how much of it have you ever inspected and not treated as a “black box”? Most of AWS’s proprietary services have a way that you can simulate running them on your laptop.
- janpot 7y ago
  Many. 100% of the times I've used one of those local versions, I've ran into incompatibilities with the real service.
  - scarface74 7y ago
    Which ones?
    - janpot 7y ago
      Not sure what you mean here but OS projects that come to mind that we haven't treated as a black-box at some point are kubernetes, docker, node, chromium, rabbitmq, postgres and every JavaScript module we use. Two local services that come to mind that we have used and that didn't work like the AWS equivalent is dynalite and fake-s3.
      - scarface74 7y ago
        I mean have you actually inspected the source code and/or made changes to suit your needs for infrastructure level resources where there is a managed equivalent?
        janpot 7y ago
        Yes

by janpot 7y ago

skohan 7y ago

Yeah I am currently working on a project which leans pretty heavily on AWS components, and can be very time consuming when something doesn't work the way it should. Even the paid support isn't that great either: a lot of times you end up chatting with someone who provides you the same links you just googled which didn't solve your problem, and more often than not the end result is a ticket being created somewhere, which will be addressed in who-knows-how-long if ever.

scarface74 7y ago

Out of all the open source code you use, how much of it have you ever inspected and not treated as a “black box”? Most of AWS’s proprietary services have a way that you can simulate running them on your laptop.

janpot 7y ago
Many. 100% of the times I've used one of those local versions, I've ran into incompatibilities with the real service.
- scarface74 7y ago
  Which ones?
  - janpot 7y ago
    Not sure what you mean here but OS projects that come to mind that we haven't treated as a black-box at some point are kubernetes, docker, node, chromium, rabbitmq, postgres and every JavaScript module we use. Two local services that come to mind that we have used and that didn't work like the AWS equivalent is dynalite and fake-s3.
    - scarface74 7y ago
      I mean have you actually inspected the source code and/or made changes to suit your needs for infrastructure level resources where there is a managed equivalent?
      - janpot 7y ago
        Yes