The SNIA Ethernet Storage Forum is very pleased to announce that the hugely popular “Storage Performance Benchmarking” webcast series continues with a 5^th installment! Join us on February 14^th at 10:00 am PT for “Storage Performance Benchmarking: Workloads.” Benchmarking storage performance is both an art and a science. In this 5^th installment, our experts, Mark Rogov and Chris Conniff, take on optimizing performance for various workloads. Attendees will gain an understanding of workload profiles and their characteristics for common Independent Software Vendor (ISV) applications and learn how to identify application workloads based on I/O profiles to better understand the implications on storage architectures and design patterns. This webcast will cover:

• An introduction to benchmarking storage performance of workloads
• Workload characteristics
• Common Workloads (OLTP, OLAP, VMware, etc.)
• Graph fun!

Did you notice this webcast is on February 14^th? We did that on purpose, because we know you’ll love it! So, register now and spend an hour of your Valentine’s Day with us. We hope to see you there. And if you have not yet had a chance to watch any of our previous “Storage Performance Benchmarking” webcasts, they are all available on-demand.

• Storage Performance Benchmarking: Introduction and Fundamentals
• Storage Performance Benchmarking: Part 2 – Solution under Test
• Storage Performance Benchmarking: Block Components 
• Storage Performance Benchmarking: File Components 

     

It's one of the great IT debates: Fibre Channel (FC) or iSCSI. We at the SNIA Ethernet Storage Forum thought this was this perfect way to kick off the New Year, so we're hosting a live webcast "FC vs. iSCSI" on January 31^st with experts who will not be afraid to highlight differences and compare and contrast these two storage protocols. In the enterprise, block storage typically handles the most critical applications such as database, ERP, product development, and tier-1 virtualization. The dominant connectivity option for this has long been Fibre Channel SAN (FC-SAN), but recently many customers and block storage vendors have turned to iSCSI instead. FC-SAN is known for its reliability, lossless nature, 2x FC speed bumps, and carefully tested interoperability between vendors. iSCSI is known for running on ubiquitous Ethernet networks, 10x Ethernet speed bumps, and supporting commodity networking hardware from many vendors. Because, FCoE also delivers increasing performance as Ethernet speeds increase – and, Fibre Channel also delivers increasing performance as FC speeds increase. Historically, FC delivered speed bumps at a more rapid interval (2x bumps), while Ethernet delivered their speed bumps at a slower pace (10x bumps), but that has changed recently with Ethernet adding 2.5G, 5G, 25G, 40G, and 50G to the traditional 1G, 10G, 100G timeline. As the storage world moves to more flash and other non-volatile memory, more cloud, and more virtualization (or more containers), this debate becomes even more interesting. Attend this webcast to learn:

• Will Fibre Channel or iSCSI deliver faster performance? Does it depend on the workload?
• How is the wire speed race going between FC and iSCSI? Does anyone actually run iSCSI on 100GbE? When will 128Gb Fibre Channel arrive?
• Can any server or storage array actually support more than 32Gb/s or 40Gb/s speeds?
• Do Linux, Windows, or hypervisors have a preference?
• Is one really easier to install and manage, or are they just different?
• How does the new NVMe over Fabrics protocol affect this debate?

I will be moderating this event where storage networking experts Fred Knight (NetApp) and John Kim (Mellanox) will argue in an energetic, yet friendly way about the differences and merits of each. And they will be available to answer your questions on the spot. I encourage you to register today and start off 2018 with this exciting and informative discussion.

It’s one of the great IT debates: Fibre Channel (FC) or iSCSI. We at the SNIA Ethernet Storage Forum thought this was this perfect way to kick off the New Year, so we’re hosting a live webcast “FC vs. iSCSI” on January 31^st with experts who will not be afraid to highlight differences and compare and contrast these two storage protocols. In the enterprise, block storage typically handles the most critical applications such as database, ERP, product development, and tier-1 virtualization. The dominant connectivity option for this has long been Fibre Channel SAN (FC-SAN), but recently many customers and block storage vendors have turned to iSCSI instead. FC-SAN is known for its reliability, lossless nature, 2x FC speed bumps, and carefully tested interoperability between vendors. iSCSI is known for running on ubiquitous Ethernet networks, 10x Ethernet speed bumps, and supporting commodity networking hardware from many vendors. Because, FCoE also delivers increasing performance as Ethernet speeds increase – and, Fibre Channel also delivers increasing performance as FC speeds increase. Historically, FC delivered speed bumps at a more rapid interval (2x bumps), while Ethernet delivered their speed bumps at a slower pace (10x bumps), but that has changed recently with Ethernet adding 2.5G, 5G, 25G, 40G, and 50G to the traditional 1G, 10G, 100G timeline. As the storage world moves to more flash and other non-volatile memory, more cloud, and more virtualization (or more containers), this debate becomes even more interesting. Attend this webcast to learn:

• Will Fibre Channel or iSCSI deliver faster performance? Does it depend on the workload?
• How is the wire speed race going between FC and iSCSI? Does anyone actually run iSCSI on 100GbE? When will 128Gb Fibre Channel arrive?
• Can any server or storage array actually support more than 32Gb/s or 40Gb/s speeds?
• Do Linux, Windows, or hypervisors have a preference?
• Is one really easier to install and manage, or are they just different?
• How does the new NVMe over Fabrics protocol affect this debate?

I will be moderating this event where storage networking experts Fred Knight (NetApp) and John Kim (Mellanox) will argue in an energetic, yet friendly way about the differences and merits of each. And they will be available to answer your questions on the spot. I encourage you to register today and start off 2018 with this exciting and informative discussion.

The SNIA Ethernet Storage Forum (ESF), specifically ESF Vice Chair, Alex McDonald, spent Halloween explaining storage requirements for modern transactions in our webcast, “Transactional Models & Their Storage Requirements.” Starting with the fascinating history of the first transactional system in a bakery in 1951 (really!), to a discussion on Bitcoin, it was an insightful look at the changing role of storage amid modern transactions. If you missed it, you can watch it on-demand at your convenience. We received some great questions during the live event. Here are answers to them all: Q. How many nodes are typical in the blockchain ledger? A. As many as are required to ensure that a single node or small number of nodes can’t crack the hard problem that gives you the right to add your blockchain as the next. There are estimated to be more than 11,000 Bitcoin nodes right now (see https://bitnodes.earn.com/), but not all blockchain systems have as many nodes (or such a hard problem to crack!) Q. A traditional DB like Oracle…how does it fit into CAP? What two features would it have? A. A traditional database doesn’t have an unreliable geographically spread network connecting parts of the database (or at least, it shouldn’t). The CAP theorem (Consistency, Availability & Partition tolerance – pick any two from three) doesn’t apply to traditional databases like Oracle. These kinds of systems provide ACIDity; Wikipedia has an excellent article on the subject. Q. Is block same as node? I thought each node has a copy of each block. A. That’s correct. Ledger transactions and blocks get distributed to all the nodes, and every node has a copy of the entire blockchain. Q. Hey! Bitcoin isn’t just limited to criminals! C’mon! A. Blockchain is more than cryptocurrencies, and is increasingly important for legit businesses too. For instance, just this week American Express Is Getting Into Blockchain-Based Payments With Ripple. Other applications across a broad range are being introduced; in healthcare for instance, for digital identity, smart contracts and digital voting to name a few. Q. Why is blockchain storage different from more regular storage we might have today? A. Let’s take the example of a cryptocurrency like Bitcoin. Blockchain ledgers are transactional in nature. So if I have 200 transactions in my wallet, they are spread across all the blockchains where they are recorded, and there isn’t a central value of what’s in my wallet. To get that, I need to add up all the wallet transactions recorded in every blockchain; and the blockchains can be pretty big. The Bitcoin blockchain is more than 140GB as of November 2017, and growing. That demands fast (both high bandwidth and low latency) storage; in memory as much as possible, with Flash based SSD for persistence. Other blockchain technologies will have equivalent or even more demanding requirements. If you have questions about this topic, please comment on this blog below. And if you’re interested in more vendor-neutral education on storage topics, check out the full library of SNIA ESF webcasts where we cover all thing related to Ethernet storage, including block, file and object storage, RDMA and NVMe over Fabrics, storage performance benchmarking, containers and our very popular 101 series “Everything You Wanted To Know About Storage But Were Too Proud To Ask.” Happy viewing!

In a recent survey of enterprise hybrid cloud users, the Evaluator Group saw that nearly 60% of respondents indicated that lack of interoperability is a significant technology issue that they must overcome in order to move forward. In fact, lack of interoperability was the number one issue, surpassing public cloud security and network security as significant inhibitors. The SNIA Cloud Storage Initiative (CSI) is pleased to have John Webster, Senior Partner at Evaluator Group, who will join us on December 12^th for a live webcast to dive into the findings of their research. In this webcast, Multi-Cloud Storage: Addressing the Need for Portability and Interoperability, my SNIA Cloud colleague, Mark Carlson, and John will discuss enterprise hybrid cloud objectives and barriers to adoption. John and Mark will focus on cloud interoperability within the storage domain and the CSI’s work that promotes interoperability and portability of data stored in the cloud. As moderator of this webcast, I’ll make sure we offer great insights on real-world cloud deployment challenges. As always, we will be available to answer your questions on the spot. I encourage you to register today. We hope to see you on the 12^th.  

In a recent survey of enterprise hybrid cloud users, the Evaluator Group saw that nearly 60% of respondents indicated that lack of interoperability is a significant technology issue that they must overcome in order to move forward. In fact, lack of interoperability was the number one issue, surpassing public cloud security and network security as significant inhibitors.

The SNIA Cloud Storage Initiative (CSI) is pleased to have John Webster, Senior Partner at Evaluator Group, who will join us on December 12^th for a live webcast to dive into the findings of their research. In this webcast, Multi-Cloud Storage: Addressing the Need for Portability and Interoperability, my SNIA Cloud colleague, Mark Carlson, and John will discuss enterprise hybrid cloud objectives and barriers to adoption. John and Mark will focus on cloud interoperability within the storage domain and the CSI’s work that promotes interoperability and portability of data stored in the cloud.

As moderator of this webcast, I’ll make sure we offer great insights on real-world cloud deployment challenges. As always, we will be available to answer your questions on the spot. I encourage you to register today. We hope to see you on the 12^th.

 

  Guest Columnist:  Paul Grun, Advanced Technology Development, Cray, Inc. and Vice-Chair, Open Fabrics Alliance (OFA) Earlier this year, SNIA hosted its one-day Persistent Memory Summit in San Jose; it was my pleasure to be invited to participate by delivering a presentation on behalf of the OpenFabrics Alliance.  Check it out here. The day long Summit program was chock full of deeply technical, detailed information about the state of the art in persistent memory technology coupled with previews of some possible future directions this exciting technology could conceivably take.  The Summit played to a completely packed house, including an auxiliary room equipped with a remote video feed.  Quite the event! But why would the OpenFabrics Alliance (the OFA) be offering a presentation at a Persistent Memory (PM) Summit, you ask?  Fabrics!  Which just happens to be the OFA’s forte. For several years now, SNIA’s NVM Programming Model Technical Working Group (NVMP TWG) has been describing programming models designed to deliver high availability, the primary thesis for which is simply stated – data isn’t truly ‘highly available’ until it is stored persistently in at least two places.  Hence the need to access remote persistent memory via a fabric in a highly efficient, and performant, manner.  And that’s where the OFA comes in. For those unfamiliar with us, the OFA concerns itself with developing open source network software to allow applications to get the most performance possible from the network.  Historically, that has meant that the OFA has developed libraries and kernel modules that conform to the Verbs specification as defined in the InfiniBand Architecture specifications.  Over time, the suite has expanded to include software for derivative specifications such as RoCE (RDMA over Converged Ethernet) and iWARP (RDMA over TCP/IP).  In today’s world, much of the work of maintaining the Verbs API has been assumed by the open source community itself.  Success! Several years ago, the OFA began an effort called the OpenFabrics Interfaces project to define a network API now known as ‘libfabric’.  This API complements the Verbs API; Verbs continues into the foreseeable future as the API of choice for verbs-based fabrics such as InfiniBand.  The idea was that the libfabric API  would be driven mainly by the unique requirements of the consumers of network services.  The result would be networking solutions that are transport independent and that meet the needs of application and middleware developers through a freely available open source API. So, what does all this have to do with persistent memory?  A great deal! By now, we have come to the realization that remote, fabric attached persistent memory, while very much like local memory in many respects, has some unique characteristics.  To state the obvious, it has persistence characteristics akin to those found in classical file systems, but it has the potential to be accessed using fast memory semantics instead of conventional file-based POSIX semantics.  Accomplishing this implies a need for new features exposed to consumers through the API, giving the consumer greater control over the persistence of data written to the remote memory.  Fortunately, the libfabric framework was designed from the outset for flexibility, which should make it straightforward to define the new structures needed to support Persistent Memory accesses over a high performance, switched fabric. My presentation at the Persistent Memory Summit had two main goals; the first was to introduce the OpenFabrics Alliance’s approach to API development.  The second was to begin the discussion of API requirements to support Persistent Memory.  For example, during the talk we drew a distinction between ‘Data Storage’ (what it means to access conventional storage) versus ‘Data Access’ (accessing persistent memory over a fabric).  As the slides in the presentation make clear, these are two very different use cases, and yet the enhanced libfabric API must support both equally well.  At the end of the presentation, we presented some ideas for what a converged I/O stack designed to support both use cases might look like.  Naturally, this is just the beginning of the story. There is much work to do. The work on the libfabric API is now underway in earnest in the OpenFabrics Interfaces Working Group (OFIWG), and as with the original libfabric work, we are beginning with a requirement gathering phase.  We want to be sure that the resulting enhancements to the libfabric API meet the needs of applications accessing remote persistent memory. The OFA is looking forward to their presentation at the next Persistent Memory Summit to be held January 24, 2018 at the Westin in San Jose, CA, where we will provide updates on OFA activities.  Details on the Summit can be found here. Being an open source organization, the OFA welcomes input from all interested parties in our efforts to support the emergence of this exciting new technology.    For more information on how to get involved, please go to the OpenFabrics website (https://openfabrics.org) to find information about regular working group meetings and how you can get involved.  Or, feel free to reach out to me directly for more information – grun@cray.com

  Guest Columnist:  Paul Grun, Advanced Technology Development, Cray, Inc. and Vice-Chair, Open Fabrics Alliance (OFA) Earlier this year, SNIA hosted its one-day Persistent Memory Summit in San Jose; it was my pleasure to be invited to participate by delivering a presentation on behalf of the OpenFabrics Alliance.  Check it out here. The day long Summit program was chock full of deeply technical, detailed information about the state of the art in persistent memory technology coupled with previews of some possible future directions this exciting technology could conceivably take.  The Summit played to a completely packed house, including an auxiliary room equipped with a remote video feed.  Quite the event! But why would the OpenFabrics Alliance (the OFA) be offering a presentation at a Persistent Memory (PM) Summit, you ask?  Fabrics!  Which just happens to be the OFA’s forte. For several years now, SNIA’s NVM Programming Model Technical Working Group (NVMP TWG) has been describing programming models designed to deliver high availability, the primary thesis for which is simply stated – data isn’t truly ‘highly available’ until it is stored persistently in at least two places.  Hence the need to access remote persistent memory via a fabric in a highly efficient, and performant, manner.  And that’s where the OFA comes in. For those unfamiliar with us, the OFA concerns itself with developing open source network software to allow applications to get the most performance possible from the network.  Historically, that has meant that the OFA has developed libraries and kernel modules that conform to the Verbs specification as defined in the InfiniBand Architecture specifications.  Over time, the suite has expanded to include software for derivative specifications such as RoCE (RDMA over Converged Ethernet) and iWARP (RDMA over TCP/IP).  In today’s world, much of the work of maintaining the Verbs API has been assumed by the open source community itself.  Success! Several years ago, the OFA began an effort called the OpenFabrics Interfaces project to define a network API now known as ‘libfabric’.  This API complements the Verbs API; Verbs continues into the foreseeable future as the API of choice for verbs-based fabrics such as InfiniBand.  The idea was that the libfabric API  would be driven mainly by the unique requirements of the consumers of network services.  The result would be networking solutions that are transport independent and that meet the needs of application and middleware developers through a freely available open source API. So, what does all this have to do with persistent memory?  A great deal! By now, we have come to the realization that remote, fabric attached persistent memory, while very much like local memory in many respects, has some unique characteristics.  To state the obvious, it has persistence characteristics akin to those found in classical file systems, but it has the potential to be accessed using fast memory semantics instead of conventional file-based POSIX semantics.  Accomplishing this implies a need for new features exposed to consumers through the API, giving the consumer greater control over the persistence of data written to the remote memory.  Fortunately, the libfabric framework was designed from the outset for flexibility, which should make it straightforward to define the new structures needed to support Persistent Memory accesses over a high performance, switched fabric. My presentation at the Persistent Memory Summit had two main goals; the first was to introduce the OpenFabrics Alliance’s approach to API development.  The second was to begin the discussion of API requirements to support Persistent Memory.  For example, during the talk we drew a distinction between ‘Data Storage’ (what it means to access conventional storage) versus ‘Data Access’ (accessing persistent memory over a fabric).  As the slides in the presentation make clear, these are two very different use cases, and yet the enhanced libfabric API must support both equally well.  At the end of the presentation, we presented some ideas for what a converged I/O stack designed to support both use cases might look like.  Naturally, this is just the beginning of the story. There is much work to do. The work on the libfabric API is now underway in earnest in the OpenFabrics Interfaces Working Group (OFIWG), and as with the original libfabric work, we are beginning with a requirement gathering phase.  We want to be sure that the resulting enhancements to the libfabric API meet the needs of applications accessing remote persistent memory. The OFA is looking forward to their presentation at the next Persistent Memory Summit to be held January 24, 2018 at the Westin in San Jose, CA, where we will provide updates on OFA activities.  Details on the Summit can be found here. Being an open source organization, the OFA welcomes input from all interested parties in our efforts to support the emergence of this exciting new technology.    For more information on how to get involved, please go to the OpenFabrics website (https://openfabrics.org) to find information about regular working group meetings and how you can get involved.  Or, feel free to reach out to me directly for more information – grun@cray.com

The most recent installment of our SNIA ESF webcast series “Everything You Wanted To Know About Storage But Were Too Proud To Ask” took on a broad topic – storage management. Our experts, Richelle Ahlvers, Mark Rogov and Alex McDonald did a great job explaining the basics and have now answered the questions that attendees asked here in this blog. If you missed the live webcast, check it out on-demand and download a copy of the slides if you’d like to take notes.

Q: What is the difference between storage and a database? Could a database be considered storage?

A: The short answer is no. The long answer relies on the fact that a database doesn’t just store data: it modifies the data to fit into its schema (table, index, etc.) A storage solution doesn’t mutate the data in any shape—the data is always preserved as is.

Q: Doesn’t provisioning a storage array mean setting it up?

A: Within the storage community, provisioning is akin to serving a cake at a party. To provision storage to a server means cutting a slice of usable capacity and allocating it to a very specific server. The record of the particular pairing is carefully recorded.

Q: Does deduplication fall into Configuration? Even when it is done only on cold data?

A: Great question! Deduplication is one of the services that a storage array may offer, therefore enabling it is configuring such service. To further clarify your question, the point of deduplication is irrelevant: it may happen with cold data (the data that is stored on the array but applications haven’t accessed it in a long time); it may happen to hot or in-flight data (frequently accessed data or data inside cache).

Q. Do Hyperscale vendors (like AWS) use any of the storage management?

A. Hyperscale vendors, like all consumers of storage, use storage management to configure their storage. They use a combination of vendor device tools and custom development scripts/tools, but are not heavy consumers of industry standard storage interfaces today. Swordfish’s RESTful interface will provide an easy-to-consume API for hyperscale vendors to integrate into their management ecosystem as vendors start delivering Swordfish-based solutions.

Q. It was mentioned that there was a ‘steep learning curve’ for previous SNIA storage management model. Any idea how much easier this is to learn?

A. One of the major advantages for Swordfish is that the RESTful API’s are standardized and can take advantage of readily available tools and infrastructure. With the JSON-based payload, you can use standard plug-ins for browsers, as well as Python scripting languages to immediately interact with the Swordfish API’s. This is a distinct difference from the SMI-S API’s, which although they are also XML-based APIs, required custom or third-party tools to interact with the SMI-S providers.

Q. You talked about how Swordfish is being designed as more user and client centric. How are you doing this?

A. We are starting with very specific use cases and scenarios (rather than looking at “what is all the functionality we could expose”) as we build both the structure of the API and the amount of information returned. We’ve also documented a lot of the basic use cases, and who might like to do them, in a user’s guide, and published that alongside the Swordfish specification. You can find links to this at the SNIA Swordfish page: snia.org/swordfish

Q. You weren’t specific on storage management tools, and I was expecting more detail. I’m wondering why you did this at such a high level, as this really hasn’t helped me.

A. We were primarily referring to ITIL –(The Information Technology Infrastructure Library). It’s a framework designed to standardize the selection, planning, delivery and support of IT services to a business. Learn more here.

Q. While most of the products today support SMI-S, it’s not something that DevOps or Storage Admins use directly. How, or is, Swordfish going to be different?

A. There are two primary ways we see the Swordfish API being much more accessible directly to the individual admins. First, as a RESTful interface, it is very easy to access and traverse with the tools that they use daily – from web browsers directly, to REST plugins, to simple (or complex) python scripts. The learning curve to start interacting with Swordfish is extremely small. You can get a sense by going to an online “mockup” site here: http://swordfishmockups.com – there are some simple instructions to either browse the system directly or some standard clients to make it easier. That will give you an idea of how easy it will be to start interacting with Swordfish (plus security for a real system, of course).

Remember the “Everything You Wanted To Know About Storage But Were Too Proud To Ask” is a series. We’ve covered 8 storage topics to date and have a library of on-demand webcasts you can watch at your convenience. Happy viewing!

The most recent installment of our SNIA ESF webcast series “Everything You Wanted To Know About Storage But Were Too Proud To Ask” took on a broad topic – storage management. Our experts, Richelle Ahlvers, Mark Rogov and Alex McDonald did a great job explaining the basics and have now answered the questions that attendees asked here in this blog. If you missed the live webcast, check it out on-demand and download a copy of the slides if you’d like to take notes.

Q: What is the difference between storage and a database? Could a database be considered storage?

A: The short answer is no. The long answer relies on the fact that a database doesn’t just store data: it modifies the data to fit into its schema (table, index, etc.) A storage solution doesn’t mutate the data in any shape—the data is always preserved as is.

Q: Doesn’t provisioning a storage array mean setting it up?

A: Within the storage community, provisioning is akin to serving a cake at a party. To provision storage to a server means cutting a slice of usable capacity and allocating it to a very specific server. The record of the particular pairing is carefully recorded.

Q: Does deduplication fall into Configuration? Even when it is done only on cold data?

A: Great question! Deduplication is one of the services that a storage array may offer, therefore enabling it is configuring such service. To further clarify your question, the point of deduplication is irrelevant: it may happen with cold data (the data that is stored on the array but applications haven’t accessed it in a long time); it may happen to hot or in-flight data (frequently accessed data or data inside cache).

Q. Do Hyperscale vendors (like AWS) use any of the storage management?

A. Hyperscale vendors, like all consumers of storage, use storage management to configure their storage. They use a combination of vendor device tools and custom development scripts/tools, but are not heavy consumers of industry standard storage interfaces today. Swordfish’s RESTful interface will provide an easy-to-consume API for hyperscale vendors to integrate into their management ecosystem as vendors start delivering Swordfish-based solutions.

Q. It was mentioned that there was a ‘steep learning curve’ for previous SNIA storage management model. Any idea how much easier this is to learn?

A. One of the major advantages for Swordfish is that the RESTful API’s are standardized and can take advantage of readily available tools and infrastructure. With the JSON-based payload, you can use standard plug-ins for browsers, as well as Python scripting languages to immediately interact with the Swordfish API’s. This is a distinct difference from the SMI-S API’s, which although they are also XML-based APIs, required custom or third-party tools to interact with the SMI-S providers.

Q. You talked about how Swordfish is being designed as more user and client centric.  How are you doing this?   

A. We are starting with very specific use cases and scenarios  (rather than looking at “what is all the functionality we could expose”) as we build both the structure of the API and the amount of information returned.   We’ve also documented a lot of the basic use cases, and who might like to do them, in a user’s guide, and published that alongside the Swordfish specification.  You can find links to this at the SNIA Swordfish page: snia.org/swordfish

Q. You weren’t specific on storage management tools, and I was expecting more detail. I’m wondering why you did this at such a high level, as this really hasn’t helped me.

A. We were primarily referring to ITIL –(The Information Technology Infrastructure Library). It’s a framework designed to standardize the selection, planning, delivery and support of IT services to a business. Learn more here.

Q. While most of the products today support SMI-S, it’s not something that DevOps or Storage Admins use directly.  How, or is, Swordfish going to be different?

A. There are two primary ways we see the Swordfish API being much more accessible directly to the individual admins.  First, as a RESTful interface, it is very easy to access and traverse with the tools that they use daily – from web browsers directly, to REST plugins, to simple (or complex) python scripts.  The learning curve to start interacting with Swordfish is extremely small.  You can get a sense by going to an online “mockup” site here:  http://swordfishmockups.com – there are some simple instructions to either browse the system directly or some standard clients to make it easier.  That will give you an idea of how easy it will be to start interacting with Swordfish (plus security for a real system, of course).

Remember the “Everything You Wanted To Know About Storage But Were Too Proud To Ask” is a series. We’ve covered 8 storage topics to date and have a library of on-demand webcasts you can watch at your convenience. Happy viewing!