4 ms·

What stops you from using a managed database from a provider who specializes in it? If Fly builds it, it will create another Goliath who tries to eat everythin

What stops you from using a managed database from a provider who specializes in it? If Fly builds it, it will create another Goliath who tries to eat everything.

minxomat 4y ago
Not really. I see fly competing with Workers for smaller services, and with KV and D1, managed edge DBs are so easy it’s hard to live without them. Very different use case from a traditional managed DB - because it’s either all scaling and running in fly or it isn’t.
Spivak 4y ago
Network posture? I can’t imagine trying to put the public internet in between my app servers and db.
- paulv 4y ago
  Doesn't fly.io have tailscale integration?
  - estsauver 4y ago
    You still need to go over a public network (as opposed to a network inside a data center.)
    - arianvanp 4y ago
      what makes a network private?
      - csunbird 4y ago
        The point the OP wanted to make was: Servers sitting less than 1km to each other tend to have lesser latency between them, compared to servers that could be anywhere on the public internet.
        atonse 4y ago
        Ah because I am interpreting it more at the logical level and about them venturing out into unknown territories (the packets are traversing routers I do not control), rather than just latency. Since others have mentioned that latencies are very low if you locate in the same region. But if you have a zero-trust architecture and everything communicates over wireguard, then technically public or private won't matter right? Not saying public/private IPs don't matter – since almost all the servers would still only have private IPs. In a sense this is more like VPC peering.
        krab 4y ago
        With IPv6, you can have all public IPs (the same as early days of IPv4). However, if you have apps that are tightly coupled and often with strict latency requirements such as Web <-> DB, then it's better to communicate only over private links. You can control latency and you have better reaction time when something breaks down. That is in addition to security concerns. I remember a failure of one transatlantic line that was used for one direction of packets we were sending between EU and US. I spent a night on a phone trying to convince AWS and our other datacenter operator to work around the problem by changing their routing and to push the backbone operator to fix the problem - we didn't have any relationship with the backbone of course. You don't want such disruption to happen in a core part of your app. These disruptions can also be intermittent and "random" and you have no way to fix.
      - zbentley 4y ago
        An RFC 1918 address range and an implementation that does not transmit data over infrastructure not owned by the network operator. I think I know what you're getting at, and if I'm right, this isn't really a subjective or squishy subject.
dehrmann 4y ago
I wonder if we're moving to an unbundling phase of the cloud. The only reason I think we might not be is the selling point is less vendor lock-in, not something managed significantly better. For the most part, the major cloud providers have mature, feature rich product offerings for common use cases like DB, distributed queues, running services, load balancers, etc.
- mrkurt 4y ago
  I hope we're unbundling! RDS is fine, but it doesn't really offer me (as an app dev ... sometimes) much. PlanetScale is a better MySQL: https://planetscale.com/blog/introducing-planetscale-boost https://planetscale.com/blog/introducing-planetscale-boost
  - atonse 4y ago
    Are you guys looking at a partner program where a lot of the managed postgres companies could also provide managed postgres but on top of your infra? (like they do with GCP/AWS/etc)
nine_k 4y ago
> What stops you from using a managed database from a provider who specializes in it? A lack of integrated security and authorization? Should be solvable though. The expense of external traffic? The latency to a DB in a different datacenter?
- cebu 4y ago
  That latency was the deal breaker for me. Kind of defeats having your app running on metal near your customers if they're in Dallas and the DB's in Ohio
ec109685 4y ago
This is an advantage of the big public clouds. Any SaaS you could want is deployed into the same region as your application, so it's essentially co-located and on the same playing field as one of the native public cloud services. With Fly.io (at least today), this isn't as straightforward given your favorite database is likely not deployed there.
- garganzol 4y ago
  Even at the minimal scale, one is going to have quite a few app instances all over the world sooner or later. In such setting, a notion of regional proximity of any kind quickly becomes irrelevant. Higher database round-trip times are fixed by using database stored procedures instead of making multitudes of tiny compound SQL queries.
  - ec109685 4y ago
    Not everything can be represented by a single database query. Often there is mixing involved using multiple sources, which break down the one query for all results pattern, and thus encourage co-locating the database near the tier making the db requests.

What stops you from using a managed database from a provider who specializes in it? If Fly builds it, it will create another Goliath who tries to eat everything.

minxomat 4y ago

Not really. I see fly competing with Workers for smaller services, and with KV and D1, managed edge DBs are so easy it’s hard to live without them. Very different use case from a traditional managed DB - because it’s either all scaling and running in fly or it isn’t.

Spivak 4y ago

Network posture? I can’t imagine trying to put the public internet in between my app servers and db.

paulv 4y ago
Doesn't fly.io have tailscale integration?
- estsauver 4y ago
  You still need to go over a public network (as opposed to a network inside a data center.)
  - arianvanp 4y ago
    what makes a network private?
    - csunbird 4y ago
      The point the OP wanted to make was: Servers sitting less than 1km to each other tend to have lesser latency between them, compared to servers that could be anywhere on the public internet.
      - atonse 4y ago
        Ah because I am interpreting it more at the logical level and about them venturing out into unknown territories (the packets are traversing routers I do not control), rather than just latency. Since others have mentioned that latencies are very low if you locate in the same region. But if you have a zero-trust architecture and everything communicates over wireguard, then technically public or private won't matter right? Not saying public/private IPs don't matter – since almost all the servers would still only have private IPs. In a sense this is more like VPC peering.
        krab 4y ago
        With IPv6, you can have all public IPs (the same as early days of IPv4). However, if you have apps that are tightly coupled and often with strict latency requirements such as Web <-> DB, then it's better to communicate only over private links. You can control latency and you have better reaction time when something breaks down. That is in addition to security concerns. I remember a failure of one transatlantic line that was used for one direction of packets we were sending between EU and US. I spent a night on a phone trying to convince AWS and our other datacenter operator to work around the problem by changing their routing and to push the backbone operator to fix the problem - we didn't have any relationship with the backbone of course. You don't want such disruption to happen in a core part of your app. These disruptions can also be intermittent and "random" and you have no way to fix.
    - zbentley 4y ago
      An RFC 1918 address range and an implementation that does not transmit data over infrastructure not owned by the network operator. I think I know what you're getting at, and if I'm right, this isn't really a subjective or squishy subject.

dehrmann 4y ago

I wonder if we're moving to an unbundling phase of the cloud. The only reason I think we might not be is the selling point is less vendor lock-in, not something managed significantly better. For the most part, the major cloud providers have mature, feature rich product offerings for common use cases like DB, distributed queues, running services, load balancers, etc.

mrkurt 4y ago
I hope we're unbundling! RDS is fine, but it doesn't really offer me (as an app dev ... sometimes) much. PlanetScale is a better MySQL: https://planetscale.com/blog/introducing-planetscale-boost https://planetscale.com/blog/introducing-planetscale-boost
- atonse 4y ago
  Are you guys looking at a partner program where a lot of the managed postgres companies could also provide managed postgres but on top of your infra? (like they do with GCP/AWS/etc)

nine_k 4y ago

> What stops you from using a managed database from a provider who specializes in it? A lack of integrated security and authorization? Should be solvable though. The expense of external traffic? The latency to a DB in a different datacenter?

cebu 4y ago
That latency was the deal breaker for me. Kind of defeats having your app running on metal near your customers if they're in Dallas and the DB's in Ohio

ec109685 4y ago

This is an advantage of the big public clouds. Any SaaS you could want is deployed into the same region as your application, so it's essentially co-located and on the same playing field as one of the native public cloud services. With Fly.io (at least today), this isn't as straightforward given your favorite database is likely not deployed there.

garganzol 4y ago
Even at the minimal scale, one is going to have quite a few app instances all over the world sooner or later. In such setting, a notion of regional proximity of any kind quickly becomes irrelevant. Higher database round-trip times are fixed by using database stored procedures instead of making multitudes of tiny compound SQL queries.
- ec109685 4y ago
  Not everything can be represented by a single database query. Often there is mixing involved using multiple sources, which break down the one query for all results pattern, and thus encourage co-locating the database near the tier making the db requests.