10 ms·

I don’t follow the logic in this argument. The same patterns work in other cloud platforms.

krn 8y ago
Serverless applications are attached to a single cloud platform they were built on top of. You can't switch between the platforms without changing the code. At its current stage, serverless is more like a hack.
- lostcolony 8y ago
  So is every managed service then; in AWS almost everything uses IAM and that's not portable. I can't use ECS; that's not portable. I can use EC2s, those are just VMs...except how the heck do I build those? I can't do it by hand, that's not portable, I can't use Cloudformations, that's not portable...I can't even use Terraform, as despite their marketing speak I still have to change out my configs, because they're still cloud dependent. Really, it's all a sliding scale. Buying into any cloud, even just at the VM level, means you've accepted your automation tools are going to be platform specific, and require changing recipes/configs/etc to go elsewhere. If you want to leverage anything beyond that, such as object storage (S3 in AWS, which is super common), then your code has to become aware of IAM and S3 endpoints. Your code now has to change if you want to deploy it elsewhere. I would contend your definition needs to be changed if the logical application of it basically makes everything more complex than 'someone else's server' to be "a hack"
  - krn 8y ago
    A public cloud only requires three things: compute instances, block storage, and object storage. Everything else is just an additional service built on top of these. If you use a cloud platform as an infrastructure provider, not as a software provider, there is no vendor lock-in. There are enough mature open-source tools even to build your own cloud on bare metal[1]. [1] https://maas.io/ https://maas.io/
    - lostcolony 8y ago
      How do you plan on accessing object storage in AWS (S3) from your code without also using IAM to authenticate/authorize requests to it?
      - krn 8y ago
        I prefer to use object storage powered by OpenStack Swift[1], which makes my application not attached to any proprietary API. [1] https://www.ovh.com/world/public-cloud/storage/object-storage/ https://www.ovh.com/world/public-cloud/storage/object-storag...
        lostcolony 8y ago
        There ya go then. Like I said; you're eschewing leveraging -any- managed service cloud providers give you, and instead just use bare VMs, and relying on cobbling together open source stuff, that you have to manage yourself, to build a solution. That's fine for those who have that kind of time, but some of us want to build things and push as many things onto the cloud provider as possible, so we don't have to deal with them. I like having out of the box authentication with Cognito, out of the box DBs with RDS and Dynamo, out of the box object storage with S3, Serverless as an option with the API Gateway and Lambda...and I'll worry about vendor lockin when Amazon ups the price of an AWS service.
        krn 8y ago
        You are right, I prefer highly scalable and proven in production open-source tools, such as Redis and Postgres, to managed services by some cloud provider. It comes as very little overhead, if you pick the right tools and master them, then re-use. But I understand your point about just connecting a bunch of APIs and being done with it, if you personally don't own the product, or if you are expecting to sell it soon. A nitpick: I don't host my own object storage, I just pick S3 alternatives that provide standard APIs to access them.
- deleted 8y ago
  [deleted]

krn 8y ago

Serverless applications are attached to a single cloud platform they were built on top of. You can't switch between the platforms without changing the code. At its current stage, serverless is more like a hack.

lostcolony 8y ago
So is every managed service then; in AWS almost everything uses IAM and that's not portable. I can't use ECS; that's not portable. I can use EC2s, those are just VMs...except how the heck do I build those? I can't do it by hand, that's not portable, I can't use Cloudformations, that's not portable...I can't even use Terraform, as despite their marketing speak I still have to change out my configs, because they're still cloud dependent. Really, it's all a sliding scale. Buying into any cloud, even just at the VM level, means you've accepted your automation tools are going to be platform specific, and require changing recipes/configs/etc to go elsewhere. If you want to leverage anything beyond that, such as object storage (S3 in AWS, which is super common), then your code has to become aware of IAM and S3 endpoints. Your code now has to change if you want to deploy it elsewhere. I would contend your definition needs to be changed if the logical application of it basically makes everything more complex than 'someone else's server' to be "a hack"
- krn 8y ago
  A public cloud only requires three things: compute instances, block storage, and object storage. Everything else is just an additional service built on top of these. If you use a cloud platform as an infrastructure provider, not as a software provider, there is no vendor lock-in. There are enough mature open-source tools even to build your own cloud on bare metal[1]. [1] https://maas.io/ https://maas.io/
  - lostcolony 8y ago
    How do you plan on accessing object storage in AWS (S3) from your code without also using IAM to authenticate/authorize requests to it?
    - krn 8y ago
      I prefer to use object storage powered by OpenStack Swift[1], which makes my application not attached to any proprietary API. [1] https://www.ovh.com/world/public-cloud/storage/object-storage/ https://www.ovh.com/world/public-cloud/storage/object-storag...
      - lostcolony 8y ago
        There ya go then. Like I said; you're eschewing leveraging -any- managed service cloud providers give you, and instead just use bare VMs, and relying on cobbling together open source stuff, that you have to manage yourself, to build a solution. That's fine for those who have that kind of time, but some of us want to build things and push as many things onto the cloud provider as possible, so we don't have to deal with them. I like having out of the box authentication with Cognito, out of the box DBs with RDS and Dynamo, out of the box object storage with S3, Serverless as an option with the API Gateway and Lambda...and I'll worry about vendor lockin when Amazon ups the price of an AWS service.
        krn 8y ago
        You are right, I prefer highly scalable and proven in production open-source tools, such as Redis and Postgres, to managed services by some cloud provider. It comes as very little overhead, if you pick the right tools and master them, then re-use. But I understand your point about just connecting a bunch of APIs and being done with it, if you personally don't own the product, or if you are expecting to sell it soon. A nitpick: I don't host my own object storage, I just pick S3 alternatives that provide standard APIs to access them.
deleted 8y ago
[deleted]