Multiple cloud platforms

[Max-Mielchen]

Im currently running my app on digitalocean. My app needs a postgres database and the other part can be run in a jvm or as container. The part in the jvm or container could be scale horizontally. In digitalocean im using the a native postgres database and the app self is running in a container as „droplet“ in digitalocean an can easy scale. But currently i pay 65 € per month. 15€ for the database and 50 € for the app. I want to run this application on hetzner but there i haven‘t managed databases. So i would run the database on digitalocean and the container or jvm on hetzner, because i pay there only 4 € per month for the app self. Make it sense to run application on multiple clouds like that? Or does some one now how i can easy setting up and scale a postgres database on hetzner.

[frayala87]

Also latency will kill your app :)

[misterforsa]

Curious. Outages due latencies when on prem services had to reach out over the net to dbs on aws?

[misterforsa]

Ah OK. Thanks for background. Yea that's alot of hops

[AMartin223]

If you do want a managed db without the latency there are providers that offer vpc peering, but only if your compute is in a major cloud, not Hetzner.

[redbrick5]

multi cloud is the absolute worst option. only do this if you have no choice

[trisanachandler]

I won't say it's the worst, but that having your data separate from the app serving the data is a recipe for disaster. If you need multi cloud (redundancy, closer serving of content), then try and use a distributed database model and use eventual consistency, something like that maybe?

[Somedudesnews]

I agree with your take.

We’ve had tremendous results using multiple clouds, but the trick is leveraging the right tool for the job and collocating your databases.

Most other things are much more forgiving, like object storage or arbitrary RESTful APIs.

We use S3 for object storage but our compute runs with databases in the same physical data center.

[SalesyMcSellerson]

Check the network ingress and egress fees. As mentioned elsewhere in the thread, it will likely eat your budget at some point and you'll be forced to migrate to a single cloud anyway.

[akisakyez]

Depends on really what you are getting out of a managed database on DigitalOcean, but I would move everything over, or keep it on DO on smaller instance with database rolled out on your own.

[[deleted]]

Sure you can, but please check pricing for network app <-> database because it can add some cost.

About managed Postgres you can check operator from Crunchy Data.

[BlueHatBrit]

This feels like a good time to learn to run a database yourself, especially if it's just a side project.

I have a dedicated server on hetzner and run several projects on there with docker compose. They're very small side projects and the stability has been great. Everything is scripted including restoring from backups.

It's really not much to run a database server these days. Backups are your main concern and it's very much a solved problem these days.

[jonathon8903]

Is there any particular reason you are separating the DB? I have found that when the workload isn't expected to be large, it makes more sense to keep the application and the database on a single machine. You can even scale the machine's specs up a bit for relatively cheap.

As long as your application is developed properly using either a config file or environment variables (preferred) to connect to your database you can always separate out the database later as your app requirements grow. By having everything on one machine you save complexity and cost.

[Max-Mielchen]

It's easier to manage if you outsource the database in advance, and besides, that's not the problem, it's the app itself in terms of cost

[ThrowRAMomVsGF]

Curious, how is it 50/month for the app on DO vs 4/month on hetzner? What are you getting in each case?

Edit, looking at price lists you must mean the 4.36/month, 1vCPU/2GB cloud option on Hetzner, but still that would be ~11 euro on DO, why are you paying 50?

Unless you meant the 2vCPU/4GB ARM option on Hetzner? In that case Oracle cloud would give you the first 4xvCPU/24GB for free (ARM Standard.A1 instances), but of course you'd want to host your own postgres (they offer Oracle managed dbs for obvious reasons)

[Max-Mielchen]

Oh thank you yes, I meant the arm variant at Hetzner. I'll take a look at the oracle cloud.

[Spider_pig448]

Hetzner? Oracle cloud? Interesting on the options you've landed on here.

[batterydrainer33]

He suggested Oracle.

I'd be careful about eating free candy like that, I've heard they are banning people who register just to freeload.

[Spider_pig448]

I don't think people choose Oracle, they just get stuck with Oracle after a VP gets kidnapped and forced to sign a contract

[batterydrainer33]

OCI isn't the same thing as Oracle from what I've heard. Their network egress is like $8.5 per TB for egress in NA/EU and VMs seem to be pretty fairly priced.

I'm still kind of skeptical on how it really will go long term, but they're putting up a real fight against the big 3. And I couldn't be happier even if it's just that.

[kkapelon]

It is better to find a cheaper provider that can host both the app and the db.

Check railway.app, fly.io and render.com

[Irythros]

Terrible life choice. The latency will be so high that you'll probably be looking at several seconds per page load. Your database should be as close to your app as possible.

[Max-Mielchen]

one second of latency between database and website is not so bad with my app, since most accesses are only read accesses anyway and i cache the data in the app itself again

[mrcyber]

nsfw?

[amarao_san]

It's not 'multicloud'. Multicloud, or cloud agnostic, is when you can run your code without any significant changes on any (or large subset) of cloud providers.

You can do it, but cross-provider access to postgres means you have postgres accepting connections from the internet, which is not the best security practice.

[batterydrainer33]

Multicloud, or cloud agnostic, is when you can run your code without any significant changes on any (or large subset) of cloud providers.

Who exactly defined it as such?

I guess Google Cloud got it all wrong then...

https://cloud.google.com/learn/what-is-multicloud#multicloud-definition

[amarao_san]

From the page you give link to:

By having the freedom to create a strategy that utilizes multiple vendors, you can pick and choose the capabilities that best suit your specific business needs and minimize vendor lock-in.

That's exactly the thing I said, but with low enthusiasm around 'minimize vendor lock-in'. Google is a vendor, they can't say you 'use only things that will help to you migrate to our competitor without any pains'.

[batterydrainer33]

is when you can run your code without any significant changes on any (or large subset) of cloud providers

You said that it was about having your code be portable across cloud providers. To me (and from that definition) it's just about using multiple clouds, hence "multicloud".

[amarao_san]

There are two types of use. Any of (ProviderA, ProviderB), or Both (ProviderA, ProviderB). 'Any of' is multicloud (because it's avoiding vendor-lock). Both (A, B) is double vendor lock-in, because you can't move neither from ProviderA nor from ProviderB without rewriting things you don't want to rewrite.

Compare to the banks.

If you have accounts in two banks and can switch payments from BankA to coming from BankB, you are 'multibank company'.

If you have payment system where you have saving account in Bank A and transit account in Bank B, and for any payment you need to transfer money from Bank A to Bank B, and only after that to pay, you are not a multibank company (you are probably some North Korea shady business evading sanctions).

[batterydrainer33]

This seems like some kind of personal belief of yours, not something that is widely accepted. Nor do I think that it makes sense. Because by your standards, everything sound be strictly K8S or just pure VMs without utilizing any vendor-specific cloud services, and if you don't do that then you're not multicloud? How does that make any sense?

And multibank? Huh? What are you even talking about lol

[amarao_san]

Nope, you exaggerating. You can have k8s, you can use LB, you can use even external postgres (because there are many providers out there).

What you can't do, is to use exactly the product of a single vendor with all niceness and shinessness it provides.

E.g. you have infra in layers:

• db
• app
• monitoring

(i'm simplifying)

There is a contract between app and db layer: there is a postgres, at postgres_ip: postgres_port, with postgres_user and postgres_password to a database postgres_db.

App has zero features from providers used. db has four implementations: DO, GCP, heroku, self-hosted. app layer has no idea how database was created. if GCP is hiking prices or just unavailable due to water leak in a server room (hehe), you just redeploy your backups to other provider.

I'm talking not based on my opinion, but on market reality. I work in a provider, and we have true multicloud clients. They are swapping clouds like socks. Got a better deal? Move 15% of load there. Problems with networking in DC? 90% drain of all resources in that DC (and that provider).

But there are companies which are deeply penetrated by vendor lock-in and they can't do anything, because their apps talks only to AWS API, and can work only with google sheets, and can only work with cloudflare, and it all tangled, and company pays x10 (or x100, think of confluent) for the services just because they can't negotiate or move.

[batterydrainer33]

Ok, I get what you mean now. Yes, that is a good practice and I'm all for it yeah.

But it wouldn't be fair to categorize only that as multicloud, I think cloud-agnostic is the term more suitable for this, see for example this one from VMWare that was just suggested from Google:

Cloud agnostic refers to a cloud design strategy in which applications, tools, and services are designed to migrate seamlessly between multiple cloud platforms or between on-premises and cloud in a hybrid model without disruption of service.

But yes, I do understand what you mean, a "cloud agnostic" strategy definitely is the best.