4 ms·

I would claim that the microservice architecture of AWS Lambda & API Gateway (which is generally associated with Serverless applications) is not what causes ven

by kennu 10y ago

I would claim that the microservice architecture of AWS Lambda & API Gateway (which is generally associated with Serverless applications) is not what causes vendor lock-in. It's pretty straightforward to implement the same environment to run your apps anywhere. Real vendor-lock-in is caused by use of proprietary backend services like DynamoDB, Redshift, Kinesis, etc. which cannot be used anywhere else than AWS.

chronid 10y ago
When you go "full serverless", you still need a place to store data, backups, etc. And then with the high cost of bandwith (...) you may as well use the same service provider you use for your "services". Be it AWS or GCloud or Azure. If you spin up servers to manage your database+storage needs, then you are no longer serverless, you are in a pretty nice hybrid - lowering somewhat your money costs maybe, but I'd still argue that the impact on ops of the "application servers" is negligible compared to what is required by everything else in the stack.
- WolfOliver 10y ago
  There is a slightly better name for "serverless architecture", its called "function as a service". But in my opinion "process on demand" would describe this concept even better.
WolfOliver 10y ago
I agree that DynamoDB, Kinesis, ... reinforce the vendor lock-in. But I'would say that easy to implement AWS Lambda & API Gateway.
- kennu 10y ago
  I would not be not easy to implement the full generic functionality of Lambda and API Gateway. But I think it would be fairly easy to just write some application-specific Express code to handle the API routing, and add some wrappers for Lambda calls, in order to migrate a single application.
- throwaway2016a 10y ago
  Kenesis and SES, maybe. But Dynamo would be pretty easy to replace with something like Mongo provided that you abstract your databases access code and don't have a lot of backend specific code missed with your business logic. A lot of serverless apps use Graphql for this purpose since Graphql is backend agnostic.

by kennu 10y ago

chronid 10y ago

When you go "full serverless", you still need a place to store data, backups, etc. And then with the high cost of bandwith (...) you may as well use the same service provider you use for your "services". Be it AWS or GCloud or Azure. If you spin up servers to manage your database+storage needs, then you are no longer serverless, you are in a pretty nice hybrid - lowering somewhat your money costs maybe, but I'd still argue that the impact on ops of the "application servers" is negligible compared to what is required by everything else in the stack.

WolfOliver 10y ago
There is a slightly better name for "serverless architecture", its called "function as a service". But in my opinion "process on demand" would describe this concept even better.

WolfOliver 10y ago

I agree that DynamoDB, Kinesis, ... reinforce the vendor lock-in. But I'would say that easy to implement AWS Lambda & API Gateway.

kennu 10y ago
I would not be not easy to implement the full generic functionality of Lambda and API Gateway. But I think it would be fairly easy to just write some application-specific Express code to handle the API routing, and add some wrappers for Lambda calls, in order to migrate a single application.
throwaway2016a 10y ago
Kenesis and SES, maybe. But Dynamo would be pretty easy to replace with something like Mongo provided that you abstract your databases access code and don't have a lot of backend specific code missed with your business logic. A lot of serverless apps use Graphql for this purpose since Graphql is backend agnostic.