←back to thread

From S3 to R2: An economic opportunity

(dansdatathoughts.substack.com)
274 points dangoldin | 3 comments | | HN request time: 0.001s | source
Show context
simonsarris ◴[] No.38118991[source]
Cloudflare has been attacking the S3 egress problem by creating Sippy: https://developers.cloudflare.com/r2/data-migration/sippy/

It allows you to incrementally migrate off of providers like S3 and onto the egress-free Cloudflare R2. Very clever idea.

He calls R2 an undiscovered gem and IMO this is the gem's undiscovered gem. (Understandable since Sippy is very new and still in beta)

replies(4): >>38119194 #>>38120069 #>>38120641 #>>38122400 #
ravetcofx ◴[] No.38119194[source]
What are the economics that Amazon and other providers have egress fees and R2 doesn't? Is it acting as a loss leader or does this model still make money for CloudFlare?
replies(9): >>38119285 #>>38119489 #>>38119521 #>>38119701 #>>38119768 #>>38119769 #>>38120649 #>>38121416 #>>38125131 #
kazen44 ◴[] No.38119701[source]
also, egress fees are a sort of vendor lock-in, because getting data out of the cloud is vastly more expensive then putting new data into the cloud..
replies(2): >>38119793 #>>38120093 #
oaktowner ◴[] No.38119793[source]
Exactly this. Data has gravity, and this increases the gravity around data stored at Amazon...making it more likely for you to buy more compute/services at Amazon.
replies(1): >>38123709 #
1. jgalt212 ◴[] No.38123709[source]
very true, but data gets stale very quickly. So you start putting new data in a new place. Eventually, you don't care about the old place. And all the people and processes who accessed the data in the old place are gone.
replies(1): >>38126110 #
2. hnwizard ◴[] No.38126110[source]
Completely agreed about data gravity, but it's not just that, it's also customer opted-in vendor-lockin.

The customer (because they are lazy, don't know better, aren't capable of, or all three) opts in to use various "convenient" CSP "services". These services could look convenient (and are always pretty to extremely expensive), they quickly becomes an integral part of the customer's badly architected "system".

The end result is complete vendor-lockin, the inability of the poor (stupid) user to leave and the continued gang rape of their bank account (also via additional, incompetent developer and devops "resources").

Throw in average modern "devops" who are hired to handle this. They aren't like the sysadmin of yesteryear, they no longer have experience with, or understand the bits and bytes. They are glorified UI clickers and YAML editors, they even lack any reasonable system level debugging skills. For every problem they encounter they first immediately run to google in search for answers.

In addition, I would argue that CSPs are a huge, huge waste of computing, space and power resources, because their systems completely encourage people to just do things, without understanding what they are doing, screw the consequences and just pay.

Result, the business suffers greatly (on so many levels), the CSP wins big and continues winning.

What happens here is that a system, if designed right from the get go, could have been run on a SINGLE, modern, high end, well positioned and connected server to the Internet, is now replaced with tens to hundreds of "instances" and random assorted CSP provided services -- what a colossal waste.

Books can be written on negligence, lack of understanding, utter tech stupidity and ultimately the costs which are absurd.

replies(1): >>38147603 #
3. 20after4 ◴[] No.38147603[source]
It is a colossal waste of resources, indeed.

It's also a huge waste of human effort managing the complexity introduced by the cloud provider's arbitrary bullshit.

At this point multiple generations of engineers have little understanding of underlying layers of technology, having only really learned how to use cloud services. No TCP/IP, no UNIX, just a bit of bash and a ton of AWS.

Cloud providers do hide most of the low level complexity, which could be seen as a benefit (at least that seems to be what's touted as a main benefit, along with instant scalability.) Unfortunately they replace all of that with more arbitrary complexity which is ultimately (in my opinion, at least) a much bigger burden than the fundamental complexity that is abstracted away.