Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS is not a dumb pipe

matt-rickard.com

Post reply on HN
Print view View original

41–50 of 90 posts

Re: AWS is not a dumb pipe

#41

Post by jrockway »

wmfiv wrote: post #21
didip wrote: post #17

But it can be a dumb pipe. More and more companies prefer that. Just deploy everything on EKS and use only foundational services such as S3 and PostgreSQL Aurora. There you go: Dumb Pipes. Edit: When I say dumb, it's more like: Dumb enough so that another public cloud vendor, such as GCP or Azure, can be swapped in.

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!

Re: AWS is not a dumb pipe

#43

Post by quickthrower2 »

meepmorp wrote: post #25
quickthrower2 wrote: post #20

Earlier quoted context omitted.

Heroku* and DigitalOcean too. Hell even Hostgator. *Heroku is expensive though but is nice to use

Heroku runs on AWS, doesn’t it?

Heroku:

* Big NO

* expensive YES

* boondoggly NO

* stranglehold on legacy workloads NOT SURE

* friends with your C-suite NO

* engineers and ICs hate it NO

It hits many of the pain points, not all.

Heroku is non-leaky in it's use of AWS. If they switch to something else under the hood you wouldn't know and wont need to change code. The only leaky part is the pricing of someone who is buying wholesale and selling retail.

Re: AWS is not a dumb pipe

#44

Post by throwaway2048 »

tjr225 wrote: post #31
wmfiv wrote: post #21

Earlier quoted context omitted.

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

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.

Re: AWS is not a dumb pipe

#45

Post by greiskul »

jrockway wrote: post #41
wmfiv wrote: post #21

Earlier quoted context omitted.

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 "WH…

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.

Re: AWS is not a dumb pipe

#46

Post by xg15 »

oneplane wrote: post #35

AWS isn't a single "thing", or perhaps, it's only a bundled brand. There are many teams, sub-companies, divisions, groups all working on their own parts. Most have to follow a similar set of rules and some attempts are made to make it cohesive, but in the end it's not a single minded entity with a single set of parameters it follows for every service offering. You can run your stuff on AWS without ever touching compu…

Ok, but by that logic it would be impossible to make any kind of analysis about AWS (or other cloud providers) in the sense that the author attempted to make.

In the end I believe, the question is about lock-in and control. In a true "dumb pipe" offering, you could just take your software elsewhere and run essentially the same code without changes. Meanwhile, if you use various proprietary APIs, this is not the case. I'd argue, even if the APIs have open source implementations that you could theoretically use elsewhere, it's not clear how viable this would be in practice.

I think AWS does not become a "dumb pipe" only because you could theoretically use it like that - at least not if doing so would require you to go "against the grain" of the platform the whole time and would force you to only use a fraction of what you paid for.

Re: AWS is not a dumb pipe

#47

Post by djbusby »

greiskul wrote: post #45
jrockway wrote: post #41

Earlier quoted context omitted.

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 "WH…

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…

For PG you can just initdb in a tmpfs.

Re: AWS is not a dumb pipe

#48

Post by oneplane »

xg15 wrote: post #46
oneplane wrote: post #35

AWS isn't a single "thing", or perhaps, it's only a bundled brand. There are many teams, sub-companies, divisions, groups all working on their own parts. Most have to follow a similar set of rules and some attempts are made to make it cohesive, but in the end it's not a single minded entity with a single set of parameters it follows for every service offering. You can run your stuff on AWS without ever touching compu…

Ok, but by that logic it would be impossible to make any kind of analysis about AWS (or other cloud providers) in the sense that the author attempted to make. In the end I believe, the question is about lock-in and control. In a true "dumb pipe" offering, you could just take your software elsewhere and run essentially the same code without changes. Meanwhile, if you use various proprietary APIs, this is not the case.…

You definitely can, but I'm not sure what the point would be. Say you are a commercial entity and you need to not run everything vertically integrated. You go look for external entities that can do some of the work for you, preferably specialised in such a way that it efficiently delivers whatever you need. At that point, this whole 'dumb pipe' concept is just a column in a crappy spreadsheet somewhere that might make a minor impact on the choice being made. Spending 10 million extra each month because an engineer liked the sound of a dumb pipe better with a vague promise of easier migrations isn't realistic.

If someone truly wants to not be dependent, you need to identify to what degree you want that, and then end up paying a lot more to get there, usually ending up multi-could. Even three 'dumb pipes' aren't similar enough to create a 'write once' IaC and application definition. The closest you can get is not using FaaS-type offerings and sticking to OCI containers. You'll still have to work with the IAM and network primitives each vendor requires, and even if you don't run active-active you'll still have to write every deployment to every provider you use to ensure your systems are always ready to deliver.

It's not impossible, but impractical and expensive. For most companies, the ROI just isn't there. Offloading more day-to-day and non-company-specific work is the way, and dumb pipes can't do that.

Re: AWS is not a dumb pipe

#49

Post by oneplane »

dilyevsky wrote: post #37
oneplane wrote: post #30

Earlier quoted context omitted.

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 sai…

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 b…

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

Re: AWS is not a dumb pipe

#50

Post by thisguyagain »

rglover wrote: post #23

AWS would be a far superior product if it trended toward being a dumb pipe. The "all the things" approach that AWS has taken has led to a lot of great ideas being poorly executed, leading to a mess and poor engineering. E.g., the new (V3) of the JavaScript SDK is such a clusterf*ck I almost can't believe they had the stones to ship it.

What’s not working for you with the V3 JS SDK?
Post reply on HN