Traditionally, the design, acquisition and deployment of storage required specialized skills and the ability to manage a fair amount of complexity to do successfully. Modern object storage has changed that. This is particularly poignant today - where the purchase of SAN and NAS appliances often take months, or longer, to complete. This stands in stark contrast to software defined object storage which can be downloaded and deployed on existing hardware in minutes - complete with license.

For this reason and others, modern object storage is much more like a data store than it is “storage.” This prompted us to look a little more closely at the ever widening gap between legacy SAN/NAS approaches and modern, cloud-native object storage.

Data Store, Object Store

SAN/NAS systems were typically purchased by infrastructure buyers designed to satisfy shared requirements in the data center. This concentrated a tremendous amount of power in IT, but also created real pressure in terms of responsiveness. As data grew, the challenge of keeping up proved too much and developers, lines of business owners, architects and application teams began to adopt software defined storage that better matched the remarkably diverse data and workloads they were running. That led them directly to modern, cloud-native object storage.

As a result, the share of enterprise data under object storage has surged. This is a function of the simplicity, scale, ease of operations and cloud-native APIs offered by object stores. At this point, you will not find a new, data-intensive application running on SAN/NAS appliances - even old school IT teams understand the power of the cloud operating model.

GTM Dynamics

The SAN/NAS model is also a channel model at its heart. Channels have value - but they can introduce complexity and cost. They absolutely introduce friction to the evaluation and purchase process. When working with the channel or VAR, extensive planning was required to accommodate the multi-faceted configuration stage, as well as operator training for ongoing system monitoring/management for proper use.

In contrast, modern, cloud-native object storage purchases are extremely simple. Download the software and use a credit card for the license if you want. MinIO, GCP, AWS, and Microsoft support this model and with IBM, you can use your contracted dollars against MinIO licenses. It is that simple. Of course, server hardware with storage must be available or purchased but these are much simpler to size and acquire than SAN/NAS systems.  Check out our reference hardware page for some ideas.

Sizing and Scale Out

SAN/NAS systems commonly require a long (3-5 year) term sizing estimate to ensure that they can support future storage requirements. This is because SAN/NAS appliances only support a limited range of storage capacity and performance, which once exceeded, requires the replacement of the appliance and migration of its data over to the new system.

Object storage also needs to be sized. But here, one can just use present data requirements to guide hardware acquisition. This is because object storage, as a pure software defined solution, has performance and capacity increments which are designed to be customer tuned. Further, through techniques like server pools, modern object storage can easily and seamlessly deliver against HW heterogeneity.  Tunable elements can range from the granularity of a single disk drive or SSD to as large as a server and its accompanying storage. As capacity and performance increments are so fine grained and user defined, there is simply no need to try to size object storage far beyond an application’s current data requirements.

Simplicity vs. Complexity

SAN storage requires storage fabric, host volume access as well as SAN storage system volume configuration changes. Yes, all this has gotten simpler over time, but it still requires host, fabric, and SAN storage updates to glue it all together. NAS systems are considerably easier but still require file systems at the NAS solution to match mount points and share points at the hosts that access them. And iSCSI volumes for SAN or NAS systems are easier to configure than FC volumes but both are complex and require both host and storage system linkages.

Configuring object storage systems is considerably easier. One needs to configure storage servers by downloading/copying object software onto them and then add these nodes to the object storage cluster. This is why there are hundreds of Medium posts on the subject of MinIO - it is simple.

Although SAN/NAS systems operations have gotten considerably easier over the years they still often require training of operators in their GUI and a separate operations group to monitor and manage them. Yes, in some cases, SAN/NAS systems can take advantage of CLIs or APIs. But their APIs are typically an afterthought and may lack some of the functionality available in the GUI or CLI. But the critical fact is they are seldom managed completely using their API and code and couldn’t work well without operator supervision.

Object storage is designed to be managed via API and CLI. They may have a GUI, but this is often just a front end for API calls. There is considerably less to do to manage an object storage system and often it is completely done by code alone.

Objects as Data

There are a few capabilities, unique to objects, which also add to the data-store-like attributes of object storage. For instance, like code repositories, objects support data versioning. This is a capability that when new data overwrites old objects, object storage systems automatically create a new version of the data. After this, both the old and new version of an object can be retrieved, if needed. Older versions can be deleted to free up space where required. Naturally, this can be automated in software like MinIO.

Immutability

Objects are inherently immutable. That is, they can be written once, but read multiple times. We see this used for data that’s needed for e-discovery, compliance (where it must be retained over a specified time period), and for other business mandates. Immutable data can only be expired after which time it’s allowed to be deleted. Prior to expiration, immutable object data cannot be altered.

Security

Moreover, objects offer finer grained data security. Most SAN/NAS storage systems can provide drive encryption (using self-encrypting drives) or volume/file system level encryption. Object storage does this as well, at the bucket level, but an object can also be encrypted with its own key. Doing so for objects within the same bucket, allows each object to be separately protected from all other objects in the bucket and across the entire object storage system.

Cloud Native

Objects are accessed using RESTful, web-based protocols not unlike web pages, using a URL and an object id to address them. SAN and iSCSI volumes are accessed via volume ids and block offsets while NAS files are accessed by NFS mount points or SMB share points and multi-level directory specifications. Objects do come in buckets, but bucket names are embedded in the object URL.

Metadata

Objects also offer user added data attribute specifications or tags. Tags are user defined and an object can have up to ten tags. Users can search for object data using tags and tags can be updated or added anytime an object is changed. SAN storage has no tags associated with volumes (OK, perhaps at the OS storage management level), ditto for iSCSI volumes. And NAS NFS/SMB files have a very limited, “standards defined”, set of metadata that can be associated with a file. And to our knowledge, files can’t be searched directly with this user-defined file metadata.  

And why exactly would you not want to search your data?

Summary

As can be seen above there are attributes of object storage systems which are much more data-store-like than legacy SAN or NAS systems. Moreover, objects themselves, also are significantly higher up the data stack than volumes, blocks, or files.

All that being said, objects just feel a lot more like data than blocks or files. Files come closer to data than volume blocks, but they still lack many data characteristics and appliances still require too much complexity and time to purchase, configure and operate.

What this means is that enterprises can adopt a data-centric architecture with the comfort that they are not sacrificing performance - and are simultaneously enhancing cloud interoperability, application interoperability, security, scalability and simplicity. If that seems like an overwhelming set of advantages - it is, and it is why SAN and NAS are on the decline while object storage is on the rise. Ultimately - this is not about a single trend. SAN/NAS vendors wouldn’t be in a bind if it were. There are multiple trends at play - scale out, software-defined, cloud-native, open source and cost. Collectively, these represent too many fronts on which to fight for SAN/NAS vendors.

Learn for yourself. You can download MinIO here, see the documentation here, watch some amazing videos here or ask questions on Slack here.