Hacker News new | past | comments | ask | show | jobs | submit login

I believe that being cloud independent is a bit of a pipe dream for startups.

Sure, Kubernetes gives you some independence but then you still depend on a lot of vendor specific services like S3, RDS, SES, SQS, etc.




You don't have to use those services, and there are some abstraction you can do to make things portable. For instance, each platform may have its own block storage, but you can have different storage provisioner configurations for each platform so that you can move your application smoothly between them.


> You don't have to use those services

Sure, you don't have to but that is the whole point of Clouds.

Otherwise, using regular old-school hosting providers is much, much cheaper.

> and there are some abstraction you can do to make things portable.

I would disagree with this point.

I'm sure that there are some APIs that try to abstract out the Cloud service used but in the end you are tied to the pricing and technical specificities of each service.

If I want to use a file storage service, I need to know how to authenticate to it, handle the access control, host static sites with it, handle CDN integration, configure access logging, etc.

All of this is possible in multiple cloud services but will be different for each provider. That is sufficient enough for it to be a leaky abstraction.


There's plenty of value in just the block storage and compute at the large cloud providers, and these are not difficult to abstract. I know because I've done it. Yes, some of the abstractions are a bit leaky, but all those leaks are variables in our helm chart. My application code is written so that it doesn't care where it's running, nor does it need to know.

> in the end you are tied to the pricing and technical specificities of each service.

That's one of the primary driving factors behind our decision to design our application to be portable.


Ah, by cloud independence i mean we can easily switch where the machines with gpus come up, not the whole stack. We might give up on this flexibility but so far it seems like it will save us a ton of cash.


If you're simply using EC2 hardware I agree but then you might as well go for a lower-level hosting provider which will be much cheaper.

The point of Cloud Services is to provide all these additional services.

If you don't use those services then the flexibility is relatively trivial to achieve.


I don't use cloud providers because they have their branded value-add services. I use them because they're reliable, automated, and they have APIs. I can't point terraform at whatever random IPMI a traditional hosting provider gives me. The last time I spun up a new dedicated instance at a traditional hosting provider, it wasn't an API call. It was a few emails, an invoice, and a week wait.


Gotcha. That’s exactly the problem I am trying to solve, using just the ec2 style hardware, and being able to spin up on smaller clouds like coreweave to take advantage of availability and prices.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: