4 ms·

Vendor lock-in is a serious issue. But there is an upside. Say you're building a serverless API. Say you build it using pyhton flask or bottle. You can use a pa

Vendor lock-in is a serious issue. But there is an upside. Say you're building a serverless API. Say you build it using pyhton flask or bottle. You can use a packaging framework such as Zappa such that it can be deployed to serverless hosting or it can run in uwsgi / nginx on a server. Id be delighted to see a universally adopted standard specification for serverless computing including management interfaces and platform compatibility. The sort of specification that competing Cloud providers could implement thus better empowering consumers like myself. I have faith it will come around eventually all of this is relatively new

StreamBright 8y ago
Is it though? I think the possibility to move to another solution is the way to deal with vendor lock in. Simple example, one of my clients wanted to move to AWS but they were super afraid of lock in. We had to create exit strategy for them with cost analysis and now they are happily using AWS services knowing they can move to GCP or something else for a certain amount of money.
- pweissbrod 8y ago
  Glad to hear things worked out for your client. The key thing is, YOU had to create an exit strategy just for your client. If the specifications for the serverless platform were "open" then the client could move their stack to different vendor with insignificant planning/risk. An analogy would be vendors somehow changing machine virtualization such that your code was required to be very hypervisor-aware to function, and porting from vmware to xen imposed significant cost and risk.
  - StreamBright 8y ago
    I am not sure how much of this is not already mitigated with https://serverless.com https://serverless.com. I have never used Lambda without it. For me serverless.com is the solution to avoid vendor lock in. However, Lambda is a tiny fraction of the entire stack we are talking about here. S3 + EMR + ALB + EC2 are all there and they are much more difficult to dodge the vendor lock in bullet with. One particularly sticky vendor lock in for S3 is pricing and reliability. Unfortunately it is almost impossible to beat that. My clients just discovered this, it would be significantly more expensive to move from S3 to HDFS or any other storage solution. This has nothing to do with how open the platform is, yet it is a much more serious lock in.
carimura 8y ago
This is what the CNCF is trying to achieve with Kubernetes as a foundation for managing compute/containerized workloads. If we lay down the right set of abstractions for app developers then the theory is the workloads become somewhat portable. Think of it as the core AWS services generalized as kubernetes services -- and k8s (or even stuff on top in theory) could still be managed by the provider. The problem for the CNCF and its projects is you can almost always move quicker if subscribing to the walled gardens of the major vendors... even if the experience is less than optimal and definitely not portable. Hopefully this changes over the next year as better abstractions (think Fn Project/Knative/Rook/someDB) and even some standards (cloudevents) emerge. That said I suppose data could be traditional DB's (sql/nosql) managed by k8s... not sure about this yet.

StreamBright 8y ago

Is it though? I think the possibility to move to another solution is the way to deal with vendor lock in. Simple example, one of my clients wanted to move to AWS but they were super afraid of lock in. We had to create exit strategy for them with cost analysis and now they are happily using AWS services knowing they can move to GCP or something else for a certain amount of money.

pweissbrod 8y ago
Glad to hear things worked out for your client. The key thing is, YOU had to create an exit strategy just for your client. If the specifications for the serverless platform were "open" then the client could move their stack to different vendor with insignificant planning/risk. An analogy would be vendors somehow changing machine virtualization such that your code was required to be very hypervisor-aware to function, and porting from vmware to xen imposed significant cost and risk.
- StreamBright 8y ago
  I am not sure how much of this is not already mitigated with https://serverless.com https://serverless.com. I have never used Lambda without it. For me serverless.com is the solution to avoid vendor lock in. However, Lambda is a tiny fraction of the entire stack we are talking about here. S3 + EMR + ALB + EC2 are all there and they are much more difficult to dodge the vendor lock in bullet with. One particularly sticky vendor lock in for S3 is pricing and reliability. Unfortunately it is almost impossible to beat that. My clients just discovered this, it would be significantly more expensive to move from S3 to HDFS or any other storage solution. This has nothing to do with how open the platform is, yet it is a much more serious lock in.

carimura 8y ago

This is what the CNCF is trying to achieve with Kubernetes as a foundation for managing compute/containerized workloads. If we lay down the right set of abstractions for app developers then the theory is the workloads become somewhat portable. Think of it as the core AWS services generalized as kubernetes services -- and k8s (or even stuff on top in theory) could still be managed by the provider. The problem for the CNCF and its projects is you can almost always move quicker if subscribing to the walled gardens of the major vendors... even if the experience is less than optimal and definitely not portable. Hopefully this changes over the next year as better abstractions (think Fn Project/Knative/Rook/someDB) and even some standards (cloudevents) emerge. That said I suppose data could be traditional DB's (sql/nosql) managed by k8s... not sure about this yet.