5 ms·

Two things, based on my experience (we migrated from Heroku to Lambda in 2016, so been there for a while) 1. you don’t need to worry about reserving capacity,

by adzicg 8y ago

Two things, based on my experience (we migrated from Heroku to Lambda in 2016, so been there for a while) 1. you don’t need to worry about reserving capacity, so you don’t need to pay for growth you expect to happen, or worry about not meeting a spike in demand if it happens 2. Most of the operations stuff (apart from packaging) is included in the price, so things like monitoring, alerts, dead-letter queues, traffic shifting beween canary versions, failovers, balancing... and it’s priced per request, so this comes to effectively free if you don’t have a lot of traffic. The big catch is that you don’t control the containers, so there’s no session stickiness. Getting the benefits from Lambda requires re-thinking how you do sessions and storage.

qaq 8y ago
That the thing though the dev overhead and limitations for startup with avg compute needs might be more $ than tiny savings (e.g who cares if it is $200/month vs $70/month) if it will cost 50k extra in dev time to architect for lambda
- scarface74 8y ago
  How is “architecting for lambda” harder than traditional architecture?
  - qaq 8y ago
    having persistent processes ? Not needing API gateway? Not having to learn a whole bunch of AWS services? Not having to work around latency? Having a simple system that easy to debug?
    - scarface74 8y ago
      If by “persistent processes” you mean storing state locally. You usually shouldn’t be counting on that anyway. My VMs are just as disposable as lambda. API Gateway - we use API Gateway even for our VM hosted APIs for the other features it provides. We also integrate with swagger so creating and maintaining our API Gateway set up is basically automatic. Not having to learn a bunch of AWS services - if you are using AWS for more than just hosting VMs, you would have to learn AWS anyway. Even if you are hosting a bunch of VMs, you still need to know about security groups, VPCs, subnets, ELBs, route 53, autoscsling etc. Creating a lambda is adding one function to your code. Easy to debug? Your code should not know nor care that you’re running serverlessly outside of your lambda handler. You test and debug your lambda code just like people have been testing APIs forever. You dry up a test harness that calls the entry point of your domain logic. I don’t mean real AAA automated test, just an entry point for manual debugging.
      - qaq 8y ago
        there is startup cost you pay in latency. You have to debug systems in prod not just in dev and debugging lambda used to be pretty crappy experience. "if you are using AWS for more than just hosting VMs" thats the thing the original question was how is better for avg starup than simple DO setup?
        scarface74 8y ago
        You debug systems in prod with lambda just like you do with anything else - via a good logging infrastructure. As far as how it’s better for a startup? With AWS I get hosted Load balancers, multi AZ redundancies, autoscaling, managed queues, databases with failover, a mobile push infrastructure, unlimited storage, etc. All stuff I don’t have to manage myself. There is absolutely no way that I could both develop and babysit infrastructure if it was all just a bunch of VMs. The money we save by not having a dedicated ops department and just one guy who does the grunt work more than makes up for the cost of AWS. Not to mention, the speed at which I can stand up infrastructure.
  - falcolas 8y ago
    Because you're immediately having to go to a MSA, which immediately adds a whole new layer of complexity, monitoring, network latency, API coordination, and configuration to otherwise simple webapps.
    - scarface74 8y ago
      In the case of .Net at least, you write your API like you always do and the SDK provides a wrapper. You can have multiple actions/controllers just like you would with a traditional Web API project. https://aws.amazon.com/blogs/developer/serverless-asp-net-core-2-0-applications/ https://aws.amazon.com/blogs/developer/serverless-asp-net-co... You test locally just like you would any other WebAPI project.
      - time0ut 8y ago
        Yup. You can do the same in the other languages as well if you want.
- tnolet 8y ago
  I would say architecting for Lambda is easier and quicker than “traditional” by now. Was a bit flaky in the beginning, admittedly.

by adzicg 8y ago

qaq 8y ago

That the thing though the dev overhead and limitations for startup with avg compute needs might be more $ than tiny savings (e.g who cares if it is $200/month vs $70/month) if it will cost 50k extra in dev time to architect for lambda

scarface74 8y ago
How is “architecting for lambda” harder than traditional architecture?
- qaq 8y ago
  having persistent processes ? Not needing API gateway? Not having to learn a whole bunch of AWS services? Not having to work around latency? Having a simple system that easy to debug?
  - scarface74 8y ago
    If by “persistent processes” you mean storing state locally. You usually shouldn’t be counting on that anyway. My VMs are just as disposable as lambda. API Gateway - we use API Gateway even for our VM hosted APIs for the other features it provides. We also integrate with swagger so creating and maintaining our API Gateway set up is basically automatic. Not having to learn a bunch of AWS services - if you are using AWS for more than just hosting VMs, you would have to learn AWS anyway. Even if you are hosting a bunch of VMs, you still need to know about security groups, VPCs, subnets, ELBs, route 53, autoscsling etc. Creating a lambda is adding one function to your code. Easy to debug? Your code should not know nor care that you’re running serverlessly outside of your lambda handler. You test and debug your lambda code just like people have been testing APIs forever. You dry up a test harness that calls the entry point of your domain logic. I don’t mean real AAA automated test, just an entry point for manual debugging.
    - qaq 8y ago
      there is startup cost you pay in latency. You have to debug systems in prod not just in dev and debugging lambda used to be pretty crappy experience. "if you are using AWS for more than just hosting VMs" thats the thing the original question was how is better for avg starup than simple DO setup?
      - scarface74 8y ago
        You debug systems in prod with lambda just like you do with anything else - via a good logging infrastructure. As far as how it’s better for a startup? With AWS I get hosted Load balancers, multi AZ redundancies, autoscaling, managed queues, databases with failover, a mobile push infrastructure, unlimited storage, etc. All stuff I don’t have to manage myself. There is absolutely no way that I could both develop and babysit infrastructure if it was all just a bunch of VMs. The money we save by not having a dedicated ops department and just one guy who does the grunt work more than makes up for the cost of AWS. Not to mention, the speed at which I can stand up infrastructure.
- falcolas 8y ago
  Because you're immediately having to go to a MSA, which immediately adds a whole new layer of complexity, monitoring, network latency, API coordination, and configuration to otherwise simple webapps.
  - scarface74 8y ago
    In the case of .Net at least, you write your API like you always do and the SDK provides a wrapper. You can have multiple actions/controllers just like you would with a traditional Web API project. https://aws.amazon.com/blogs/developer/serverless-asp-net-core-2-0-applications/ https://aws.amazon.com/blogs/developer/serverless-asp-net-co... You test locally just like you would any other WebAPI project.
    - time0ut 8y ago
      Yup. You can do the same in the other languages as well if you want.
tnolet 8y ago
I would say architecting for Lambda is easier and quicker than “traditional” by now. Was a bit flaky in the beginning, admittedly.