4 ms·

Here is the reasoning why they didn't have "s3 compatibility" before: https://www.backblaze.com/blog/design-thinking-b2-apis-the-hidden-costs-of-s3-compatibilit

Here is the reasoning why they didn't have "s3 compatibility" before: https://www.backblaze.com/blog/design-thinking-b2-apis-the-hidden-costs-of-s3-compatibility/ https://www.backblaze.com/blog/design-thinking-b2-apis-the-h...

yamrzou 6y ago
So how did they manage to get rid of those hidden costs? Or is the new S3 compatible API more expensive?
- toomuchtodo 6y ago
  It's possible they're eating the cost of the load balancing necessary to multiplex from their backends to client requests, which should theoretically stoke an increase in business due to reduced switching costs (and what timing, with an economic contraction likely pushing cost reductions at those needing cloud storage). Disclaimer: Happy Backblaze Mac client and B2 customer, no other affiliation. EDIT: @yev: I took the signal out after the sibling reply :) Appreciate the responses as always. Please stay awesome.
  - fthead9 6y ago
    From Gleb (CEO) comment on the blog. "Yes - B2 is still a more cost efficient API as it allows customers to connect directly to the final storage location. However, we have built a highly cost efficient load balancing system as we always have - using software to optimize inexpensive hardware - and are swallowing the additional costs for our customers."
  - atYevP 6y ago
    Yev here -> saw my Yev-signal. That's right, Gleb actually answered that question on our blog (https://www.backblaze.com/blog/backblaze-b2-s3-compatible-api/#comment-4900843623 https://www.backblaze.com/blog/backblaze-b2-s3-compatible-ap...) but we're eating the cost. Om nom nom.
    - deleted 6y ago
      [deleted]
    - justinclift 6y ago
      Interesting. Implementation wise, is it some form of Minio gateway + hardware?
      - budmang 6y ago
        No gateway - native code written from scratch and optimized for our environment...sitting on top of regular, inexpensive hardware.
        atYevP 6y ago
        When you say regular, I think you mean awesome Storage Pods that were lovingly purpose-built for affordable and efficient data storage (https://www.backblaze.com/b2/storage-pod.html https://www.backblaze.com/b2/storage-pod.html). *Edit -> Well, those plus the load balancing servers =D
- brianwski 6y ago
  Disclaimer: I work at Backblaze. > So how did they manage to get rid of those hidden costs? Or is the new S3 compatible API more expensive? The new S3 compatible APIs are the same cost as the original native B2 APIs. I'm the author of that original blog post, and we were able to get rid of SOME of the internal costs, but in the end we ate the cost of the load balancer. Internally I voted that we externalize that cost, but it's in the spirit of our "no-sales-friction" pricing model to get rid of decision points for customers and just let them get their stuff done. The internal math is that we believe the additional storage that (hopefully) will result from supporting the S3 API will help make up the cost of the upload balancers. It eats into our margin, but not by enough to justify a "friction pain point" that might reduce sales as customers struggle to decide which API to use. When you do the math over thousands of customers, we make the vast majority of money simply from renting the storage. Many many many customers upload things to Backblaze, and let them sit for long enough, that the cost of the load balancers becomes pretty small as a percentage. One of our goals of the pricing of Backblaze Personal Backup (flat fee of $6/month regardless of how much data you backup) and not charging much for transactions is we aren't trying to nickle and dime customers. We just want to make our margin and provide a solid service that makes customers happy.
  - anderspitman 6y ago
    Are you guys apprehensive at all that supporting S3 might bring in more lower margin customers (ie higher transfer GB/store GB ratio)? In any case, thanks for B2 (happy customer) and good luck. Sounds like an exciting time.
    - budmang 6y ago
      (backblaze ceo here) We're happy to take customers regardless of which API they choose. Sure, we make a bit more on our B2 Native APIs, but ultimately I'd rather we make it easy for them to use us how they wish.
tambre 6y ago
>It requires Amazon to have a massive and expensive choke point in their network: load balancers. When a customer tries to upload to S3, she is given a single upload URL to use. For instance, s3.amazonaws.com/<bucketname>. Now that Amazon has deprecated the single URL version and replaced it with region-specific URLs (e.g. s3.dualstack.us-east-1.amazonaws.com) and tooling has been mostly updated, this huge reason for not supporting the S3 API is gone.
- deleted 6y ago
  [deleted]
- jjeaff 6y ago
  Even though they are using region specific URLs, they would still have to load balance all of that traffic. Backblaze avoided this by having a 2 part request for a file. You would make a request to a centralized url and then that would return a url that connected you directly to a server that had that file.
  - yjftsjthsd-h 6y ago
    > You would make a request to a centralized url and then that would return a url that connected you directly to a server that had that file. Heh, kinda like how FTP worked. That's funny to see again.

yamrzou 6y ago

So how did they manage to get rid of those hidden costs? Or is the new S3 compatible API more expensive?

toomuchtodo 6y ago
It's possible they're eating the cost of the load balancing necessary to multiplex from their backends to client requests, which should theoretically stoke an increase in business due to reduced switching costs (and what timing, with an economic contraction likely pushing cost reductions at those needing cloud storage). Disclaimer: Happy Backblaze Mac client and B2 customer, no other affiliation. EDIT: @yev: I took the signal out after the sibling reply :) Appreciate the responses as always. Please stay awesome.
- fthead9 6y ago
  From Gleb (CEO) comment on the blog. "Yes - B2 is still a more cost efficient API as it allows customers to connect directly to the final storage location. However, we have built a highly cost efficient load balancing system as we always have - using software to optimize inexpensive hardware - and are swallowing the additional costs for our customers."
- atYevP 6y ago
  Yev here -> saw my Yev-signal. That's right, Gleb actually answered that question on our blog (https://www.backblaze.com/blog/backblaze-b2-s3-compatible-api/#comment-4900843623 https://www.backblaze.com/blog/backblaze-b2-s3-compatible-ap...) but we're eating the cost. Om nom nom.
  - deleted 6y ago
    [deleted]
  - justinclift 6y ago
    Interesting. Implementation wise, is it some form of Minio gateway + hardware?
    - budmang 6y ago
      No gateway - native code written from scratch and optimized for our environment...sitting on top of regular, inexpensive hardware.
      - atYevP 6y ago
        When you say regular, I think you mean awesome Storage Pods that were lovingly purpose-built for affordable and efficient data storage (https://www.backblaze.com/b2/storage-pod.html https://www.backblaze.com/b2/storage-pod.html). *Edit -> Well, those plus the load balancing servers =D
brianwski 6y ago
Disclaimer: I work at Backblaze. > So how did they manage to get rid of those hidden costs? Or is the new S3 compatible API more expensive? The new S3 compatible APIs are the same cost as the original native B2 APIs. I'm the author of that original blog post, and we were able to get rid of SOME of the internal costs, but in the end we ate the cost of the load balancer. Internally I voted that we externalize that cost, but it's in the spirit of our "no-sales-friction" pricing model to get rid of decision points for customers and just let them get their stuff done. The internal math is that we believe the additional storage that (hopefully) will result from supporting the S3 API will help make up the cost of the upload balancers. It eats into our margin, but not by enough to justify a "friction pain point" that might reduce sales as customers struggle to decide which API to use. When you do the math over thousands of customers, we make the vast majority of money simply from renting the storage. Many many many customers upload things to Backblaze, and let them sit for long enough, that the cost of the load balancers becomes pretty small as a percentage. One of our goals of the pricing of Backblaze Personal Backup (flat fee of $6/month regardless of how much data you backup) and not charging much for transactions is we aren't trying to nickle and dime customers. We just want to make our margin and provide a solid service that makes customers happy.
- anderspitman 6y ago
  Are you guys apprehensive at all that supporting S3 might bring in more lower margin customers (ie higher transfer GB/store GB ratio)? In any case, thanks for B2 (happy customer) and good luck. Sounds like an exciting time.
  - budmang 6y ago
    (backblaze ceo here) We're happy to take customers regardless of which API they choose. Sure, we make a bit more on our B2 Native APIs, but ultimately I'd rather we make it easy for them to use us how they wish.

tambre 6y ago

>It requires Amazon to have a massive and expensive choke point in their network: load balancers. When a customer tries to upload to S3, she is given a single upload URL to use. For instance, s3.amazonaws.com/<bucketname>. Now that Amazon has deprecated the single URL version and replaced it with region-specific URLs (e.g. s3.dualstack.us-east-1.amazonaws.com) and tooling has been mostly updated, this huge reason for not supporting the S3 API is gone.

deleted 6y ago
[deleted]
jjeaff 6y ago
Even though they are using region specific URLs, they would still have to load balance all of that traffic. Backblaze avoided this by having a 2 part request for a file. You would make a request to a centralized url and then that would return a url that connected you directly to a server that had that file.
- yjftsjthsd-h 6y ago
  > You would make a request to a centralized url and then that would return a url that connected you directly to a server that had that file. Heh, kinda like how FTP worked. That's funny to see again.