Tigris makes your storage multicloud for you, so you don’t have to worry about all that.
Lifecycle rules automatically move your objects to archive or infrequent access tiers to help cut storage costs. This feature has become pretty standard for object storage systems, but under the hood, it’s relatively complex to implement. Especially when you’re building with global storage across many regions. Let’s walk through how we built the feature, and where things got a little complicated.
On Tigris, you can set any domain name to point to any bucket. Why does this matter?
Multi-cloud is all the rage these days. A new neocloud pops up every week offering cheap compute, and running your apps on Kubernetes means they’re easily ported to another provider. Compute is fungible, but storage is sticky. Using a custom domain to front your bucket of data makes it easy to swap out storage providers without updating all the code that uses that storage.
We’ve made it easy to share buckets with your team. Surprisingly, it isn’t so easy to share buckets on $BigCloud. Life doesn’t have to be hard when you have good developer experience.
Let’s say you want to share a bucket in a big public cloud. Suddenly you need permissions to author IAM policies, and you have to worry about user policies, bucket policies, and trawl through the documentation to remember which verb means “this user can do this policy on these resources”. Tigris supports all the IAM goop you’re used to if you want to copy and paste something you already have. But you don’t have to deal with IAM policies if you don’t want to. We’ve made it easy to share access to buckets in the UI, exactly how you’d expect it to work.
As the saying goes, there’s two hard problems in computer science:
Tigris takes care of cache invalidation, and we’d love to help with that last one, but now we can help you out if you named your object wrong. That’s right, we’ve added the ability to rename objects.
