Cloud as an Operating Model – Not a Physical Location

Cloud as an Operating Model  - Not a Physical Location

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 the building blocks of the cloud operating model.

Kubernetes: The Orchestrator of Cloud-Native Applications

Kubernetes has redefined how applications are deployed and scaled across different environments, including hybrid and multi-cloud. It facilitates automation, scaling, and self-healing for containerized applications. Kubernetes’ ability to orchestrate workloads across clusters allows enterprises to maintain agility and ensure high availability, unlocking the full potential of cloud-native infrastructures.

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.

Containers: The Core of Cloud Portability

Containers encapsulate application dependencies, enabling consistent performance across diverse environments. MinIO’s architecture is designed for containerization, simplifying deployment and providing scalability, portability, and isolation. Whether on-premises or across multiple clouds, containerized applications running with MinIO ensure data is portable, secure, and instantly available. This container-first approach ensures your cloud strategy remains flexible, allowing workloads to move seamlessly across different environments.

RESTful APIs: Building Blocks of Cloud Interoperability

RESTful APIs are integral to cloud-native applications, offering a consistent interface for interacting with services regardless of the environment. S3 is the poster-child for Restful APIs and MinIO compatibility is second only to the OG itself. If anyone wants to argue, we put forward our 2M Docker Pulls a day. MinIO’s S3 compatibility allows it to integrate with an ecosystem of applications, providing reliable, secure, and efficient data access. RESTful APIs promote interoperability between microservices, applications, and cloud infrastructures, ensuring that data can flow seamlessly, whether across on-premises or cloud environments, aligning with the operational model of the cloud.

Specifically S3…

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.

Microservices: Resilient, Modular, and Scalable Cloud Architectures

Microservices enable a cloud-native approach to application development by breaking down monolithic applications into smaller, self-contained services. This architecture allows for independent scaling, resilience, and faster deployments. MinIO supports microservices-based architectures by delivering highly scalable, secure object storage that can grow with your microservices as they scale. As microservices communicate over networks, MinIO ensures consistent performance, availability, and access to unstructured data, whether on-prem or in the cloud, making it an essential component of modern cloud infrastructure.

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.