My grandmother used to make the best chocolate chip cookies, her recipe was unbeatable! I’d love to leave the story there, but one not-so-fine day she thought she’d try a different recipe, just to mix things up. What was she thinking! The new cookies tasted nowhere near as good as her original recipe. Ok, she could’ve spent hours upon hours in the kitchen refining the new recipe, experimenting with ingredients and so on, but what would be the point? She already had a tried-and-tested recipe for choc chip cookies that everyone loves, chocoholic visitors knew exactly what they were getting… so, why change? Fortunately in the end she saw it that way too - the new recipe was ditched and the original one was back in the oven, much to everyone’s delight. So why am I talking about chocolate chip cookies? Well, because a similar scenario arose here at Nutanix not so long ago, but this time the subject wasn’t cookies, but APIs for storage access. Tasty.
At Nutanix we’ve spent a lot of time and energy developing the Nutanix Unified Storage (‘NUS’) platform, which consists of Files, Objects and Volumes. Consequently NUS has evolved into a robust, feature-rich and versatile storage platform, one that’s been adopted by all kinds of organizations across the globe for all sorts of use cases. So it makes complete sense that we should start to leverage NUS - specifically Nutanix Objects Storage - to store images, LCM bundles and other sizeable Prism Central-managed data assets. The scalability, immutability and data lifecycle capabilities delivered by Nutanix Objects, along with its field-proven robustness, make it ideal for the job. Though for this particular use case, much of the usual Objects functionality is not required. Thus, a stripped down version (one that can fit into a compact footprint) was called for and so, Objects Lite was born. What we have, then, is a lightweight yet robust technology that streamlines the storage and retrieval of large files and is tailored for specific use cases like managing VM images and LCM bundles. As it evolves, Objects Lite will expand its scope to serve as a dedicated content repository for various content types, including Docker images and other formats.
Most folks will be unaware that Nutanix Objects (ok ok, Objects Lite) is already powering Prism Central’s data storage needs; it sits largely in the background doing its thing. Indeed, most consumers of Objects Lite are internal Nutanix services, but there are a few scenarios where Objects Lite serves external clients, for example when ISO images are being programmatically uploaded to Prism Central… which brings us back to the question that is the focus of this blog: what client access method should Objects Lite support? The options are twofold:
- Industry standard S3 APIs
- Nutanix v4 APIs
Spoiler alert: the team ruled in favor of the S3 API, but it wasn’t a slam dunk; before making a final decision, the team of course wanted to be clear about the pros and cons of each approach. Let’s look at the thought process behind this decision, starting with the argument for v4 APIs.
The case for v4 APIs
Nutanix has been on something of a mission these past few years, creating a set of standardized APIs across all its products. The benefits of this are API consistency for all things Nutanix, improved security, and a one-stop-shop for all API and related SDK documentation.
So, in the case of Objects Lite, if you wanted to upload an ISO to Prism Central programmatically, you could simply grab the v4 API for that operation at developers.nutanix.com and add it into your script (had we gone down that route).
Consistency across features is a powerful argument; everyone knows where they stand in terms of structure, security and documentation. But there are other considerations that cannot be ignored…
The case for S3 APIs
I don’t think there are too many folks in the IT sector who haven’t heard the term “S3”. Developed by AWS, it describes both their massively popular object storage service (S3: the service) and the methodology for storing and accessing object data (S3: the API). In fact, it’s fair to say the S3 API has emerged as the de facto standard for object storage access with a huge number of applications and just about every object storage vendor supporting it, including Nutanix. Importantly, this means that S3 is:
- Well known within the industry
- Mature and fully featured
- Extensively battle-tested with proven robustness
Extensible SDK Support
One of the most appealing aspects of the S3 API, and one that relates to its maturity, is the extensive support for SDKs across various programming languages. Developers can leverage familiar languages like Python, Java, Node.js, and others to interact with Nutanix Objects Lite. This compatibility reduces the learning curve and accelerates development cycles, ensuring that clients are able to integrate with our service quickly and efficiently. By contrast if we went with the v4 API it would take time to build and test even the basic APIs, let alone SDKs, which would be a much longer term prospect. The bottom line is that low time-to-value is a really big advantage for the S3 API - it makes good sense to avoid the cost and delay incurred by reinventing the wheel.
Scalability
Accessing Objects Lite using SDKs already available for S3 ensures efficient and adept handling of data storage and retrieval at scale. For example, if a very large file is being uploaded to Objects Lite and there is a network interruption, TransferManager for Amazon S3 (part of the AWS SDK) will ensure the upload picks up where it left off once connectivity is reestablished - no need to start uploading the whole thing again. Building and testing similar SDKs around as-yet unwritten v4 APIs for a variety of programming languages is possible, but would take considerable time.
A Well Documented Set of APIs
Thanks to massive ongoing efforts by AWS, the inventors of the S3 API, there is no shortage of documentation for S3. A quick visit to Amazon's S3 API documentation reveals a wealth of clear explanations about what each API (and its accompanying headers) does and how to use it, as well as a multitude of examples to help folks get started. The vast number of examples and explanations, many of which can be found beyond amazonaws.com, are evidence of the S3 API’s widespread adoption. Unquestionably, the extensiveness and richness of the documentation makes it much easier for developers to understand and implement the S3 API (and corresponding SDKs). This, in turn, simplifies integration and ensures consistent behavior across different platforms.
An Open Door to Future Data Management Options
The current implementation of Objects Lite supports two S3 APIs for external clients: PutObject and CreateMultiPartUpload. However, many more S3 APIs exist than just those, and in fact internal services in Prism Central already leverage other APIs with Objects Lite such as lifecycle policy and bucket management, in addition to the aforementioned. Going forward, Objects Lite could easily start to support more APIs with external clients, where it makes sense. Indeed, plans are already afoot at the time of writing to support downloads using pre-signed URLs.
Built-In Security & Integrity Checking
The S3 ‘protocol’ natively supports checksums and integrity checks to ensure (you guessed it) data integrity during uploads and downloads. It also provides a number of security features, not least granular bucket access policies that determine what actions a given user may perform on a given bucket (or its contents). Given the importance of data integrity and access security in the Enterprise, the fact that the S3 API comes with these capabilities fully integrated is a significant advantage.
Does Not Undermine Control Path API Standards
If you take a good look at the various Nutanix v4 APIs that exist across our numerous products, you’ll notice they all relate to management functions, i.e. control path. However, what we’re talking about here are functions relating to the data path. In other words, adopting the S3 API does not represent a deviation from the company’s v4 standard for management APIs, and therefore does not undermine it. Data path is a different class of API, one that has no precedent in the Nutanix v4 API rollout. To further clarify the point, had we opted to use a network-attached filesystem for Prism Central’s large file storage needs, the data path would have been based on a file sharing protocol such as NFS, which of course has nothing to do with control path APIs. Why then would the alternative, object storage access, be treated any differently?
Conclusion
Let’s summarize: why did we choose the S3 API over the v4 API? The fact that it’s a firmly established, feature-rich and widely adopted protocol has a lot to do with it. The S3 API standard is a cornerstone of cloud computing, ensuring compatibility across various platforms and tools. The choice we’ve made simplifies interactions for our clients, as they can utilize existing S3 SDKs without needing to learn a new system, and it’s an approach that quite simply aligns with industry best practices. Kind of a no-brainer, just like my grandmother’s choc-chip cookies.
--/--
This article was baked with the expert assistance of Chef Naveen Gundlagutta from Objects Engineering