Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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...


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.


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.


Many.

100% of the times I've used one of those local versions, I've ran into incompatibilities with the real service.


Which ones?


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.


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?


Yes




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: