Hacker News Reader

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/

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.

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.

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.

$5/mo will host my webapp and a postgres db? The domain has to happen either way, but when it's an idea I'm playing with, I don't want to pay $5/mo as my projects move pretty slowly due to prioritization of full-time work and family.

But if I'm going to do all that, I might as well just install k8s and deploy with the cli. I've already gone through the learning curve. But I don't want to do that. I don't want other people that might join my project to have to learn k8s for a tiny side project.

You can host both on the same machine.

Get a free Oracle cloud account if on a budget.

lol, apps that are probably way higher scale than your side project have been running with a db on the same host for decades now. And that jump to k8s is a big jump.

no because that doesn't just work and involves additional work. A lot of additional work.

Because it mustn't "just work" and then when the project grows you setup something new. It must "just work" and then scale to continue working for the initial and maybe all phases of the software product.

So e.g. security matters, so you rally don't want to maintain an OS. Sure a OCI image has OS like properties, but by using stateless approaches and carefully select a very thin base image and rebuild it automatically with the newest version of the image you can sidestep most of that work load.

Then you need auto scaling.

Then you need to be able to add services on the fly without problems (e.g. another DB) and they need to have their own scaling.

Then there is networking, as you don't create a super complex applications you don't need anything complex but still something solid.

fly.io does provide all that

So not only can you get something running trivially, you can the incrementally improve on it and even ship it in many cases without needing to re-design your deployment.

Looks tbh. pretty grate for small and mid sized companies (or autonomous project of such size in larger companies).

You need auto scaling to evaluate an idea works?! That's the post I replied to. You need none of that. Have been running apps in a decent scale for decades and an NGINX+postgres in a single VM will take you to many customers before it becomes a bottle neck

> You need auto scaling to evaluate an idea works?!

But you don't "just" show that something works.

Once you did show that you are expected to make a MVP and then a MVP which works in production and then add features etc.

With fly you can just use the same basic setup to go through all of this steps reducing a ton of friction.

I have seen startups fail because of this friction. I also have seen internal proposals being abandoned because of this friction.

What is less friction than an rsync command to deploy ?

I think something happened with a generation of programmers that completely missed the basics and went straight to abstractions.

They know react but not JavaScript, they know k8s but not linux… and they barely know how a computer works. They read a lot of stuff online in blogs but no books. They think moving fast is what some company marketing material says it is.

Look anything you build on top of the basics will be more complex than the basics. It’s worth it to abstract complexity when that arises, when you don’t have it, it’s not necessary and only causes you to move slowly.

Nothing will be faster to iterate than a file on disk if you’re working alone and want to validate an idea. You can literally rsync the folder you’re dev-ing from on a git tag and change a symlink in a single command. That will take you very far with no friction.

What I’ve seen failing is people who find the non existing problems they have more interesting than delivering value

You want firebase?

Okay, fine. That list clearly wasn't sufficiently exhaustive. I want to use the technologies I want to use and not be locked in to certain technologies.

Gotcha. I'm just testing Firebase now so was front mind. I come from a python, sql, setup own VPS on Ubuntu etc kind of background. Cloud functions and nosql is all quite different.

You can get a cheap VPS For ~$3pcm just about anywhere

> 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.

> 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.

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.

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. :)

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).

That's true but Fly's PaaS is perhaps more comparable to DigitalOcean's App Platform (its PaaS). For that, DO include 100GB for free while Fly include 160GB. Beyond that, DO charge $0.10/GB while Fly charge $0.02-$0.12/GB. Cheaper bandwidth for Fly's Machines (more comparable to droplets, as far as I can see) would be neat though.

Yes I agree that Fly's PaaS is more comparable to DO's App Platform and definitely has better price model. However, I don't use DO's App Platform for exactly the same reasons as why I don't use Fly's PaaS. I like services which provide bandwidth for cheap (or even free — Cloudflare Images and Cloudflare R2 comes to mind). Ideally, I want to be charged only for features I use and not for egress which I have no control over. But I know that is not feasible from business point of view (unless you are Cloudflare).

It's OK that we're not a good fit for every user; in fact, you should be suspicious of providers that claim otherwise.

I adore fly.io and hope for 1), but

> We have the same incentives as our investors.

this is wrong, even if today it looks right because the different incentives result in the same concrete things.

You have a company; your goal is to make the company succeed. Investors have a portfolio; their goal is to make the portfolio succeed. Your company succeeding is only one aspect of their portfolio succeeding, and one whose importance and externalities can change drastically for reasons outside your control.

This is all true. But my goal is to make the portfolio succeed.

I've modified the first option

1.We are correct, and manage to build the right thing [developer first cloud]. We'll get to work on this *until we exhaust that market and are forced to grow beyond it"

That's a pretty big market. Heroku got to ~$500mm of revenue while they funneled their most valuable customers to AWS. Keeping those customers around (by, say, giving them lower level primitives) would have 10x'ed that, I bet.

That's a great point. I hope it's big enough for you to not reach its boundaries, because transitioning to a larger market will fundamentally alter the nature of the org. Speaking as customer of organizations that made the transition, and as someone who lived through one on the inside

> 1. We are correct, and manage to build the right thing. We'll get to work on this forever.

Maybe I'm too pessimistic, I apologize if that's the case. But I fail to see how the company could ever work on "the right thing" "forever" since there is outside investment in the company. Do these investor not want a return on their investment at one point? If it's in 1 year or 10, eventually they are gonna want you to either go public, or get bought by another company, both of which makes the mission goal change from "the right thing" to "the profitable thing" at that moment.

But again, maybe I'm just overly pessimistic based on bad experiences with VC funded companies.

Oh when I say "the right thing", it includes actually making money. We're not just building a dev focused cloud because it's fun (it is fun!). We think it's a good business with a very large market. An IPO would be fine!

> An IPO would be fine!

And now instead of venture capitalists you have Wall Street to answer to.

(Taking notes) If we IPO, we lose this message board argument. Got it!

Your snarky response actually proves my point. The responses from the individuals (including the CEO) are meaningless without action. The only action (beyond writing words) the company has undertaken is to take money from venture capitalists.

Have other people invested money in them? If that's the case, sooner or later they don't call the shots, but rather who owns the capital and wants it to grow.

I think if you look at the companies you like, you'll notice that it's not the investors who call the shots. There are a handful of very large, very profitable, developer focused companies that investors love because they remain developer focused.

There are also companies that never figured it out because "developer focused" is not the right business model for them. Those are, I think, the companies that make us all feel burned.

Heroku is one of those companies where "developer focus" is not the right business model. Salesforce has a model, it's working very well, Heroku's doesn't fit.

You should look at the Multi-region PostgreSQL feature they did, not their best work imo.

https://fly.io/docs/getting-started/multi-region-databases/

Hey! I love this feature. What don't you like?

That fly-replay header is legit one of the smartest pieces of infrastructure engineering designs I've encountered in years.

I was thinking about adopting this feature in the near future. Would love to know your reservations against it.

> 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.

> 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.

> "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".

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.

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.

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.

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.

It's the ecosystem things like Upstash Redis Database, edgeDB

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.