Spaces: Scalable Object Storage on DigitalOcean
blog.digitalocean.com
blog.digitalocean.com
That's almost always a nice problem to have. If it was profitable in small scale usage, then it's usually profitable in widespread usage once economies of scale have been applied.
But I guess if you factor in not losing customers due to obscure IE problems on AWS, we could have saved over 100% ;) by not losing customers.
Some businesses don't need to worry about obscure IE problems, and AWS will make sense, for us it didn't.
The biggest reason Linode didn't make sense for us is that we couldn't scale hard drive space without scaling everything else, too. As the site grew this became pretty crazy.
I've managed to find a good Xen based vps/dedi host that let you customise memory/disk independently (but regular vps are all "just" 2 vcpus I believe).
You can still run your own CDN on linode & use amazon s3 as an origin server.
How does this industry manage to fuck up usage of very specific technical terms so often.
Bandwidth is the speed. The hint is in the name. Wider means more at once.
You're almost certainly talking about the amount of data transfered.
The most depressing part is seeing hosting companies use the same incorrect terminology.
If I were comparing cost of bursting, the semantics would be worth arguing.
Market rate is actually below $0.01/GB even, but I'm very comfortable paying that rate for a multi-homed connection to a managed service.
Not to say they don't also charge that for bandwidth in those locations, but per-GB pricing in Australia is more like 20-50c/GB
Another feature it would be nice to see is accidental deletion protection of some kind. S3 does this with versioning, and it's an important feature lacking on most of the alternatives:
> Versioning allows you to preserve, retrieve, and restore every version of every object stored in an Amazon S3 bucket. Once you enable Versioning for a bucket, Amazon S3 preserves existing objects anytime you perform a PUT, POST, COPY, or DELETE operation on them. By default, GET requests will retrieve the most recently written version. Older versions of an overwritten or deleted object can be retrieved by specifying a version in the request.
Compared to BackBlaze B2: $0.005/GB/month for storage and $0.02/GB for traffic, plus tiered API call fees (see https://www.backblaze.com/b2/cloud-storage-pricing.html)
So Spaces is better for serving assets (lower traffic cost) and B2 is better for archiving data (lower storage cost).
Take e.g. OVH's Swift pricing[1], which is $0.011 per GB (stored and outgoing). I found Swifts latency (at least on the OVH cluster, with the OVH CDN) to be much better than B2. Swift also satisfies my paranoia about having a remote storage system I could setup on-prem.
Also, more storage regions, much better network infra, actual access to software running on the cluster (Swift, not some proprietary API).
YMMV
[1] - https://www.ovh.com/us/public-cloud/storage/object-storage/
They already have a sort of "cloud formation" like API for provisioning nodes, a load balancer, and now object storage.
Maybe a managed database offering? Or managed K8S? Or a more clear "region / availability zone" strategy?
Since Google started offering strong consistency that's been a really tempting feature. We often want to upload something for another user to immediately access, and having that extra delay or potential 404 with other services sucks. But Google's pricing is nowhere near B2 or now DO's Spaces.
Any thoughts on eventually adding strong consistency to Spaces?
> Spaces currently supports v2 of pre-signed URL functionality. Tools and libraries that only support v4 of pre-signed URL functionality will not work.
I had really hoped this would be in place for the launch, but I guess this wasn't a priority. Looking forward to this + EU locations!
[1] https://www.digitalocean.com/community/tutorials/an-introduc...
B2 also has a free tier for the first 10 GB of storage, 1 GB of daily downloads. DO charges $5/month minimum
Storage: $0.0112/month/GB, Outgoing traffic: $0.011/GB
I only wish the other regions would roll out quicker(sfo please!)
Also a bit weird you have to use S3 to connect to it even though it isn't S3, unless this new feature is S3 but wrapped in Digital Ocean interface?
It means they can support any apps/services that currently rely on s3 without little more than a s3 host/URL change.
Spaces isn't working with Transmit 5 yet. I don't have the technical details, but it's a known issue that's being worked on. I'll write a Transmit 5 tutorial as soon as it works.
And they aren't 100% compatible. I believe that DO doesn't support headObject, bucketExists and creating presigned upload URLs.
i thiink cdn is more cheap. am i wrong?