4 ms·

I don't worry about lock in in this particular case. At the platform level there is an element of implicit lock in because nobody else offers this exact service

by mryan 11y ago

I don't worry about lock in in this particular case. At the platform level there is an element of implicit lock in because nobody else offers this exact service. However, the application level can be easily moved to another platform. You could host the handler function code on an EC2 instance or bare-metal server. Little would change in the app code, except the API endpoint to which requests are sent. So IMHO there is no lock in in the traditional sense, but there is a switching cost if you want to move to another platform.

crdoconnor 11y ago
>At the platform level there is an element of implicit lock in because nobody else offers this exact service. That's kinda what I meant (although there seem to be some similar variants with totally different APIs). Anything similar will use a different API, as well. Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API and reimplement the glue code. >So IMHO there is no lock in in the traditional sense Lock-in doesn't mean that it's impossible to move to a different platform, it just means that there's a high cost. To me, it seems like the cost of moving this to some other platform is quite a bit higher than the cost of moving something from, say, EC2. Actually, it seems like this is Amazon's real business strategy with things like this. They want you to use all of their different services like this, SQS, SES, Elastic beanstalk, their hosted database thing. Individually the costs of moving away from all of them is not that high, but add them all together and it becomes immense.
- mryan 11y ago
  > Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API and reimplement the glue code. That's true. I think we're essentially on the same page here. I guess I'm still using the old definition of lock in. Poor example: a proprietary Microsoft format that can only be understood by MS software. There is literally no alternative to using MS software if you want to access files created using this format. Does "high switching cost" == "lock in"? I think it is a grey area. I would not consider myself locked in to Lambda if I had made the decision to host my app there, although I do see there is a high switching cost. However, if I used RDS Postgres and Amazon decided to prevent me from creating database dumps to migrate to a self-hosted Postgres, then I would be very unhappy because that would be an arbitrary restriction with no purpose except to keep me on AWS. > To me, it seems like the cost of moving this to some other platform is quite a bit higher than the cost of moving something from, say, EC2. I agree completely with this. Let's say this was implemented on EC2 instances running Ubuntu, and configured with something like Salt or Puppet. The cost of moving to a Digital Ocean box would be negligible.

by mryan 11y ago

crdoconnor 11y ago

>At the platform level there is an element of implicit lock in because nobody else offers this exact service. That's kinda what I meant (although there seem to be some similar variants with totally different APIs). Anything similar will use a different API, as well. Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API and reimplement the glue code. >So IMHO there is no lock in in the traditional sense Lock-in doesn't mean that it's impossible to move to a different platform, it just means that there's a high cost. To me, it seems like the cost of moving this to some other platform is quite a bit higher than the cost of moving something from, say, EC2. Actually, it seems like this is Amazon's real business strategy with things like this. They want you to use all of their different services like this, SQS, SES, Elastic beanstalk, their hosted database thing. Individually the costs of moving away from all of them is not that high, but add them all together and it becomes immense.

mryan 11y ago
> Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API and reimplement the glue code. That's true. I think we're essentially on the same page here. I guess I'm still using the old definition of lock in. Poor example: a proprietary Microsoft format that can only be understood by MS software. There is literally no alternative to using MS software if you want to access files created using this format. Does "high switching cost" == "lock in"? I think it is a grey area. I would not consider myself locked in to Lambda if I had made the decision to host my app there, although I do see there is a high switching cost. However, if I used RDS Postgres and Amazon decided to prevent me from creating database dumps to migrate to a self-hosted Postgres, then I would be very unhappy because that would be an arbitrary restriction with no purpose except to keep me on AWS. > To me, it seems like the cost of moving this to some other platform is quite a bit higher than the cost of moving something from, say, EC2. I agree completely with this. Let's say this was implemented on EC2 instances running Ubuntu, and configured with something like Salt or Puppet. The cost of moving to a Digital Ocean box would be negligible.