4 ms·

The whole "serverless" fad is about lock-in. I also really wish they would not have squatted that term. It should refer to decentralized P2P systems which are

by api 6y ago

The whole "serverless" fad is about lock-in. I also really wish they would not have squatted that term. It should refer to decentralized P2P systems which are truly serverless.

minitoar 6y ago
Even without serverless you are pretty locked in. Things like Terraform help but the level of cloud integration required for a complex system is pretty overwhelming.
- api 6y ago
  If its "required" you need to think more. We use GCP and GKS for some things, but we could leave pretty easily. Hardest parts would be DIY Postgres HA and DIY K8S. CockroachDB is almost ready to get rid of the former headache. Haven't looked into the latter headache yet. Of course we really only use K8S for load balancing and HA and there are other options there like Consul and Nomad.
  - nrki 6y ago
    Try Patroni for Postgres HA, seems really trivial.
  - minitoar 6y ago
    I’m glad you are able to move your use case easily!
staticassertion 6y ago
I build off of serverless. Not very locked in - I wrote my service to run locally without any AWS services at one point. The main 'lock in' has nothing to do with serverless - it's DynamoDB. DynamoDB is really good so I'm reluctant to port to other clouds without something that has a very similar model. If having a really good service is "lock-in", sure, we're locked in.
rumanator 6y ago
> The whole "serverless" fad is about lock-in. I don't believe that's true at all. Serverless stuff in gener and function-as-a-service solutions such as the example described in this discussion in particular is in my opinion about placing the needs of the service provider before the needs of the customers. More specifically, it's about enabling the service provider to waste less computational resources while providing the exact same service. For example, how many VM instances would you need to put up an API Gateway distributing a couple of HTTP requests to at least one instance of a HTTP server whose only responsibility is to trigger a workflow or update a database? How many instances would you need to keep up to keep a database running that barely has 2 or 3 tables? How many instances would you need to launch to run a batch job that does nothing more than sniff a bunch of files? Without considering any concern with availability, that's about 3 to 4 instances. All idling, and mostly running support stuff that needs to be there just for your service to be able to handle a request. This might be your go-to solution for this sort of service, but in the eyes of a service provider that is sinfully wasteful. I mean, half a dozen instances with a utilization rate that barely breaks off 50% just to do the same thing everybody else is already doing? So, why not cut with all that bullshit and simply tweak a shared API Gateway/message broker/background task/workflow automation/pubsub/database/data store service to do the stuff you need to do? If you use the communal service and let the service provider manage it with it's dedicated staff, the company doesn't waste half of its computational resources idling by or just duplicating the service everyone is already using. That's less hardware to power, less hardware to provision, less hardware to maintain, less spiky hardware utilization rates... Less work and less costs. If you want to discuss lock-in then focus on IAM. Everything else is a way to help the service provider better utilize their current capabilities.

by api 6y ago

The whole "serverless" fad is about lock-in. I also really wish they would not have squatted that term. It should refer to decentralized P2P systems which are truly serverless.

minitoar 6y ago

Even without serverless you are pretty locked in. Things like Terraform help but the level of cloud integration required for a complex system is pretty overwhelming.

api 6y ago
If its "required" you need to think more. We use GCP and GKS for some things, but we could leave pretty easily. Hardest parts would be DIY Postgres HA and DIY K8S. CockroachDB is almost ready to get rid of the former headache. Haven't looked into the latter headache yet. Of course we really only use K8S for load balancing and HA and there are other options there like Consul and Nomad.
- nrki 6y ago
  Try Patroni for Postgres HA, seems really trivial.
- minitoar 6y ago
  I’m glad you are able to move your use case easily!

staticassertion 6y ago

I build off of serverless. Not very locked in - I wrote my service to run locally without any AWS services at one point. The main 'lock in' has nothing to do with serverless - it's DynamoDB. DynamoDB is really good so I'm reluctant to port to other clouds without something that has a very similar model. If having a really good service is "lock-in", sure, we're locked in.

rumanator 6y ago

> The whole "serverless" fad is about lock-in. I don't believe that's true at all. Serverless stuff in gener and function-as-a-service solutions such as the example described in this discussion in particular is in my opinion about placing the needs of the service provider before the needs of the customers. More specifically, it's about enabling the service provider to waste less computational resources while providing the exact same service. For example, how many VM instances would you need to put up an API Gateway distributing a couple of HTTP requests to at least one instance of a HTTP server whose only responsibility is to trigger a workflow or update a database? How many instances would you need to keep up to keep a database running that barely has 2 or 3 tables? How many instances would you need to launch to run a batch job that does nothing more than sniff a bunch of files? Without considering any concern with availability, that's about 3 to 4 instances. All idling, and mostly running support stuff that needs to be there just for your service to be able to handle a request. This might be your go-to solution for this sort of service, but in the eyes of a service provider that is sinfully wasteful. I mean, half a dozen instances with a utilization rate that barely breaks off 50% just to do the same thing everybody else is already doing? So, why not cut with all that bullshit and simply tweak a shared API Gateway/message broker/background task/workflow automation/pubsub/database/data store service to do the stuff you need to do? If you use the communal service and let the service provider manage it with it's dedicated staff, the company doesn't waste half of its computational resources idling by or just duplicating the service everyone is already using. That's less hardware to power, less hardware to provision, less hardware to maintain, less spiky hardware utilization rates... Less work and less costs. If you want to discuss lock-in then focus on IAM. Everything else is a way to help the service provider better utilize their current capabilities.