4 ms·
Yeah, I would be really careful about relying on something like Aurora and planning to migrate to Cloud SQL or another vendor's managed PostgreSQL. Apps couple
by jrockway 5y ago
Yeah, I would be really careful about relying on something like Aurora and planning to migrate to Cloud SQL or another vendor's managed PostgreSQL. Apps couple very tightly to implementation quirks of their database, and even the tiniest difference between implementations is going to cause problems when you migrate. (For example, we used to test our Postgres app with SQLite. We found that each query engine treats "WHERE foo = 't'" and "WHERE foo = true" differently, though an exciting production outage. Postgres does what you'd expect, SQLite does not. That was the last time I'll ever use a different database for production and testing.)
If you are going to be cloud provider independent, then you have to bring your own foundational services that run independently of the cloud provider. Minio instead of S3, CockroachDB instead of managed Postgres, etc. (Honestly, I would feel safe switching between plain Postgres on RDS and some other provider's equivalent. Don't use any extensions, though. S3 I would probably try and get away with as well, since everything provides an S3 compatible API these days. But definitely not Aurora.)
You also need to think about your other cloud provider integrations. Do you programatically change DNS? You'll need something that can handle any provider. IAM? You'll need something that handles both providers. Even at the Kubernetes level, things work differently. Compare Google's L7 load balancer to Amazon's ALB, for example. You might create them both with "kubectl create service loadbalancer ...", but the semantics are going to be different. Persistent volume types also vary between cloud providers; your StorageClass "default" is going to have different IOPS characteristics, for example, and that can easily burn you.
I am willing to bet that anyone using the cloud for something serious will have some hiccups migrating away, even if they're using Kubernetes. It's all the stuff that's not in Kubernetes that will get you!
- greiskul 5y agoI hate this practice that some companies do of testing their sql database usage... By using another database. For postgres, if you are using the jvm, you can use the amazing test containers library to test reasonably fast, with a postgres database that you can set up to be the same version as you use in production. Any database vendor should either support having their database used quickly in test like these, or at least release a simplified in memory version of their database so people can test their code. If your database is not testable, that should be a black mark against choosing it for a project.
- syspec 5y agoWhich library are you referring to? I'm new to jvm programming, and was wondering about this as I'm used to rails where the test db is spun up on your behalf and is usually the same db
- djbusby 5y agoFor PG you can just initdb in a tmpfs.
- denysvitali 5y agoOr (and this can be done with pretty much everything) spin up a container
- thejosh 5y agoWith elixir and ecto it wraps the whole thing in a transaction so it runs Async across multiple tests.
- deleted 5y ago[deleted]
- closeparen 5y agoMuch better than mocking out cursor objects!