[HN Gopher] Moving Off Heroku, Slowly
___________________________________________________________________
Moving Off Heroku, Slowly
Author : craigkerstiens
Score : 42 points
Date : 2024-11-03 21:18 UTC (1 hours ago)
(HTM) web link (jamie.ideasasylum.com)
(TXT) w3m dump (jamie.ideasasylum.com)
| ko_pivot wrote:
| This is a great article but one thing it doesn't discuss is the
| importance of who the underlying cloud provider is. Many
| companies are pretty locked into AWS for better and for worse,
| regardless of whether they use things like lambda that are known
| for lock-in. Just the fact that you can use crunchydata,
| redis.com, and heroku is a reflection of being on AWS under the
| hood. Moving to something like fly.io or railway means
| introducing internet egress between your services.
| perteraul wrote:
| It sort of seems to me that Heroku stopped development /
| experiments after getting a bunch of traction. They were spot on
| solving a specific problem, early, and as time went on, said
| problem became a non-issue?
| eloisius wrote:
| For a long time, they operated more or less like an independent
| org after the Salesforce acquisition. Eventually they've been
| pulled into the ecosystem though, and now it has the on-brand
| feel: 10+ second page loads, weird breakage like it taking two
| tries to click the SSO links to open addons like New Relic,
| needing to re-auth too often. It's a shame.
| bigfatkitten wrote:
| A lot of the key talent also moved on.
| bdndndndbve wrote:
| Salesforce bought Heroku in 2011. Also every cloud provider has
| an in-house "good enough" PaaS at this point.
| alexpetralia wrote:
| What used to be the "Oracle Effect" has now become the
| "Salesforce Effect".
| jmduke wrote:
| This dovetails with my own experience more or less exactly: when
| I launched my company, it was easy to throw everything on Heroku,
| and to their credit and detriment it was also fairly easy to move
| pretty much everything _off_ of Heroku (RDS for a database,
| RedisLabs for, well, Redis, and so on.)
|
| Back in 2021 (https://news.ycombinator.com/item?id=29648325,
| https://news.ycombinator.com/item?id=30177907) and 2022
| (https://news.ycombinator.com/item?id=32608734) Heroku went from
| "well this is costing enough that it probably makes sense to
| divest at some point and save the $X00/mo" to "Heroku is now the
| biggest systemic risk to uptime that I have", and it felt _very_
| high-priority to get off of them and onto someone else.
|
| Two years later, though... the inclination has ebbed. Heroku
| hasn't shipped anything meaningful for my use case in the past 24
| months, but also they have been fairly stable. I'm sure I will
| migrate off of them onto something else in the fullness of time,
| but it would take a pretty severe precipitating event.
| Eikon wrote:
| These platforms enable horizontal scaling, but ironically, many
| apps only need to scale horizontally because the base instances
| offer such underwhelming specs.
|
| It's frustrating to see engineering teams in 2024 spending
| countless hours optimizing their applications to run on what
| essentially amounts to 2008-era hardware configurations.
| ko_pivot wrote:
| This is one reason AWS Fargate is so good. No, it isn't
| developer friendly, but it gives you performance that actually
| matches the CPU allocation while still abstracting the VMs.
| cyberax wrote:
| We migrated from Heroku to AWS ECS and Fargate.
|
| It's not hard, and it provides a nice managed service without
| the full complexity of running K8s.
| stackskipton wrote:
| Ops person here, by moving Redis/PostGres to Redis
| Inc./CrunchyData, does that mean your queries are running over
| internet? What are security/response time implications of that? I
| can already see my InfoSec person going "YOU PUT WHAT ON THE
| INTERNET?"
| gurchik wrote:
| If you're using TLS what is the concern? I'd be more worried
| about Internet data transfer costs than that. Latency might be
| a concern but it's going to be very dependent on use case.
| marksomnian wrote:
| From an infosec perspective, as long as the queries are
| encrypted (with proper TLS verification), that angle is covered
| (though there are other considerations about data sovereignity
| etc.).
|
| In terms of response time, that's something you'd need to
| benchmark for your application - though, given most DBaaSes run
| in the same major cloud providers are your application, it'll
| either be the same region or go cross-region via their private
| backbone, so the latency delta should be manageable. Of course
| if your app is particularly latency-sensitive for the DB that
| won't work.
| tetha wrote:
| > Yes, every second Friday there was mild panic as all the errors
| and alarms went off when Heroku took the database offline and did
| whatever they needed to do, then restarted the app. This whole
| process took about 10 minutes
|
| The heck? Like sure, people may call me "too perfect", but 20
| minutes of outage for a Postgres database or a Redis instance /
| month is entirely not acceptable? Crossing out the less
| professional words there.
|
| We're not particularly ambitious at work at guaranteeing 99.5 SLA
| to our customers, but 20 minutes of outage / month is already
| 99.5%. Availability only goes down if your database just has
| that. We observe that much downtime on a postgres cluster in a
| year.
| renewiltord wrote:
| 20 minutes is 99.95% monthly uptime. That's what Google Cloud
| SQL promises you. 99.5% is 24 h/d * 60 min/h * 30 d/mon * 0.01
| * 0.05 which is a little over 20 min.
|
| At work you're committing to 3 h / month.
| tetha wrote:
| Ah, I mis-remembered / brain farted a 9 in there.
|
| Yet, a promise of 99.95% or 20 minutes of downtime, or having
| 20 minutes of interruptions and downtime / month are still a
| wild difference.
| ojame wrote:
| I build an add-on for Heroku[0], have worked for a company on and
| off that's had all core services on Heroku for over 8 years, and
| I've put a lot of my side projects etc. on Heroku.
|
| My experiences differ depending on the above, I've mostly use
| Render or an alternative for side projects now (just due to
| cost/forgettability). As a daily user of Heroku professionally -
| it's clear Heroku isn't a priority for Salesforce. Heroku has
| struggled to maintain any form of product development and, if
| anything, has become more unreliable over the last year or two.
|
| As an add-on developer, my communication with Heroku has been
| fantastic. You can assume so because it's a direct revenue stream
| and feature expander - but my experience with other platforms
| isn't (iOS has slow/poor communication and docs, Chrome's
| extension support is non-existent and often not backwards
| compatible etc.). It's kind of re-ignited my love affair with
| Heroku, like it was pre-salesforce.
|
| Overall I can't see us moving from Heroku unless costs demand us
| to - it's just too 'easy' to stay. Vendor lock in is real and I'm
| okay admitting that.
|
| 0 - https://elements.heroku.com/addons/eppalock
| qubitly wrote:
| Heroku reminds me how the tools that helped us grow can
| eventually turn into limits we outgrow. In tech staying dynamic
| means keeping the freedom to adapt not just scale.
| mtkd wrote:
| Moved everything Ruby to Fly.io a while back, can recommend
|
| A few annoyances (like CLI auto-updating and rebuilding Go etc.
| when want to deploy a fast fix) but overall very solid
|
| Also Render have been useful for running scripts
|
| The vertical DBaaS are great for early phases but, generalising,
| seem to have pricing models tuned to punish any success (such as
| storage overage fees even if compute is low) -- also sneaky tier
| configs where lower tiers don't offer important features most
| need during prototype/dev phase forcing dedicated instances even
| though no volume hitting
___________________________________________________________________
(page generated 2024-11-03 23:00 UTC)