5 ms·

Why use serverless to begin with? Vendor lock in, at least 5x more expensive, no good development env - what is the appeal?

pydry 5y ago
Not to mention all sorts of built-in limits.
joshuanapoli 5y ago
The expense depends on your use-case. I think that some SaaS products would be cheaper to host on Lambda. We have short bursts of high load, which led to quite a bit of waste with provisioning of traditional application servers and database. After moving from traditional servers to Lambda, we had lower hosting cost. After switching, it is easier to deploy new back-end features. It is easier to provision a sandbox for development.
- qaq 5y ago
  so $50 a month you would save over fargate is worth all the hussle
  - joshuanapoli 5y ago
    In our case, the cost savings were significant. More important, we have operational improvements: safer delivery of new features, comprehensive metrics, and comprehensive alerting. Of course, there are many ways of achieving these goals. Kubernetes has great ways of doing the same with less vendor lock-in, but requiring more knowledge and care with the system components.
  - 0xB31B1B 5y ago
    fargate is "serverless" and has the same vendor lock in that lambda does
    - qaq 5y ago
      if you have run of the mill monolith deployed to Fargate that uses say RDS Postgres there is virtually no locking.
      - 0xB31B1B 5y ago
        If you run “run of the mill” lambdas that use postgres, there is virtually no locking as well (every cloud provider has lambdas)
huffmsa 5y ago
We use them for things that require unpredictable but immediate bursts of scaled parallel processing
0xB31B1B 5y ago
Vendor lock in is a non issue. Prices have been dropping across the board for basically all cloud services across all providers as long as cloud has been a thing. While the hosting itself might be 5x more expensive, you can generally run a large scale app on serverless infra with 20% of the SRE/platform headcount, and for nearly every engineering company the savings in salary costs and focus on product instead of platform will pay for themself very quickly and become a huge asset in the long run.
- pxc 5y ago
  From a skills perspective, the vendor lock-in still bothers me on a personal level. What's interesting about learning to push the right buttons on one company's black box, especially when I know it's likely powered by or equivalent to familiar F/OSS?
  - 0xB31B1B 5y ago
    It’s not about what is interesting; it’s about what is productive. Kubernetes is interesting but I would not launch a project in it at a scale smaller than say 20M USD/year hosting costs because you’ll probably be able to make a higher quality project in a faster time if you use hosted/3rd party solutions
    - pxc 5y ago
      An engineer's choice of where to work or what skills to develop is definitely (in part) about what is interesting.
derriz 5y ago
One selling point is “free” horizontal scaling possibility. Contrived example: you’ve a parallelizable workload but the work arrives sporadically. 600 pieces of 10 minutes work arrive. In theory, instead of waiting 10 hours to process the batch on a single instance - lambda will fire up 600 instances completing the batch in 10 minutes. And 1 cloud CPU for ten hours costs the same as 600 for 10 minutes. In practice, you spend more time writing lambda specific code and changing an obvious workflow to avoid DB access becoming a bottleneck or debugging why published events did not trigger the correct function, etc. that you wonder whether throwing cpu/memory/disk resources at a single instance tuned for the workload with dedicated local SSD storage might have been a better option especially as tasks around logging, persistent storage, debugging, profiling, error handling and getting stack traces are so much easier.
pxc 5y ago
Yeah, I don't really see the appeal, either. I thought part of the point of something like this was that you no longer had to manage or think about the environment you're deploying to in the same level of detail. But clearly you do, except now the resources, permissions, versioning, and costs you have to think about are all specific to various parts of AWS, which are locked in, probably more expensive, and probably less familiar than their counterparts on operating systems or in containers. Seems like a lot of work for a kind of scalability that leaves you with little insight into how it works, idk
meekins 5y ago
Security, ability to outsource pretty much everything ops-related besides cloud resource provisioning and deployments to the cloud provider and developer focus on business logic. I don't know a better dev environment than a (possibly scaled down) personal replica of production environment in the cloud. With proper tooling (e.g. Serverless Stack or SAM) you can achieve very fast code updates so the old argument of slow feedback due to having to deploy changes to the cloud on each iteration is getting less and less true as well. With more traditional models already keeping your OS, possible container images, web server and any other middleware secure and up-to-date is pretty expensive if you want to do it properly. Going all-in on serverless might not make much sense for a large software product company but when building bespoke business software it allows small teams to do wonderful things very cost-effectively.
andrew_ 5y ago
Is "Vendor lock-in" a good argument anymore? I've never been with a company that's moved cloud providers, and I'd bet it's a pretty rare case.

pydry 5y ago

Not to mention all sorts of built-in limits.

joshuanapoli 5y ago

The expense depends on your use-case. I think that some SaaS products would be cheaper to host on Lambda. We have short bursts of high load, which led to quite a bit of waste with provisioning of traditional application servers and database. After moving from traditional servers to Lambda, we had lower hosting cost. After switching, it is easier to deploy new back-end features. It is easier to provision a sandbox for development.

qaq 5y ago
so $50 a month you would save over fargate is worth all the hussle
- joshuanapoli 5y ago
  In our case, the cost savings were significant. More important, we have operational improvements: safer delivery of new features, comprehensive metrics, and comprehensive alerting. Of course, there are many ways of achieving these goals. Kubernetes has great ways of doing the same with less vendor lock-in, but requiring more knowledge and care with the system components.
- 0xB31B1B 5y ago
  fargate is "serverless" and has the same vendor lock in that lambda does
  - qaq 5y ago
    if you have run of the mill monolith deployed to Fargate that uses say RDS Postgres there is virtually no locking.
    - 0xB31B1B 5y ago
      If you run “run of the mill” lambdas that use postgres, there is virtually no locking as well (every cloud provider has lambdas)

huffmsa 5y ago

We use them for things that require unpredictable but immediate bursts of scaled parallel processing

0xB31B1B 5y ago

Vendor lock in is a non issue. Prices have been dropping across the board for basically all cloud services across all providers as long as cloud has been a thing. While the hosting itself might be 5x more expensive, you can generally run a large scale app on serverless infra with 20% of the SRE/platform headcount, and for nearly every engineering company the savings in salary costs and focus on product instead of platform will pay for themself very quickly and become a huge asset in the long run.

pxc 5y ago
From a skills perspective, the vendor lock-in still bothers me on a personal level. What's interesting about learning to push the right buttons on one company's black box, especially when I know it's likely powered by or equivalent to familiar F/OSS?
- 0xB31B1B 5y ago
  It’s not about what is interesting; it’s about what is productive. Kubernetes is interesting but I would not launch a project in it at a scale smaller than say 20M USD/year hosting costs because you’ll probably be able to make a higher quality project in a faster time if you use hosted/3rd party solutions
  - pxc 5y ago
    An engineer's choice of where to work or what skills to develop is definitely (in part) about what is interesting.

derriz 5y ago

One selling point is “free” horizontal scaling possibility. Contrived example: you’ve a parallelizable workload but the work arrives sporadically. 600 pieces of 10 minutes work arrive. In theory, instead of waiting 10 hours to process the batch on a single instance - lambda will fire up 600 instances completing the batch in 10 minutes. And 1 cloud CPU for ten hours costs the same as 600 for 10 minutes. In practice, you spend more time writing lambda specific code and changing an obvious workflow to avoid DB access becoming a bottleneck or debugging why published events did not trigger the correct function, etc. that you wonder whether throwing cpu/memory/disk resources at a single instance tuned for the workload with dedicated local SSD storage might have been a better option especially as tasks around logging, persistent storage, debugging, profiling, error handling and getting stack traces are so much easier.

pxc 5y ago

Yeah, I don't really see the appeal, either. I thought part of the point of something like this was that you no longer had to manage or think about the environment you're deploying to in the same level of detail. But clearly you do, except now the resources, permissions, versioning, and costs you have to think about are all specific to various parts of AWS, which are locked in, probably more expensive, and probably less familiar than their counterparts on operating systems or in containers. Seems like a lot of work for a kind of scalability that leaves you with little insight into how it works, idk

meekins 5y ago

Security, ability to outsource pretty much everything ops-related besides cloud resource provisioning and deployments to the cloud provider and developer focus on business logic. I don't know a better dev environment than a (possibly scaled down) personal replica of production environment in the cloud. With proper tooling (e.g. Serverless Stack or SAM) you can achieve very fast code updates so the old argument of slow feedback due to having to deploy changes to the cloud on each iteration is getting less and less true as well. With more traditional models already keeping your OS, possible container images, web server and any other middleware secure and up-to-date is pretty expensive if you want to do it properly. Going all-in on serverless might not make much sense for a large software product company but when building bespoke business software it allows small teams to do wonderful things very cost-effectively.

andrew_ 5y ago

Is "Vendor lock-in" a good argument anymore? I've never been with a company that's moved cloud providers, and I'd bet it's a pretty rare case.