5 ms·

Dropbox did the same thing a few years back - moved everything from Amazon S3 to their own storage. My guess is they did it for cost reasons.

llarsson 6y ago
That S3 is eventually consistent with object updates (HTTP PUT) might also screw up things for a company whose core value is synchronized storage.
- boredpudding 6y ago
  Since the move to S3 is only 'a few years ago', my guess is this was not the reason for them to move away from S3 since service at Dropbox is pretty much the same.
- RachelF 6y ago
  I suspect that is behind many problems with Google Drive. Sometimes old versions seems to take precedence over newer ones, for some reason.
- dfsegoat 6y ago
  I don't mean to sound daft, just clarifying my own understanding, but isn't Dropbox eventually consistent (as a system)?
  - llarsson 6y ago
    Oh, sure, but when they think they have written something to S3 and got a successful HTTP response back from the API, perhaps they want to be able to tell clients to go fetch the new data from the bucket. But those clients may not get the new data then, due to eventual consistency.
    - lozenge 6y ago
      S3 is immediately consistent for new objects unless the service received a GET on the object before it was created. It's easy to use this to make an immediately consistent system.
      - llarsson 6y ago
        Yes. HTTP POST (new objects) is immediate, HTTP PUT (updates to objects) is eventually consistent. If you want to use this to create new objects all the time, rather than update ones you already have, you now have to keep track of which objects in your bucket are "old" and should no longer be there. But yes, totally doable.
      - ozkatz 6y ago
        S3 ListObjects calls are eventually consistent (i.e. list-after-put). EMRFS [1] and S3Guard [2] mitigate this for data processing use cases. [1] - https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-f... [2] - https://blog.cloudera.com/introducing-s3guard-s3-consistency-for-apache-hadoop/ https://blog.cloudera.com/introducing-s3guard-s3-consistency...
- ayush--s 6y ago
  They might have implemented a metadata store 1 layer before S3 to guarantee read after write consistency since write to a new object is consistent in S3. Only updates are eventually consistent.
hn_throwaway_99 6y ago
They did, but at Dropbox's size it should be pretty obvious. I mean, their whole business model is essentially acting as a cloud storage provider. Once they got big enough, of course it made sense for them to optimize their infrastructure instead of letting another company take x% off the top.
- deleted 6y ago
  [deleted]
- rumanator 6y ago
  > Once they got big enough, of course it made sense for them to optimize their infrastructure Isn't that true in all cases? There is no doubt that rolling and maintaining your own infrastructure can be and is better than dumping cash on the AWSs of this world. The only question is what size marks the breakeven point.
  - hn_throwaway_99 6y ago
    I think it is actually only very true in a small number of cases. First, you need to be big enough where the cost of the people needed to support your infrastructure can be amortized over a (very) large number of machines. Second, Amazon, Microsoft and Google pay some of the best salaries around, so they have some of the best infrastructure people working for them. Looking at the comments here, I think it's clear that there are a relatively small number of use cases where roll your own is a better idea, primarily where you have a huge number of servers basically all doing the same thing with lots of data transfer (which is comparatively expensive in the cloud). This may be cheaper to manage when a small team of people if you're essentially cloning similar setups.
StreamBright 6y ago
How many other companies do you know that have same problem as Dropbox? An average company that uses does not provide IT infrastructure (like storage in this case) to a massive amount of clients.
m463 6y ago
I expect many companies do that. They prioritize growth over costs (stock price over profitability). Then they get to a certain inflection point on the growth curve and splurging for unpredictable capacity slowly is replaced with reasonable costs for the known capacity.

llarsson 6y ago

That S3 is eventually consistent with object updates (HTTP PUT) might also screw up things for a company whose core value is synchronized storage.

boredpudding 6y ago
Since the move to S3 is only 'a few years ago', my guess is this was not the reason for them to move away from S3 since service at Dropbox is pretty much the same.
RachelF 6y ago
I suspect that is behind many problems with Google Drive. Sometimes old versions seems to take precedence over newer ones, for some reason.
dfsegoat 6y ago
I don't mean to sound daft, just clarifying my own understanding, but isn't Dropbox eventually consistent (as a system)?
- llarsson 6y ago
  Oh, sure, but when they think they have written something to S3 and got a successful HTTP response back from the API, perhaps they want to be able to tell clients to go fetch the new data from the bucket. But those clients may not get the new data then, due to eventual consistency.
  - lozenge 6y ago
    S3 is immediately consistent for new objects unless the service received a GET on the object before it was created. It's easy to use this to make an immediately consistent system.
    - llarsson 6y ago
      Yes. HTTP POST (new objects) is immediate, HTTP PUT (updates to objects) is eventually consistent. If you want to use this to create new objects all the time, rather than update ones you already have, you now have to keep track of which objects in your bucket are "old" and should no longer be there. But yes, totally doable.
    - ozkatz 6y ago
      S3 ListObjects calls are eventually consistent (i.e. list-after-put). EMRFS [1] and S3Guard [2] mitigate this for data processing use cases. [1] - https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-f... [2] - https://blog.cloudera.com/introducing-s3guard-s3-consistency-for-apache-hadoop/ https://blog.cloudera.com/introducing-s3guard-s3-consistency...
ayush--s 6y ago
They might have implemented a metadata store 1 layer before S3 to guarantee read after write consistency since write to a new object is consistent in S3. Only updates are eventually consistent.

hn_throwaway_99 6y ago

They did, but at Dropbox's size it should be pretty obvious. I mean, their whole business model is essentially acting as a cloud storage provider. Once they got big enough, of course it made sense for them to optimize their infrastructure instead of letting another company take x% off the top.

deleted 6y ago
[deleted]
rumanator 6y ago
> Once they got big enough, of course it made sense for them to optimize their infrastructure Isn't that true in all cases? There is no doubt that rolling and maintaining your own infrastructure can be and is better than dumping cash on the AWSs of this world. The only question is what size marks the breakeven point.
- hn_throwaway_99 6y ago
  I think it is actually only very true in a small number of cases. First, you need to be big enough where the cost of the people needed to support your infrastructure can be amortized over a (very) large number of machines. Second, Amazon, Microsoft and Google pay some of the best salaries around, so they have some of the best infrastructure people working for them. Looking at the comments here, I think it's clear that there are a relatively small number of use cases where roll your own is a better idea, primarily where you have a huge number of servers basically all doing the same thing with lots of data transfer (which is comparatively expensive in the cloud). This may be cheaper to manage when a small team of people if you're essentially cloning similar setups.

StreamBright 6y ago

How many other companies do you know that have same problem as Dropbox? An average company that uses does not provide IT infrastructure (like storage in this case) to a massive amount of clients.

m463 6y ago

I expect many companies do that. They prioritize growth over costs (stock price over profitability). Then they get to a certain inflection point on the growth curve and splurging for unpredictable capacity slowly is replaced with reasonable costs for the known capacity.