I had to re-read the recent thread[0] of reasons to realize they were only interested in deploying it outside of the cloud. I'm curious to answer why you'd have it in the cloud as well.
1. To have a unified (S3-compatible) interface across clouds storage backends
2. To use the same deployment code everywhere. If you're multi-cloud, maintaining different storage backends is complex.
Also, you can deploy Minio backed by either your own storage (like AWS EBS) or as a layer in front of cloud storage (S3, GCS, etc). So even with the Minio interface on top, you are still using managed cloud storage.
I disagree about complexity, the object storage is the simplest APIs out there. Even if I was multi-cloud, I'd prefer writing adapters instead of trying to host a an object storage. I get the use case but it feels so overreach. S3 has 11 9s, and I'm sure others are high too. Even if it proxies, minio would be a useless layer that is not adding any considerable value and introducing a reliability risk, operation cost, because I'd not prefer writing 3 if clauses to handle multiple cloud providers in my code.
I've used it a bit in cases where you need to use object storage on prem, or when you don't have cloud service access during development. But I don't see a use for it myself beyond that.
> So even with the Minio interface on top, you are still using managed cloud storage.
But… you’re not. You’ve just taken a service that can scale to any request volume and slapped a slow proxy in front of it that you need to manage, patch, keep up, debug etc.
This completely defeats one of the major selling points of the service you’re proxying, whilst reducing everything down to the lowest common denominator that minio supports. How would an application running on GCP with minio generate a signed public URL to an object?
That and completely ignoring whatever IAM offerings your cloud has.
The thing that makes minio a complete non starter for any serious use case imo is the fact that you can not expand volume without downtime. Also running minio in cloud in general seems like a dubious proposition given you’ll pay more for both storage (even with local volumes) and network (if you run multi-az and especially multi-cloud).
10 comments
[ 0.19 ms ] story [ 24.4 ms ] thread[0] https://news.ycombinator.com/item?id=30012746
2. To use the same deployment code everywhere. If you're multi-cloud, maintaining different storage backends is complex.
Also, you can deploy Minio backed by either your own storage (like AWS EBS) or as a layer in front of cloud storage (S3, GCS, etc). So even with the Minio interface on top, you are still using managed cloud storage.
But… you’re not. You’ve just taken a service that can scale to any request volume and slapped a slow proxy in front of it that you need to manage, patch, keep up, debug etc.
This completely defeats one of the major selling points of the service you’re proxying, whilst reducing everything down to the lowest common denominator that minio supports. How would an application running on GCP with minio generate a signed public URL to an object?
That and completely ignoring whatever IAM offerings your cloud has.
There are very few reasons to do this.