3 ms·

i dunno. moving off heroku to another provider marking up aws or pretending to seems counterproductive. a go binary in a zip builds and uploads to lambda in 1

i dunno. moving off heroku to another provider marking up aws or pretending to seems counterproductive. a go binary in a zip builds and uploads to lambda in 1 second. handle routing and everything else in binary, don’t use aws features. you don’t need em. lambda, s3, and dynamo all scale to zero with usage based billing. toss in rds if you really miss sql or dislike scale to zero. once this is too expensive, move to ovh metal, which sells significantly faster compute, ie epyc 4244p ddr5 5200. more importantly, they sell bandwidth for $0.50/TB instead of $0.10/GB, which is aws price before paas wrapper markup. the ovh price is after the 1Gbps unmetered you get for free with any server. most companies will never even need metal, and between lambda and metal is ec2 spot, which might be of use anyway for elasticity. ovh metal bills monthly, ec2 spot bills by the second. recently i learned ec2 spot in localzones is x2-3 cheaper than standard spot. i only use r5.xlarge in los angeles these days. ovh metal has an old fashioned but perfectly workable api. aws has a great api. spend a few days figuring out a decent sdlc, and then freeze it permanently. it will grow insanely robust over time. i haven’t published my ovh metal workflows. my aws workflows are here[1]. lower overhead means more interesting products coming to market. lower friction definitely doesn’t hurt. viva le renaissance! 1. https://github.com/nathants/libaws https://github.com/nathants/libaws

swat535 2y ago
Exactly, I don't really see the point of migrating off Heroku unless you have scaled beyond it (in which case you are successful anyway) or are simply chasing distractions. For us, Heroku allows us to focus on the product and simply ship features which brings revenue and keeps everyone happy; it may not be sexy right now but it sure as heck is mature and stable with lots of integrations. Salesforce might eventually end up completely dismantling it but I'm hoping by that time other players can catch up.
- nathants 2y ago
  i haven’t used heroku. i assume it and all other x% aws-markup paas feel about the same. my point was that it’s not really needed. if you’re migrating off, you already have an sdlc that you like and want to preserve from provider degradation over time. simplify it a bit, and encode it directly into aws or ovh. then it’s permanent, and grows insanely robust over time. sdlc doesn’t not need to be constantly evolving. evolve it for the next greenfield product.
kdazzle 2y ago
API development on lambda has to be the worst devex I’ve ever had. Not sure if it was cuz we were also using Dynamo, a half-baked JS framework, or cuz we had wacky internal requirements pushed down (one ex: live-live multi-region deployments for our 0 users!) Maybe you’ve figured it out, but the local dev flow seemed pretty hacky/nonexistent. It also got expensive with real traffic
- nathants 2y ago
  single binary go workflow is great. net http. conditionals for routes. live updates in 1 second. no frameworks needed.
  - kdazzle 2y ago
    Thats cool - I’ll give it a shot with Go after I get over my PTSD.
    - nathants 2y ago
      good luck! only thing worse than dysfunctional companies is dysfunctional technology. someday we’ll get the incentives aligned properly, and thrive.

swat535 2y ago

Exactly, I don't really see the point of migrating off Heroku unless you have scaled beyond it (in which case you are successful anyway) or are simply chasing distractions. For us, Heroku allows us to focus on the product and simply ship features which brings revenue and keeps everyone happy; it may not be sexy right now but it sure as heck is mature and stable with lots of integrations. Salesforce might eventually end up completely dismantling it but I'm hoping by that time other players can catch up.

nathants 2y ago
i haven’t used heroku. i assume it and all other x% aws-markup paas feel about the same. my point was that it’s not really needed. if you’re migrating off, you already have an sdlc that you like and want to preserve from provider degradation over time. simplify it a bit, and encode it directly into aws or ovh. then it’s permanent, and grows insanely robust over time. sdlc doesn’t not need to be constantly evolving. evolve it for the next greenfield product.

kdazzle 2y ago

API development on lambda has to be the worst devex I’ve ever had. Not sure if it was cuz we were also using Dynamo, a half-baked JS framework, or cuz we had wacky internal requirements pushed down (one ex: live-live multi-region deployments for our 0 users!) Maybe you’ve figured it out, but the local dev flow seemed pretty hacky/nonexistent. It also got expensive with real traffic

nathants 2y ago
single binary go workflow is great. net http. conditionals for routes. live updates in 1 second. no frameworks needed.
- kdazzle 2y ago
  Thats cool - I’ll give it a shot with Go after I get over my PTSD.
  - nathants 2y ago
    good luck! only thing worse than dysfunctional companies is dysfunctional technology. someday we’ll get the incentives aligned properly, and thrive.