Hacker News Reader

Comment by wmfiv | Hacker News Reader

Except you’ve picked out two of the most complex and deep services as “foundational”.

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!

I 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.

For PG you can just initdb in a tmpfs.

Or (and this can be done with pretty much everything) spin up a container

With elixir and ecto it wraps the whole thing in a transaction so it runs Async across multiple tests.

Much better than mocking out cursor objects!

Which 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

Running your own Kubernetes cluster is complex and deep. Giving a yaml file to EKS and suddenly you have infrastructure is not complex at all. Its actually pretty sweet.

You are confusing simplicity of usage with simplicity of implementation. "dumb pipes" implement simple services for fixed or low per unit costs, the entire appeal of ready to use complex stacks like EKS is simplicity of usage.

It’s dumb in the sense that you can just move clouds without issue. You’re not using the secret special sauce that binds you tightly to AWS, everyone has a K8s and they’re all broadly the same.

Huh? Yes Aurora is highly proprietary, but S3 is a commodity in many use cases.

Commodity in usage, yes, but not on the service side. Doing S3 properly is really hard, having a service with a 'compatible API' doesn't make it the same as S3. Same goes for EKS (Yes, it looks and smells like a normal API server) and RDS.

If you never use anything that ties this stuff together (like IAM), then there is practically no point in using AWS at all, it's way too expensive to use as a 'dumb pipe'.

That said, I'm personally a fan of using things that would technically also work outside of AWS, but not shying away from the AWS-specific optimisations. I'm not going to use Kubernetes on AWS without EKS for example (plain EC2). Or Kubernetes on AWS without the Amazon's CNI, that's not a thing I'd enjoy in production either.

When managed Kafka was announced, that was another great example of "nice, now I don't have to mess with EC2 node contents anymore", but I still can if I want to, including outside of AWS.

The most AWS-native thing (or two things) that make most other offerings not work out all that great is the integrated IAM and Security Groups. Kludging those together with some crappy port to AD or NSX is just a waste of time and sanity.

Doing EB-scale s3 is really hard, throwing a few hundred terrabytes (or even couple petabytes) into s3 compatible storage on top of k8s is not that hard (getting easier every day). There’s numerous options available today even with enterprise support

> The most AWS-native thing (or two things) that make most other offerings not work out all that great is the integrated IAM and Security Groups

SGs are easily covered by kubernetes network policies. What do you need iam for if you’re not using any manager stuff? Sounds like circular argument to me (“you need managed bc you need iam bc you need managed…)

You need SGs because not everything in the world lives inside a K8S cluster or flows through a CNI. And you need IAM because if you have 10 users and 10 resources but not every user is allowed to perform all actions on all resources you need policies. Policies apply (generally) on roles, actions and resources. IAM that only works on some random resources but not on others are pointless, unless you have a very small setup (i.e. less than 100 resources, less than a small office of users), but at such a small scale, you shouldn't even be thinking about AWS (unless you are on track to scale 1000x).

S3 isn't just "I have many files and it needs a lot of disk space". Like I wrote, if you just use base S3 API primitives then no, you're not really using anything AWS-specific, and making a comparison between something that does more than you need seems odd to me. Edge storage, cold storage, cheaper storage based on reductions of redundancy or access times, mirroring, versioning, multi-level IAM (integrated with the rest of your IAM) are all things that make the difference between "look at my virtual USB disk" (most MinIO configurations out there, the unsupported ones that is) and "durable and reliable multi-level object storage, configured for my needs".

I’m sure you can find a feature that minio/ceph/swift don’t support out of the box just as i can probably find something that’s very easy to do do/add in ceph/seaweedfs but will be on the back burner of your cloud tam for a few quarters/years or do it at a cost that can’t be beat by any volume commits. At the end of the day we are payed to solve business problems with set constraints so statements like “you need s3 bc everything else is hard” are kind of myopic

Unless you are in the business of reinventing wheels and building knowledge silos that will never transfer, none of what you wrote applies in general commercial business.

If you never use anything that ties this stuff together (like IAM), then there is practically no point in using AWS at all, it's way too expensive to use as a 'dumb pipe'.

Must cheap providers have crappy networks compared to AWS.

That's true. And sometimes you get an odd mix of good network quality but crappy features, or the other way around and that isn't amazing to work with either.

Reply on news.ycombinator.com