They built a toy object store while blogging aggressively.
Openstack Swift or Redhat Ceph are still the only real open-source object store players, AFAIK.
Multi-tenant cloud-native architecture requires each tenant to be intentionally kept small (limited by the failure domain). This way, when you scale from few hundred tenants to millions, your complexity doesn't scale proportionately. Million'th instance of Minio is as simple as its first instance. If you are looking for a global namespace, simply use ngnix like proxy load-balancers in the front. Orchestration tools are well understood at scale unlike Ceph and Swift.
Building monolithic distributed systems has a number of challenges. They do not scale beyond a point. Failure may take down the entire site. Troubleshooting is hard. No CI/CD. Entire system has to be upgraded at once with planned downtime. Security breach exposes the whole system..
Architect (Minio and formerly GlusterFS)
So glad to come across this piece; it is as if you are looking over my shoulder at my to-do list. Started messing with Minio on Docker on Raspberrypi a few days ago testing a setup to implement in my newish business in Shanghai (version 2.0). Still early days but I like what I see.
You continue to produce practical, insightful, germane pieces. Keep up the high quality work. Really appreciate it. Bought your Flocker book last month and plan to start it during Chinese New Year.
Kudos! Be well.
Making a single large PB sized volume where the disks and nodes are managed like a blackbox by the filesystem is quite scary to us at Minio. Any crash means we blew up all the tenants at once. 1000s of individual Minio tenants means, we know when we add the million'th minio instance, it is not any more complex than the first instance of Minio.
Provisioning with k8s , mesos  or other external orchestration tools is better than Minio's own resource management system. When it comes to the applications, objects are just represented as URLs. Some data sitting on Amazon S3 and some on Minio makes no difference to the application.
We are also planning to introduce a namespace layer to work on top to combine these individual tenants into single namespace. This would allow you to transparently add new clusters as you scale without loosing the ability to have a single namespace.
We hang out at slack , please reach out if you have further questions.
 - https://github.com/kubernetes/charts/tree/master/stable/mini...
 - https://github.com/dcos/examples/tree/master/1.8/minio
 - https://slack.minio.io