5 ms·

How about cost at scale? Amazon itself shifted Prime Video from serverless to mostly containers and it resulted in huge savings.

by qaq 2y ago

sitkack 2y ago
Without a link and a breakdown that makes no sense. We switched from blue to square and saw a honey suckle savings. Amazon runs both and serverless is a billing model. Many serverless runtimes consume containers. Serverless, like microservices are a design philosophy.
- bearjaws 2y ago
  https://archive.is/ehJbY https://archive.is/ehJbY > Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% > The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.
- _heimdall 2y ago
  Serverless is more of a billing philosophy than a design philosophy in my opinion. Serverless is all about outsourcing the infrastructure for scaling a micro service. How you design the service itself, or the system its a part of, can vary widely. There are definitely dedign constraints of going serverless, but I'd argue those are largely just the constraints of going with microservices rather than a monolith.
  - 9rx 2y ago
    > Serverless is all about outsourcing the infrastructure for scaling a micro service. Technically, it is all about removing the server from your application. The name literally tells you so. It is true that removing the server can offer some benefits in the scaling realm. In particular, it allows you to scale to 0 now that you no longer have to keep the process alive to serve requests. Of course, that is not tradeoff free. Scaling to 0 brings you right back to the old problem of slow initialization once a request does come in, which was the primary driver for why we moved to hosting the server in the application in the first place.
    - qaq 2y ago
      Scaling to 0 is pretty much the only benefit you get. Which is not much of a benefit at any reasonable scale. Fargate is same firecracker VMs as Lambda they just don't scale to 0.
      - 9rx 2y ago
        And even then it is not strictly necessary. Cloud Run comes to mind as offering the ability to scale to zero, yet allows (maybe even requires?) maintaining the server in the application. The real benefit of "serverless" is that you no longer have to worry about the server, it being removed. Granted, that is not a big worry much these days with all the great server frameworks available.
        qaq 2y ago
        I’d much rather write 20 lines of boilerplate code and a Dockerfile than deal with 100s lines of CDK code, distributed tracing, and the associated observability challenges.
        9rx 2y ago
        Some frameworks used to support serverless applications are completely over-engineered cesspools, no doubt, but it doesn't have to be that way.
        qaq 2y ago
        It has nothing to do with the framework if it's a web app you have to manage deploy of multiple lambdas and API gateway.
        9rx 2y ago
        Why? Just throw your program executable in the cgi-bin directory like we did in the olden days, go wash your hands, and then call it a day. Simple. Serverless! Serverless doesn't have to be over engineered-garbage, even if some bored technologists looking for a promotion and/or to pad their resume try their best to make it so.
- qaq 2y ago
  the pricing is different for the same amount of compute is that news for you? Lambda is priced an order of magnitude higher than fargate which is priced significantly higher than EC2. For small scale workloads your TCO might be lower with higher level abstraction.
  - sitkack 2y ago
    It is a billing switch, crazy that Amazon would publish a report of them do a rewrite of an application when the distinction is one of book keeping. You would think they would want to sell their expensive solution.
    - qaq 2y ago
      There is tangible overhead to all the extra tracking Lambda infra has to do.
dijit 2y ago
From what I recall about that situation, they had a really stupid architecture that was using S3 as intermediate storage and processing video multiple times on multiple stages. In fact, the solution still used serverless afaik: https://www.youtube.com/watch?v=BcMm0aaqnnI https://www.youtube.com/watch?v=BcMm0aaqnnI (take that u/UltraSane! https://news.ycombinator.com/item?id=42506205 https://news.ycombinator.com/item?id=42506205) It likely could have been solved by serverless too, by using local storage and having the pipeline condensed into a single action... FD: I'm not a fan of serverless for production anything.
- qaq 2y ago
  For the same amount of compute Lambda is priced far higher than Fargate which itself is priced higher than ec2. People run large workloads on k8s with base workload compute fully covered by dedicated ec2 instances not because it's fun, but because it saves you a lot of $.
  - dijit 2y ago
    Totally agree. But it's the python argument. Python is super slow, inefficient and let's say that the build environment is not so nice. However, it's so easy to write functioning software in python that the alternative sometimes is not more efficient code, it's no code. Lambda, in theory, follows a similar paradigm, if you can click a button and have a service that scales to zero (with logging and monitoring) then you're more likely to make toy webhooks and tiny services. If I have to make a build pipeline and a docker container and wrangle some yaml, configure service accounts and a service definition with the right labels and annotations. Well, that's a decent chunk of work that means I'm probably going to think a bit longer about even deploying my little toy service that might see one request a day. Going to reiterate though: I do not advocate for serverless in production. If you seriously think you're building something that will scale, it's fiscally illiterate to use a managed serverless provider.
    - qaq 2y ago
      If you under the impression that CI/CD and observability is easy with lambda I have a bridge to sell you. I worked on a large scale pure serverless project we wrote more CDK code than application code.

How about cost at scale? Amazon itself shifted Prime Video from serverless to mostly containers and it resulted in huge savings.

by qaq 2y ago

How about cost at scale? Amazon itself shifted Prime Video from serverless to mostly containers and it resulted in huge savings.

sitkack 2y ago

Without a link and a breakdown that makes no sense. We switched from blue to square and saw a honey suckle savings. Amazon runs both and serverless is a billing model. Many serverless runtimes consume containers. Serverless, like microservices are a design philosophy.

bearjaws 2y ago
https://archive.is/ehJbY https://archive.is/ehJbY > Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% > The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.
_heimdall 2y ago
Serverless is more of a billing philosophy than a design philosophy in my opinion. Serverless is all about outsourcing the infrastructure for scaling a micro service. How you design the service itself, or the system its a part of, can vary widely. There are definitely dedign constraints of going serverless, but I'd argue those are largely just the constraints of going with microservices rather than a monolith.
- 9rx 2y ago
  > Serverless is all about outsourcing the infrastructure for scaling a micro service. Technically, it is all about removing the server from your application. The name literally tells you so. It is true that removing the server can offer some benefits in the scaling realm. In particular, it allows you to scale to 0 now that you no longer have to keep the process alive to serve requests. Of course, that is not tradeoff free. Scaling to 0 brings you right back to the old problem of slow initialization once a request does come in, which was the primary driver for why we moved to hosting the server in the application in the first place.
  - qaq 2y ago
    Scaling to 0 is pretty much the only benefit you get. Which is not much of a benefit at any reasonable scale. Fargate is same firecracker VMs as Lambda they just don't scale to 0.
    - 9rx 2y ago
      And even then it is not strictly necessary. Cloud Run comes to mind as offering the ability to scale to zero, yet allows (maybe even requires?) maintaining the server in the application. The real benefit of "serverless" is that you no longer have to worry about the server, it being removed. Granted, that is not a big worry much these days with all the great server frameworks available.
      - qaq 2y ago
        I’d much rather write 20 lines of boilerplate code and a Dockerfile than deal with 100s lines of CDK code, distributed tracing, and the associated observability challenges.
        9rx 2y ago
        Some frameworks used to support serverless applications are completely over-engineered cesspools, no doubt, but it doesn't have to be that way.
        qaq 2y ago
        It has nothing to do with the framework if it's a web app you have to manage deploy of multiple lambdas and API gateway.
        9rx 2y ago
        Why? Just throw your program executable in the cgi-bin directory like we did in the olden days, go wash your hands, and then call it a day. Simple. Serverless! Serverless doesn't have to be over engineered-garbage, even if some bored technologists looking for a promotion and/or to pad their resume try their best to make it so.
qaq 2y ago
the pricing is different for the same amount of compute is that news for you? Lambda is priced an order of magnitude higher than fargate which is priced significantly higher than EC2. For small scale workloads your TCO might be lower with higher level abstraction.
- sitkack 2y ago
  It is a billing switch, crazy that Amazon would publish a report of them do a rewrite of an application when the distinction is one of book keeping. You would think they would want to sell their expensive solution.
  - qaq 2y ago
    There is tangible overhead to all the extra tracking Lambda infra has to do.

dijit 2y ago

From what I recall about that situation, they had a really stupid architecture that was using S3 as intermediate storage and processing video multiple times on multiple stages. In fact, the solution still used serverless afaik: https://www.youtube.com/watch?v=BcMm0aaqnnI https://www.youtube.com/watch?v=BcMm0aaqnnI (take that u/UltraSane! https://news.ycombinator.com/item?id=42506205 https://news.ycombinator.com/item?id=42506205) It likely could have been solved by serverless too, by using local storage and having the pipeline condensed into a single action... FD: I'm not a fan of serverless for production anything.

qaq 2y ago
For the same amount of compute Lambda is priced far higher than Fargate which itself is priced higher than ec2. People run large workloads on k8s with base workload compute fully covered by dedicated ec2 instances not because it's fun, but because it saves you a lot of $.
- dijit 2y ago
  Totally agree. But it's the python argument. Python is super slow, inefficient and let's say that the build environment is not so nice. However, it's so easy to write functioning software in python that the alternative sometimes is not more efficient code, it's no code. Lambda, in theory, follows a similar paradigm, if you can click a button and have a service that scales to zero (with logging and monitoring) then you're more likely to make toy webhooks and tiny services. If I have to make a build pipeline and a docker container and wrangle some yaml, configure service accounts and a service definition with the right labels and annotations. Well, that's a decent chunk of work that means I'm probably going to think a bit longer about even deploying my little toy service that might see one request a day. Going to reiterate though: I do not advocate for serverless in production. If you seriously think you're building something that will scale, it's fiscally illiterate to use a managed serverless provider.
  - qaq 2y ago
    If you under the impression that CI/CD and observability is easy with lambda I have a bridge to sell you. I worked on a large scale pure serverless project we wrote more CDK code than application code.