We have said it before, but it bears repeating. The cloud is an operating model - not a physical location. That is why you will find MinIO everywhere on the public cloud, on the private cloud, at the edge. We don’t differentiate and because we are cloud native we are cloud (location) agnostic.

The public cloud has mindshare and gravity, however, in ways that cannot be denied. It is the place to learn the way of the cloud and it offers the allure of instant infrastructure, a bevy of services and minimal friction.

It is not without it’s dark side. Cloud lockin is a real thing and there are massive enterprise software companies that are seeing that dark side first hand as they try and re-engineer their economics within highly constrained parameters.

Optionality is goal for any well architected system because optionality provides control. Control delivers leverage.

That is why both established enterprises and emerging startups are changing the way they think about the cloud. The sophisticated strategy they are employing is to use substitutable software over proprietary systems. While open source has a role to play - that is not the core element of the argument, it is more about modular standards-based approaches. These, architected correctly, can be applied anywhere, and that creates optionality.

Here is a simple litmus test. If your entire software stack can be defined in a Kubernetes YAML that can be deployed on any new infrastructure, public or private cloud several times a day, you are ready. If there are any proprietary services, hardware appliances or baremetal software dependencies, You will not pass the test.

Here are a few examples of substitutable software that provide the optionality the enterprise requires.

S3 Compatible Object Storage

The beauty of S3 compatible object storage isn’t just its infinite scalability or RESTful APIs - but its extensibility. MinIO is a drop-in replacement for AWS S3 that runs on AWS itself, on GCP, Azure, Tanzu, Ezmeral, SUSE Rancher or bare metal. AWS S3 pioneered the modern object store, but it is stuck inside of AWS. We just did it the favor of breaking it out.

This means you can leave behind the hidden costs associated with each tranche of API calls, egress charges, etc. They may seem de minimus, at first, but we suspect those charges alone, sans capacity and compute, exceed the sales of all but top of the Cloud 100.

Deploying MinIO in place of the “native” cloud object store makes a ton of sense. That is why we are on every marketplace with click to deploy models. Yes, you still pay for capacity, compute and networking, but you create freedom for yourself. Vendor lockin is incredibly expensive - not just for when your credits and discounts expire - but for your organizational agility. If you literally can’t move your workload you have lost all control. And so you have lost all your leverage.

Procurement teams are increasingly attuned to this phenomena. Their jobs depend on not ceding control of the tech stack.

There is the side benefit of continuity but the core benefit is optionality. Only MinIO can provide that. Let’s be clear, everyone claims to be an S3 compatible object store. If the only place that you add is “on prem” then it is not that valuable. That is the “value” that the appliance vendors offer. That isn’t optionality. That is choice. Cloud or on-prem not cloud AND on-prem. Enterprises want more.

Databases

Each cloud provider seems to have their own take on databases, such as Amazon RDS, Microsoft SQL Manager Instances and GCP Cloud SQL. Amazon even offers hosted and managed versions of third party, cloud native database software (think Mongo or Elastic). But using hosted or cloud managed database services will incur cloud usage taxes which include storage, IO counts, backups, etc., all which will add to the cost of running your apps in cloud.

But there are plenty of cloud native database systems out there, that include SQL and NoSQL databases, in memory databases, massively distributed databases, etc. Most can be readily deployed from cloud marketplaces with a few clicks. As discussed above, you pay for compute, networking, and storage and in some cases, software licenses and support, but you avoid any other cloud use taxes and again if you ever plan to repatriate your apps, using cloud native databases rather than cloud hosted, managed or proprietary ones will make this much easier to do.

Kubernetes

All cloud providers offer hosted K8s services, e.g., EKS from AWS, AKS for Azure, GKE for GCP, etc. To be fair, using hosted K8s services will be easier to use and deploy up front - it is the long-term lockin that is problematic. This aligns with our standard advice on the subject - which is to go to cloud to get started, but once your skill set improves and your workload is well understood - you repatriate. The same goes here. The cloud offerings are a superb way to get your Kubernetes sea legs, but over time, Kubernetes knowledge will enable you to have the application and infrastructure mobility that are the proverbial pot at the end of the rainbow.

Deploying native K8s as an alternative would avoid cloud use taxes. It’s more work to install, configure and run native K8s, but once you’ve done this, the container apps and the orchestration system can be run anywhere you wish.

MinIO is agnostic. We have hundreds of thousands of deployments each of AKE, EKS, GKE, stock, Tanzu, OpenShift, SUSE, Ezmeral. We deliver optionality, which delivers control.

Summary

Like all the above, just about any major stack component exists in both cloud proprietary and cloud native options. And just like all the above, most of these other cloud native components are readily available and installable from cloud marketplaces. Using these, one can take advantage of the cloud provider’s instant hardware infrastructure without having to pay the extra costs and taxes for cloud hosted, managed or proprietary solutions.

The disadvantages to deploying cloud native substitutes for hosted SaaS services are often framed as the added time and effort to deploy and manage them, which is, in some part, true.  Even those advantages have been significantly reduced with the introduction of Kubernetes operators. Operators fully automate all the day 2 operations, and they're also portable across clouds.

Nonetheless, the advantages are stark - extreme portability and cheaper cost, with equivalent, if not superior scaling, performance, and functionality. And if you ever decide to repatriate, using cloud native stack components will make that transition substantially easier.

The choice is yours, deploy cloud proprietary solutions and pay cloud use taxes or alternatively, spend more time and effort to deploy cloud native alternatives and reap the savings and portability that comes with them.