4 ms·

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 billin

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.
  - _heimdall 2y ago
    > Technically, it is all about removing the server from your application. Technically its about removing the server from my list of responsibilities. There is still a server running my app, it just isn't managed by me and likely comes with auto-scaling features.
    - 9rx 2y ago
      > Technically its about removing the server from my list of responsibilities. Not necessarily. Back in the serverless CGI days you would still typically manage Apache. What you say is probably why would you choose serverless in 2025, but not always. This is not the technical differentiation. > There is still a server running my app There may be a separate server (e.g. Apache) that runs your app, but that is someone else's app, not your app. Calling someone else's app your own would be rather silly. Your application is less a server, which is a change from how these applications had normally been written over the past couple of decades. At least since the death of CGI, you would traditionally see your application become the server (possibly proxied through another server, but that is ultimately immaterial to the discussion). That is what goes away with serverless.
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.

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.
- _heimdall 2y ago
  > Technically, it is all about removing the server from your application. Technically its about removing the server from my list of responsibilities. There is still a server running my app, it just isn't managed by me and likely comes with auto-scaling features.
  - 9rx 2y ago
    > Technically its about removing the server from my list of responsibilities. Not necessarily. Back in the serverless CGI days you would still typically manage Apache. What you say is probably why would you choose serverless in 2025, but not always. This is not the technical differentiation. > There is still a server running my app There may be a separate server (e.g. Apache) that runs your app, but that is someone else's app, not your app. Calling someone else's app your own would be rather silly. Your application is less a server, which is a change from how these applications had normally been written over the past couple of decades. At least since the death of CGI, you would traditionally see your application become the server (possibly proxied through another server, but that is ultimately immaterial to the discussion). That is what goes away with serverless.

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.