Exiting cloud being useful seems to be a very narrow use case.
For one, you have to be at a large enough scale where buying and hosting your own infra is feasible and cheaper.
Second, you have to give up the ability to almost instantly scale up or provision hardware in response to traffic or other events. (which is very common at scale)
Maybe his use case happens to be that very narrow case, but this isn’t something I would take as general advice.
Your last paragraph is why we’ve heavily used the cloud here in rural Canada for years.
Monitoring data is much easier to push into the cloud and read from there than it is hope for a reliable connection to a farm or rural plant.
Self-hosted services need to be cloud hosted for uptime and because it was getting ever harder to get a routed IPv4 address from any provider. IPv6 is nice to finally have, but Starlink is the only provider at all supporting it and it’s only been a few months at that. Their prefixes change constantly too, come on guys get your shit together.
Even basic remote access systems require a VPS or VPN cloud service as you always need both ends to punch out through layers of CGNAT. Now we can finally have one end available through IPv6 but the remote user is often trying to use a IPv4 CGNAT network to connect… So you still need something in the cloud to punch holes.
Can’t believe it’s been over 20 years for the IPv6 rollout
I’m still trying to figure out how to use Docker with an unstable prefix (hey Docker, this is as much your problem as the ISPs, honestly) as any of the v6NAT solutions I’ve found that enable the same full containerization available on IPv4 all require you feed the Docker daemon a fixed prefix on startup. Frustrating.
I’m also tired of reading posts about v6NAT being irrelevant because half of the point of containers is the interchangeability, Docker containers aren’t supposed to be routable unless you intentionally put them on the host network! Docker just needs to work the same on v4 and v6!
Tor as a hole puncher is an intriguing idea but I don’t think I would use it for something customer facing… Too many moving parts. We like to use Wireguard and a tiny cloud VPS instance when someone needs to punch into an unreliable network around here.
Exiting cloud being useful seems to be a very narrow use case.
For one, you have to be at a large enough scale where buying and hosting your own infra is feasible and cheaper.
Second, you have to give up the ability to almost instantly scale up or provision hardware in response to traffic or other events. (which is very common at scale)
Maybe his use case happens to be that very narrow case, but this isn’t something I would take as general advice.
[This comment has been deleted by an automated system]
Your last paragraph is why we’ve heavily used the cloud here in rural Canada for years.
Monitoring data is much easier to push into the cloud and read from there than it is hope for a reliable connection to a farm or rural plant.
Self-hosted services need to be cloud hosted for uptime and because it was getting ever harder to get a routed IPv4 address from any provider. IPv6 is nice to finally have, but Starlink is the only provider at all supporting it and it’s only been a few months at that. Their prefixes change constantly too, come on guys get your shit together.
Even basic remote access systems require a VPS or VPN cloud service as you always need both ends to punch out through layers of CGNAT. Now we can finally have one end available through IPv6 but the remote user is often trying to use a IPv4 CGNAT network to connect… So you still need something in the cloud to punch holes.
Can’t believe it’s been over 20 years for the IPv6 rollout
[This comment has been deleted by an automated system]
I’m still trying to figure out how to use Docker with an unstable prefix (hey Docker, this is as much your problem as the ISPs, honestly) as any of the v6NAT solutions I’ve found that enable the same full containerization available on IPv4 all require you feed the Docker daemon a fixed prefix on startup. Frustrating.
I’m also tired of reading posts about v6NAT being irrelevant because half of the point of containers is the interchangeability, Docker containers aren’t supposed to be routable unless you intentionally put them on the host network! Docker just needs to work the same on v4 and v6!
Tor as a hole puncher is an intriguing idea but I don’t think I would use it for something customer facing… Too many moving parts. We like to use Wireguard and a tiny cloud VPS instance when someone needs to punch into an unreliable network around here.
[This comment has been deleted by an automated system]
DHH is a contrarian. Any benefits of the cloud he might get are overridden by the fact that he needs to be different (and blog about it).
See his stances on Typescript, workplace inclusion, TDD, etc.