5 ms·

Sadly, we have all seen these promises, "X makes Y much easier" but you cannot make complex things easy without removing lots of functionality. Kubernetes for

Sadly, we have all seen these promises, "X makes Y much easier" but you cannot make complex things easy without removing lots of functionality. Kubernetes for the basics is actually pretty easy despite what people say, I got a fairly simple cluster running with little pain but...it doesn't take long before you want multiple clusters, or vlan peering, or customising the DNS or.... and that is when it becomes complex. What will fly.io do? Probably what everyone else does, starts simple, becomes popular and then caves in to the deluge of feature requests until they end up with an Azure/AWS/GCP clone. If it stays simple, lots of people will say that you will outgrow it quickly and need something else, if you increase functionality, you lose your USP of making infrastructure easy. I think perhaps the abstractions are the problem, if you are abstracting at the same level as everyone else e.g. docker images, orchestration etc. then I don't understand how it can ever work differently. To make my point, the very first comment below (above?) is about container format, a really fundamental thing that noobs are not likely to know about, they will just immediately have some kind of error.

ignoramous 4y ago
> it doesn't take long before you want multiple clusters, or vlan peering, or customising the DNS Then, Fly is not for such an application. Just not yet. I mean, we wouldn't buy a snowboard and complain we couldn't go skiing. Different tools. The point really is, for a similar thing that which Fly is capable of (and other NewCloud services to an extent like railway.app, render.com, replit.com, convex.dev, workers.dev, deno.com, pages.dev, vercel.com, temporal.io etc), you're better off NOT using AWS/GCP/Azure. I certainly have found it to be true for whatever toy apps I build.
diceduckmonk 4y ago
> "X makes Y much easier" but you cannot make complex things easy without removing lots of functionality. The question is whether customers need or want that "functionality".
chrisabrams 4y ago
> What will fly.io do? Probably what everyone else does, starts simple, becomes popular and then caves No, mrkurt will not cave, I can guarantee you that. Fly will be a platform that says no to feature requests that don't make sense for their customer base. I have no affiliation with Fly, other than I've used it on and off since the beginning of the platform's existence. They're a veteran team that knows how to build platforms. I definitely trust them to go in the right direction with their roadmap, and all my new projects go on Fly.
- pier25 4y ago
  > No, mrkurt will not cave, I can guarantee you that. I concur. Fly is not your typical startup with dreams of becoming the next big corp monster. They are just a bunch of talented people with a vision having fun making cool stuff.
  - capableweb 4y ago
    Not to break your rose-tinted glasses, I think fly.io is pretty cool too. But it's a for-profit company with outside investment, coming from investors who expect a return on their investment, one way or another, and they likely have some influence on how the company will act. Same has been said for every company who taken outside investment ever. "But no, Heroku/Figma/GitHub/X are different, they really do care about their users and would never sell/go public/Y", and then a couple of years later we end up in the same position. It might not even be up to the "bunch of talented people" in the end, what they have to do to survive or to grow. But grow they have to, unless investors are fine with getting their ROI over 10-50 years rather than 1-10 years. A growing usually comes with some pain.
    - mrkurt 4y ago
      This is a 10-50 year company. You're not wrong, though, we are either building something big or we're building something that will fail. Our bet is that a developer first public cloud is important and needs to exist. Which means, there will be one of three outcomes: 1. We are correct, and manage to build the right thing. We'll get to work on this forever. 2. We are correct, but not the right group to build it. We fail. 3. We are incorrect, and the world doesn't need a public cloud for devs. We fail, and I become a carpenter. We have the same incentives as our investors. That doesn't mean it'll work. It does mean that we all believe that we're building a product for developers. We're pretty good at surviving, so far. And there are early signs that we're good at growing. There's reason to be hopeful. :)
      - KrishnaShripad 4y ago
        Only issue stopping me from using Fly: bandwidth costs. I am spoiled by DigitalOcean's 1TB tier per droplet created (along with bandwidth pooling if you have more droplets).
paulgb 4y ago
> Sadly, we have all seen these promises, "X makes Y much easier" but you cannot make complex things easy without removing lots of functionality. There's certainly a limit, but it makes me so sad that developers see the current state of orchestration and say “welp, it's a complex problem, guess this is as good as it gets” (not you specifically, but it's a common sentiment on HN.) Sure, there will always be use cases that require getting down to a lower level, but there's definitely space for reducing complexity for common use cases.
ngrilly 4y ago
It sounds like you’re commenting in general terms without having looked at what Fly.io is actually doing. Yes, choosing the right abstractions is the problem, and what makes Fly.io really interesting is that they chose different ones. It’s really well explained in their docs and blog posts.
- ipaddr 4y ago
  Having to read through docs and blog posts to understand what unique abstractions doesn't help those asking. I've read through docs, blog posts, etc. It's for developers who don't want to setup and maintain an environment. Other providers offer this. You end up paying far more than a five dollar droplet in most cases and a lot more than the free Oracle tier offers but much less compared to big cloud like AWS. They offer a free tier and a community helping onboarding. The goal is ecosystem lock-in and they provide enough to win over a certain group in the middle. The fear is the freebies given today will be paid for by the lock-in effects tomorrow.
  - tptacek 4y ago
    We host Docker containers. As you aptly observe: you can boot up a Docker container just about anywhere. I'm not seeing the lock-in.
    - ipaddr 4y ago
      It's the ecosystem things like Upstash Redis Database, edgeDB
      - tptacek 4y ago
        That's Redis, Redis, Postgres, and a database we don't do anything with, for those following along with this. Unless "Upstash Redis Database" is one thing? In which case, that's "Redis, and a database we don't do anything with". I'm still not seeing the lock-in. Whatever EdgeDB is: we're happy if you run it here! If it has like, a company running it as a service, we're very happy to talk to them, too. But we're going out of our way to avoid weird custom services, like Amazon's 19 different messaging services, that have platform-specific APIs. Our APIs are Docker, IPv6, DNS, Redis, and Postgres. Our Postgres is literally just an app running on Fly.io; you can run it yourself if you like --- or, I guess, run it somewhere else.
mrkurt 4y ago
You definitely can't make complex things simple just by removing features. What we did, instead, was built low level primitives, then built opinionated PaaS-like magic on top of those. If you're running a Phoenix app, `fly launch` gets you going, then `fly deploy` gets you updated. If you want to skip the PaaS layer and do something more intense, you can use our Machines API (or use Terraform to power it) and run basically anything you want: https://fly.io/docs/reference/machines/ https://fly.io/docs/reference/machines/ We are very, very different than k8s. In some ways, we're lower level with more powerful primitives. We probably won't build an AWS clone. I don't think devs want that. I also don't think devs want a constrained PaaS that only works for specific kinds of apps. I think want devs want is an easy way to deploy a boring apps right now, and underlying infrastructure they can use to solve bigger problems over time.
- knicholes 4y ago
  I'm a dev. That's what I want. I want something publicly visible that I can get running in the first sprint so I can show everyone what my idea is looking like as it progresses. I want setting up the DB and certificates to be easy. I want a static IP to point my domain to. I want it all to just work if I have the source code and I tell it to deploy. I want secrets to be included so I don't have to stand up Vault or something. I don't want to set up my own Jenkins. I don't want to deal with resizing volumes in k8s. I don't want to dick with networking rules/configurations that allow my frontend to talk to my backend and my backend to my DB. I also don't want to set up my own log aggregator, grafana, and prometheus/alert manager, but for a quick "show everyone your app", I don't need those. I can add that harder crap later when the app shows promise and I actually need to debug performance.
  - aprdm 4y ago
    So you want a 5 dollars digital ocean, a DNS domain that costs you 10 bucks a year, and a docker-compose up command running nginx/whatever behind it. You can scp the tarball of your docker and docker-compose down/up If you want even easier, just put your app on docker and run nginx natively via systemd or wahtever.
tootie 4y ago
Yeah it's neat but idk who the target market for this is. I can run a custom-designed site with all sorts of features using WordPress.com or Shopify or Hubspot. Once I need a real platform and backend services, you'll need a team that can spin up Docker images in AWS or the like and the full gamut of DIY platform tools. Platforms like fly.io appeal to semi-mature orgs but they will either die or outgrow it pretty quickly.

ignoramous 4y ago

> it doesn't take long before you want multiple clusters, or vlan peering, or customising the DNS Then, Fly is not for such an application. Just not yet. I mean, we wouldn't buy a snowboard and complain we couldn't go skiing. Different tools. The point really is, for a similar thing that which Fly is capable of (and other NewCloud services to an extent like railway.app, render.com, replit.com, convex.dev, workers.dev, deno.com, pages.dev, vercel.com, temporal.io etc), you're better off NOT using AWS/GCP/Azure. I certainly have found it to be true for whatever toy apps I build.

diceduckmonk 4y ago

> "X makes Y much easier" but you cannot make complex things easy without removing lots of functionality. The question is whether customers need or want that "functionality".

chrisabrams 4y ago

> What will fly.io do? Probably what everyone else does, starts simple, becomes popular and then caves No, mrkurt will not cave, I can guarantee you that. Fly will be a platform that says no to feature requests that don't make sense for their customer base. I have no affiliation with Fly, other than I've used it on and off since the beginning of the platform's existence. They're a veteran team that knows how to build platforms. I definitely trust them to go in the right direction with their roadmap, and all my new projects go on Fly.

pier25 4y ago
> No, mrkurt will not cave, I can guarantee you that. I concur. Fly is not your typical startup with dreams of becoming the next big corp monster. They are just a bunch of talented people with a vision having fun making cool stuff.
- capableweb 4y ago
  Not to break your rose-tinted glasses, I think fly.io is pretty cool too. But it's a for-profit company with outside investment, coming from investors who expect a return on their investment, one way or another, and they likely have some influence on how the company will act. Same has been said for every company who taken outside investment ever. "But no, Heroku/Figma/GitHub/X are different, they really do care about their users and would never sell/go public/Y", and then a couple of years later we end up in the same position. It might not even be up to the "bunch of talented people" in the end, what they have to do to survive or to grow. But grow they have to, unless investors are fine with getting their ROI over 10-50 years rather than 1-10 years. A growing usually comes with some pain.
  - mrkurt 4y ago
    This is a 10-50 year company. You're not wrong, though, we are either building something big or we're building something that will fail. Our bet is that a developer first public cloud is important and needs to exist. Which means, there will be one of three outcomes: 1. We are correct, and manage to build the right thing. We'll get to work on this forever. 2. We are correct, but not the right group to build it. We fail. 3. We are incorrect, and the world doesn't need a public cloud for devs. We fail, and I become a carpenter. We have the same incentives as our investors. That doesn't mean it'll work. It does mean that we all believe that we're building a product for developers. We're pretty good at surviving, so far. And there are early signs that we're good at growing. There's reason to be hopeful. :)
    - KrishnaShripad 4y ago
      Only issue stopping me from using Fly: bandwidth costs. I am spoiled by DigitalOcean's 1TB tier per droplet created (along with bandwidth pooling if you have more droplets).

paulgb 4y ago

> Sadly, we have all seen these promises, "X makes Y much easier" but you cannot make complex things easy without removing lots of functionality. There's certainly a limit, but it makes me so sad that developers see the current state of orchestration and say “welp, it's a complex problem, guess this is as good as it gets” (not you specifically, but it's a common sentiment on HN.) Sure, there will always be use cases that require getting down to a lower level, but there's definitely space for reducing complexity for common use cases.

ngrilly 4y ago

It sounds like you’re commenting in general terms without having looked at what Fly.io is actually doing. Yes, choosing the right abstractions is the problem, and what makes Fly.io really interesting is that they chose different ones. It’s really well explained in their docs and blog posts.

ipaddr 4y ago
Having to read through docs and blog posts to understand what unique abstractions doesn't help those asking. I've read through docs, blog posts, etc. It's for developers who don't want to setup and maintain an environment. Other providers offer this. You end up paying far more than a five dollar droplet in most cases and a lot more than the free Oracle tier offers but much less compared to big cloud like AWS. They offer a free tier and a community helping onboarding. The goal is ecosystem lock-in and they provide enough to win over a certain group in the middle. The fear is the freebies given today will be paid for by the lock-in effects tomorrow.
- tptacek 4y ago
  We host Docker containers. As you aptly observe: you can boot up a Docker container just about anywhere. I'm not seeing the lock-in.
  - ipaddr 4y ago
    It's the ecosystem things like Upstash Redis Database, edgeDB
    - tptacek 4y ago
      That's Redis, Redis, Postgres, and a database we don't do anything with, for those following along with this. Unless "Upstash Redis Database" is one thing? In which case, that's "Redis, and a database we don't do anything with". I'm still not seeing the lock-in. Whatever EdgeDB is: we're happy if you run it here! If it has like, a company running it as a service, we're very happy to talk to them, too. But we're going out of our way to avoid weird custom services, like Amazon's 19 different messaging services, that have platform-specific APIs. Our APIs are Docker, IPv6, DNS, Redis, and Postgres. Our Postgres is literally just an app running on Fly.io; you can run it yourself if you like --- or, I guess, run it somewhere else.

mrkurt 4y ago

You definitely can't make complex things simple just by removing features. What we did, instead, was built low level primitives, then built opinionated PaaS-like magic on top of those. If you're running a Phoenix app, `fly launch` gets you going, then `fly deploy` gets you updated. If you want to skip the PaaS layer and do something more intense, you can use our Machines API (or use Terraform to power it) and run basically anything you want: https://fly.io/docs/reference/machines/ https://fly.io/docs/reference/machines/ We are very, very different than k8s. In some ways, we're lower level with more powerful primitives. We probably won't build an AWS clone. I don't think devs want that. I also don't think devs want a constrained PaaS that only works for specific kinds of apps. I think want devs want is an easy way to deploy a boring apps right now, and underlying infrastructure they can use to solve bigger problems over time.

knicholes 4y ago
I'm a dev. That's what I want. I want something publicly visible that I can get running in the first sprint so I can show everyone what my idea is looking like as it progresses. I want setting up the DB and certificates to be easy. I want a static IP to point my domain to. I want it all to just work if I have the source code and I tell it to deploy. I want secrets to be included so I don't have to stand up Vault or something. I don't want to set up my own Jenkins. I don't want to deal with resizing volumes in k8s. I don't want to dick with networking rules/configurations that allow my frontend to talk to my backend and my backend to my DB. I also don't want to set up my own log aggregator, grafana, and prometheus/alert manager, but for a quick "show everyone your app", I don't need those. I can add that harder crap later when the app shows promise and I actually need to debug performance.
- aprdm 4y ago
  So you want a 5 dollars digital ocean, a DNS domain that costs you 10 bucks a year, and a docker-compose up command running nginx/whatever behind it. You can scp the tarball of your docker and docker-compose down/up If you want even easier, just put your app on docker and run nginx natively via systemd or wahtever.

tootie 4y ago

Yeah it's neat but idk who the target market for this is. I can run a custom-designed site with all sorts of features using WordPress.com or Shopify or Hubspot. Once I need a real platform and backend services, you'll need a team that can spin up Docker images in AWS or the like and the full gamut of DIY platform tools. Platforms like fly.io appeal to semi-mature orgs but they will either die or outgrow it pretty quickly.