241–250 of 320 posts
Earlier quoted context omitted.
Vercel and Github pages would be better IMO if it's a static site.
If it’s a static site then just dump it in an s3 bucket and be on your way.
> I wouldn't straight out recommend fly.io. See, part of Heroku's value proposition was their excellent support. I had asked fly.io to delete my account since there wasn't a provision to delete it from their interface and they never bothered to reply and put me in some kind of shadow ban from re-registering with my email. I mean if this is how you're going to treat your customers, then good luck! I'm yet to try out r…
Earlier quoted context omitted.
Really? I think it's a pretty obvious benefit. If you bundle something into a container, you can probably run it in kubernetes. This uniformity makes it incredibly easy to deploy and scale new applications.
I think what I've heard is the kubernetes end result is very often a massively overcomplicated infrastructure that nobody understands, that's a constant source of headaches and lost time due to leaky abstractions. Disclaimer: I've never actually used it myself. That's mostly just what I've read and heard from people who use kubernetes.
I could relate to the comment on Redis. The only things I can see missing are automated Redis hosting by the platform. There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it. If and when you get big eno…
I could relate to the comment on Redis. The only things I can see missing are automated Redis hosting by the platform. There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it. If and when you get big eno…
Perhaps just using an embedded DB would be better in your case? Something like Berkeley DB. Alternatively, just Dockerize it, although I assume it's too much upkeep. While not as "Redis-y", there are some decent KV-ish managed databases out there: - Firestore - Cloudflare Workers KV - DynamoDB - Bigtable
At one point (a very long time ago now) it was declared that Dogwood was the future and as a result Go would be the language of choice at Heroku and Erlang would be no more. Trouble is that Erlang ran all the important Cedar code (it might still today) and the Erlang engineers didn't particularly like the news that Erlang code was essentially deprecated so they left and nobody knew how to maintain the stack. This def…
Earlier quoted context omitted.
Have seen similar transitions in different companies, and while I can't say anything about Heroku, it is often not the target technology or architecture that matters. For instance I've seen PHP -> nodejs transition while moving to micrservices, and while the ideas made sense on paper: - It didn't come from the engineers at large. Most weren't phased by the prospect and the main engine for the change was the top archi…
This is pretty common in corporates too. Shiny new project gets all the attention, funding and management focus. The poor guys left to deal with the day to day crap get screwed over then leave. If they leave too soon its an emergency, if they stay too long they get laid off.
Render and others are interesting but K8S is still fundamentally better considering all the DX progress there making it pretty easy to get a container running in a cluster.
Earlier quoted context omitted.
Really? I think it's a pretty obvious benefit. If you bundle something into a container, you can probably run it in kubernetes. This uniformity makes it incredibly easy to deploy and scale new applications.
Yeah if you study over it instead of copy pasting stuff from the internet, I find k8s the best thing for my small projects. I only have to setup a simple dockerfile and helm chart and I can run a new service in my cluster on DO, for which they offer free control plane, and not be billed for a completely new app and have to setup all my deps and env vars in a clunky UI. I can setup scaling, ingress easily, the Datadog…
Of course, this quickly stops working once your small projects grow to have multiple collaborators, a staging environment, etc. - but at that point you're running a proper business
After all the chatter this week, I've come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called "features" are exactly what we don't want or need. 1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. 2.…
We’re not “froze”. The last week has been exhausting fud.