Most active commenters

    ←back to thread

    Fly.io: The reclaimer of Heroku's magic

    (christine.website)
    528 points sealeck | 13 comments | 15 May 22 19:56 UTC | HN request time: 0.001s | source | bottom
    Show context
    anon3949494 ◴[15 May 22 21:10 UTC] No.31391163[source]▶
    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. File persistence is fine but not typically necessary. S3 works just fine.

    It's easy to forget that most companies are a handful of people or just solo devs. At the same time, most money comes from the enterprise, so products that reach sufficient traction tend to shift their focus to serving the needs of these larger clients.

    I'm really glad Heroku froze when it did. Markets always demand growth at all costs, and I find it incredibly refreshing that Heroku ended up staying in its lane. IMO it was and remains the best PaaS for indie devs and small teams.

    replies(10): >>31391221 #>>31391236 #>>31391460 #>>31391578 #>>31391671 #>>31391717 #>>31391956 #>>31392086 #>>31392734 #>>31393610 #
    closeparen ◴[15 May 22 22:00 UTC] No.31391578[source]▶
    Hot take: if people spent half the energy doing multi-region that they today spend screwing around with Kubernetes, they’d be a hell of a lot more reliable.
    replies(1): >>31391662 #
    jpgvm ◴[15 May 22 22:14 UTC] No.31391662[source]▶
    I think people misconstrue the benefits of k8s to be related to reliability or similar. Ultimately it's about the API and the consistency and productivity it offers.

    For larger teams having a well defined API that delineates applications from infrastructure that doesn't require extreme specialist knowledge (it still requires some specialist knowledge but vastly less than direct manipulation of resources via something like Terraform) is a massive productivity boost.

    Of course none of that matters if you have 4 developers like OP but for folks like myself that routinely end up at places with 300+ engineers then it's a huge deal.

    replies(1): >>31391901 #
    1. Trasmatta ◴[15 May 22 22:45 UTC] No.31391901[source]▶
    > I think people misconstrue the benefits of k8s to be related to reliability or similar. Ultimately it's about the API and the consistency and productivity it offers

    I think this is the first time I've heard somebody say one of the benefits of kubernetes was productivity.

    replies(2): >>31392050 #>>31393831 #
    2. vlunkr ◴[15 May 22 23:07 UTC] No.31392050[source]▶
    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.
    replies(4): >>31392071 #>>31392174 #>>31392509 #>>31393108 #
    3. otterley ◴[15 May 22 23:10 UTC] No.31392071[source]▶
    The same is true of ECS, but with a much simpler API, much tighter integration with load balancers, a no-charge control plane, and not having to upgrade every cluster every 3-6 months.
    replies(1): >>31393161 #
    4. Trasmatta ◴[15 May 22 23:25 UTC] No.31392174[source]▶
    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.

    replies(2): >>31392504 #>>31394246 #
    5. ramraj07 ◴[16 May 22 00:17 UTC] No.31392504{3}[source]▶
    Basically depends on expertise. The parent commenter probably comes from a team of good well paid ops engineers who understand and set up k8s well. In any other org it’s the show you describe.
    6. ◴[16 May 22 00:18 UTC] No.31392509[source]▶
    7. aledalgrande ◴[16 May 22 02:08 UTC] No.31393108[source]▶
    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 agent is going to pick it up automatically, I can have services communicating via private dns etc. etc.

    I am not an ops guy.

    replies(1): >>31394592 #
    8. snoman ◴[16 May 22 02:21 UTC] No.31393161{3}[source]▶
    I’ve had 2 services running flawlessly in ecs for over a year (with load balancing) without having to touch them. Took me all of 15m to set them up. It’s quite good.
    replies(1): >>31393336 #
    9. danenania ◴[16 May 22 03:04 UTC] No.31393336{4}[source]▶
    Fargate is really nice too—it takes the benefits of ECS even further to the point that the underlying EC2 instances are abstracted away almost completely.

    Fargate with auto-scaling plus Aurora for the DB is pretty great in terms of a nearly zero-maintenance setup that can handle just about any type of service up to massive scale.

    Unfortunately getting all the networking and IAM stuff right is still pretty thorny if you want to do things the correct way and not just run it all in public subnets. And the baseline costs are significantly higher than a paas.

    replies(1): >>31393366 #
    10. ◴[16 May 22 03:11 UTC] No.31393366{5}[source]▶
    11. tetha ◴[16 May 22 05:11 UTC] No.31393831[source]▶
    We're running Nomad, but that's just a detail. The great thing for both development teams and the ops team is that the container orchestration starts working as a contract between the teams. This allows building more of a framework in which we can provide some initial starting point for standard tasks, like connections to infrastructure components, migrations in various languages, automated deployments, rollbacks and so on for teams out of the box. With this, product teams can go from an idea to deployed and running code very quickly and confidently.
    12. zoltar ◴[16 May 22 06:58 UTC] No.31394246{3}[source]▶
    It's like what Hedberg said about rice: k8s is great if you're really hungry and what to host two thousand of something.
    13. miamibougie ◴[16 May 22 08:10 UTC] No.31394592{3}[source]▶
    +1 this is what I do as well. If you have any semblance of uniformity in your project folder structure, you can even automate the build/deploy process with a simple shell script/bash function.

    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