SwiftStack [EOL] Reviews

We provide archived documentation in Canada. We use it to manage servers for object storage. It is a console that helps you configure OpenStack Swift. We have eight OpenStack Swift servers, and we use SwiftStack to manage them.

It is on-premises. We have one VM on one of our servers, and then we use it to configure all other nodes.

It makes my work easier. 

The graphs are most valuable. They have a lot of graphs and reports that you can run to see what's happening in the background to configure OpenStack Swift. 

It is a very well-done solution. I have no issues with it. It is well-explained, and configuration is easy with it.

It's very well done for what it's supposed to do, and I don't have anything to add, but I would like them to keep it available to the public. SwiftStack is going out of the market. NVIDIA purchased SwiftStack a couple of years ago, and they won't be making it available to the public anymore. Our license is up to March 31st.

It is reliable. Everything works fine.

It is very easy to scale. Installing SwiftStack on every node is easy.

Its users include me and my backup. I need to support it every day, but I don't use it every day. 

The developers use the SwiftStack Client to connect to the storage, which is also easy to deploy. Our main purpose as an organization is to provide archived documents. They're testing the platform every day. I'm assuming that in one way or another, they use it every week.

We have the basic support because we're not a HA business. We don't need high availability. The system can be down for a couple of hours or days.

They're very knowledgeable, and they respond very quickly. We didn't have any problems with them.

We always used SwiftStack. When we implemented OpenStack Swift, it was done with SwiftStack. We haven't used any other solution, and we haven't replaced any other solution to use SwiftStack.

It's pretty straightforward. I didn't set it up originally. I haven't installed the console itself. When you deploy OpenStack, you might configure a node with it. Installing the client on every node is super easy and very well-documented. 

I'm the sole system admin here. I have a backup, but I'm the main system admin. If I'm not available, he takes care of it, but I'm the one who is maintaining it every day.

It's pricey for us because we're a nonprofit. I'm not privy to any amount or cost, but I have been told that it is pricey.

There are no costs in addition to the licensing fees, and it seems to come with the support.

Don't use it because it will go off the market in three months. It won't be available. NVIDIA purchased the whole company and made it private so that they can use SwiftStack internally for their AI stuff.

I would rate it a nine out of 10. I'm very saddened that we won't have access to SwiftStack because of how useful it was.

We have a number of use cases. The most important one is that we run a data-sharing service for Dutch universities and higher education and research institutes. The service is used to share research data. It's based on cloud software which uses the object store as a storage backend. That is our most important user. 

We have another user from Leiden University, which has the most data in it. They have a few very huge electron microscopes. They do research with them and distribute the data through SwiftStack to their customers.

It's all in the nonprofit sphere.

We do have archives, but for a lot of use cases people cannot deal with the latency that comes with such storage. What we needed, and what a number of our users needed, was some kind of storage solution based on disk, to get rid of the latency. But at the same time, it had to be a very secure storage system to store data. That gap is now filled by SwiftStack.

The solution has also enabled us to store more data with same number of staff. At the moment, we store something like 300 to 400 terabytes.

It has also decreased our cost of storing and utilizing data. It depends a bit because at Surfsara we have different storage systems with different characteristics used for different purposes. It's very hard to make a comparison. But when I look at SwiftStack versus our other storage systems and the amount of manpower they take, that is where we win. For other big storage clusters, we need something like one-and-a-half or two FTEs to maintain them. With SwiftStack, we can get by with 0.1 or 0.2 FTEs.

The most valuable feature is its versatility. We use 1space and we can use it for almost anything: for our cloud service, for backups of VMs. You can use it for almost anything. That's something we like very much.

We have a storage policy where we have three copies of the data. We migrate that data to another storage policy and we use the 1space feature for that. I very much doubt that the developers envisioned that use case when they developed it but it does work.

When working with petabytes of data, we find that data can be ingested and accessed at a fast rate.

SwiftStack is also quite flexible when it comes to hardware. It depends, of course, on the use case and the kind of hardware you want to buy. But you have quite a bit of choice in hardware. The SwiftStack software itself does not impose anything on you.

At the moment we are using Erasure coding in an 8+4 setting. What would be nice is if, for some standard configurations like 15+4 and 8+4, there were more versatility so we could, for example, select 8+6, or the like.

It's a rock.

Up until now, we have not encountered any scalability issues.

As we go, there are more and more people interested. It's steadily growing. In the Netherlands, there is an organization called NWO which is similar to the National Science Foundation. The NWO has departments that are all about research and data management, and they have a solution for that. They are also interested in using SwiftStack as a storage backup.

We have between 50 and 60 SwiftStack users. Because we are an academic computer center providing services to universities, a lot of those people are not within our company, but are working at universities. There are researchers, professors, etc. Within our company, Surfsara itself is mainly used for backups. Those are accounts that are not really attached to people but which are attached to a service.

SwiftStack's technical support gets an A+. They're really, really good. Every time we ask them a question, they are very quick in responding. They provide very valid and good responses. I don't see any room for improvement there.

We didn't have a previous solution. 

I had read about the solution and was very interested in it because, as I mentioned before, we were looking for some kind of all-around, online disk storage solution. At the same time, we saw an increasing interest in people wanting to use storage which supported the S3 protocol. That's how we ended up with SwiftStack.

The initial setup was pretty straightforward. At first, I just installed it on my laptop in the VM. I am a group leader so later on, one of my admins set it up in a small cluster. It was up and running in no time. It was not complex. I've seen a lot worse.

The deployment took about a day, and we're talking about something like a 35-node cluster. That included everything, things such as OS's and network, etc.

Installing it takes no time, but then you have to set up your whole management environment. Of course, the SwiftStack Controller itself controls the SwiftStack-related stuff. But then there are OS upgrades and the configuration of the nodes. You have to set up things like Ansible to manage your clusters. SwiftStack has its own monitoring, but apart from that, we also use Zabbix and we had to set up the monitoring. 

First, we got everything to work and then we set up the whole environment that comes along with it. We also had to set up an accounting system, so we know what user X or user Y uses in terms of the number of objects and the number of data stores. Those are all the things that come later on.

As for deployment and maintenance of SwiftStack, we require almost no staff. The deployment takes some work, to set up the monitoring, etc. We run it together with Keystone and Keystone has a database server that needs to be backed up. So the setup takes some work, but once it's actually running, it's very close to zero people for maintenance. In our budget it's about 0.1 FTE. It takes very little effort to run the system.

We deployed it by ourselves.

We find the pricing rather steep. Of course, you get quality for your money, that's absolutely true. But I do get questions about it from my management. When you look at the prices of the licensing and the prices of your hardware, it's quite substantial.

At Surfsara we already had several different storage solutions. In that sense, we did do a comparison because we were already running some of the competitive solutions in-house. For one service, we run Scality for object-based storage. And our cloud has a big Ceph cluster. The supercomputer storage cluster is based on Lustre.

I would absolutely recommend SwiftStack. The quality is really good, the stability is fantastic. It requires very little manpower.

The performance of SwiftStack is adequate. It does the job.

In terms of 1space helping move applications to the public cloud or to use resources in the public cloud for on-prem data, we have not used it at all for that. But I would not rule out our using it for that purpose at some point in the future.

The primary use case is general purpose object storage for preproduction types of test and development. We use it in research, development, test, and evaluations (RDT&E) for software development.

We are using it for the backup and recovery and object storage. We use the Swift and NFS. We have a NAS gateway such as Avere in front of it. So, it is multipurpose. I would like to use it for more direct NFS, if that feature does become available.

We are able to dynamically grow storage at a lower cost. We can repurpose hardware and buy commodity hardware. There is a huge cost savings, on average $100,000 a year compared to traditional storage for what we have at our size.

The SwiftStack Controller, which is the web UI, provides out of band management. This has been one of the best features of it. It allows us to be able to do upgrades and look at performance metrics. It is a top feature and reason to choose the product.

The file access needs improvement. The NFS was rolled out as a single service. It needs to be fully integrated into the proxy in a highly available fashion, like the regular proxy access is. I know it's on the roadmap.

With some of the hierarchy, old management storage policies, I would like to be able to move data between different types of storage policies. One of the things that has come up before was being able to do distributed erasure coding. Right now, erasure coding is only supported locally redundant. Products, like Scality, support the ability using multiple rings to do erasure coding that's globally redundant.

I have been using the product since 2015.

The hardware stability is independent of SwiftStack. However, the way the durability is configured, it is quite impressive. We have had three years of 100 percent uptime on the system. 

SwiftStack is able to offer a level of availability beyond using basic hardware. We don't need special-purpose hardware in order to achieve that level of availability.

The performance is limited to what our hardware is, so the software performs as expected. I have not found any reason to believe that the software has had any performance limitations.

I have a storage administrator who manages SwiftStack. I know we are on the latest version.

It easily scales. We have about 500 users with the majority being software and systems engineers.

We are at a half of one petabyte range. We do find that data can be ingested and accessed a fast rate.

If you were to do gigabyte per person, we can store more data per person than we used to with traditional storage by at least 200 percent.

The technical support is pretty good. I haven't had any issues with the support. We have had some challenges sending certain types of information because of they outsource support to other countries. 24-hour US-only support would probably be my recommendation as room for improvement. Other than that, the support that we do get has been really good.

The outsourced support has been helpful. We have been limited in what we can send, but in one case, they were able to allow us to recover our data quickly.

It was the first object storage product that we ever installed. We had more traditional storage, like a NetApp or a Dell-type solution with a traditional NAS or SAN. 

This was our first object storage solution. We decided to move to it because of the cost savings associated with having unstructured data being stored on deep, dense storage than using commodity hardware. Even when you look at the traditional filer, there's a lot more cost that goes into it. It's less flexible. So it was really to provide that flexibility of what you get in an Amazon or Microsoft Cloud to be able to run that on-premise.

They have made improvements to the product since we first initially installed it. Previously, it didn't have a packaged installer. However, they've since done a packaged installer of the Controller. Beyond that, it's pretty nice because the Controller handles the installation. Relative to some of the other software that we have done of this nature, it was easier.

The initial Controller install was probably the most complex part. Once you got that going, getting it onto individual nodes was straightforward.

Our deployment took a day or two. We deployed it as quickly as possible, then figured it out as we went along. It was an initial proof of concept that we just rolled out into production.

We repurposed existing servers for our initial deployment of SwiftStack, then for our expansion, we bought new servers. It was a positive benefit for scalability, flexibility, and cost savings. This was a primary reason that we chose the product. It had a lower cost of entry versus comparable solutions. We could repurpose hardware at a small capacity license, then we were able to incrementally grow, which saved us a lot of money over the years.

We had SwiftStack engineers onsite for a day or two. They worked alongside a few other engineers and myself to do the install. Our experience with them was great.

It requires about half the time of a FTE (systems administrator) a year to manage and maintain it. We do have engineers who might come in if there are high priority issues, configurations, etc. However, the average cost equivalent is probably a thousand hours a year, and that might be on the upper end.

Dollar per gigabyte, it costs us more because we are storing more. However, if you look at it from a cost per gigabyte perspective, we have dropped our costs significantly.

The pricing model is great and makes sense. We have talked about how to get into more of a frequent billing cycle than once a year. That would be an interesting concept to add into the product, having the ability to have monthly billing instead of having to do a one-year licensing renewal. However, the way the license works by charging for storage consumed is definitely what makes them the most competitive.

We have looked at IBM Cleversafe, which is now IBM Cloud Object Storage. 

We had discussions about Scality and Cloudian. 

We looked at NetApp StorageGRID Webscale, which was the vendor who we were considering since NetApp has a large presence in the government space and we wanted to look at something familiar. 

We had a history of working with the Dell EMC ECS product, which was originally called Atmos, then ViPR. We didn't buy the hardware appliance. We bought the software only. The hardware being used is our Dell hardware. 

We talked about Ceph because they do have object storage interfaces, but decided not to go with them for lack of product maturity.

Looking at these vendors gave us some metrics to compare against. The primary reason for going with SwiftStack was the low cost of entry. They had comparable features to other vendors, but won out on price.

Give it consideration. A lot of people don't know about it or how it works. The biggest advice: You don't require OpenStack to run SwiftStack. That is the biggest product confusion issue that SwiftStack has to deal with that you can deploy them independent of OpenStack. A lot of customers may think that because it's based on OpenStack, you will need this complex OpenStack deployment, which is not true.

Right now, it's a backup storage system, so it's used as a backup repository. We point our Commvault backups to it and soon to be Veeam backups.

It has helped us with the ability to distribute data to different data centers. As part of our DR strategy, we have nodes automatically replicating data from one data center to the other. This makes it easier for us to not have to shift tapes around or do anything else like that. 

We have seen a tremendous increase in the amount of data that is being produced, but at the same point in time, we haven't needed to increase our head count to manage this backup storage. We have seen eight times more data without having to increase the head count to manage the solution.

In theory, we could stop using SwiftStack tomorrow and still have the solution up and running. It would just be up to us to manage and maintain it. However, their solution makes it a lot easier to manage the OpenStack Swift environment, so we don't have to have a dedicated resource who knows the ins and outs and nuances of OpenStack Swift. SwiftStack makes it easier to use this solution.

• You can bring your own drives, which don't have to be certified. This usually means that they cost significantly more to insert a certified drive with the manufacturer who is selling you your solution. 
• It is platform independent, so you bring your own hardware. It doesn't matter if you get a Dell EMC, HPE, IBM, etc. Its hardware agnostic capabilities are great. Dell EMC, HPE, and Lenovo are obviously big players, but sometimes they don't have the best prices. You are not tied to any one particular vendor, and it gives you great flexibility as far as pricing is concerned. You can go out, and say, "Give me the most capacity in the smallest number of use spaces." Sometimes that's not the big vendors, it's the small vendors who provide this.
• The forward thinking in their cloud solution creates a global namespace across the major public clouds. It allows you to go from on-premise to the cloud seamlessly. They have made it easier to move data between the different cloud vendors and move those flows from on-premise to the cloud, then from the cloud back to on-premise. That freedom that they facilitate is hard to put a price on, because it gives you flexibility.
• The metadata search capabilities are something that we look forward to being able to use, though we haven't fully had a chance to get into them. However, in the life sciences area, it could be tremendously beneficial. 
• Ease of operation: We got it up and running, and it's been solid. We can upgrade the capacity of our drives at any point in time.
• The flexibility that the solution provides, both for hardware and on-premise, then to the cloud. That flexibility is great.

On the controller features, there needs to be a bit more clean up of the user interface. There are a lot of options available on the GUI which might be better organized or compartmentalized. There are times when you are going through the user interface and you have to look around for where the setting may be. A little bit more attention to the organization of the user interface would be helpful.

They should provide a more concise hardware calculator when you're putting your capacity together.

The stability has been great.

We have seen good performance. Right now, we are somewhat hamstrung by the network that we're on. It's the data center and network that we're on at the moment. We have been happy with SwiftStack's performance, but there's probably more upside that we're not seeing yet.

As long as the stability is there on the platform, it allows us to compete the hardware vendors against each other because it doesn't all have to be homogeneous. E.g., maybe Dell has a great system this year and we have a Dell EMC system, but then next year, we find out that Super Micro has the best bang for the buck. Now, we have Dell EMC and Super Micro in the same cluster providing resources. That it doesn't have to be an all in one brand vendor is a tremendous benefit.

The scalability has been fantastic.

We are not quite at the petabyte range yet. We're just barely under one petabyte. The ingestion is not an issue. Thus far, because it's primarily a backup target, the ingest has been fine. We haven't had any significant restores that need to be done. The general consensus on what we've done is that the restores coming back from it have been faster than they were from our prior vendor. Ingest speeds are fine. The restore speeds have improved.

It is backing up enterprise systems in our data center. Those enterprise systems are being used by close to 600 staff, both administrative and scientific. That staff doesn't directly interact with SwiftStack, but the data that they store is on our primary storage system and gets backed up to it. Indirectly, they're being covered by the capacity on the SwiftStack system.

We are kicking the tires on the SwiftStack 1space feature right now. We're trying to determine the namespace that we'd want to use. Because we're in a transitional period, we're looking at increasing our capacity. We're going to bring on two new SwiftStack nodes with additional capacities. Part of that will be the 1space with the ability to move out to Azure and AWS, who right now are our two primary cloud providers. However, GCP will also likely be involved. Therefore, we're in the process of formulating a long-term plan that won't require us to re-architect after we get out and running.

Our use case for the 1space feature is cold archives and the ability to move some of the data out of our on-premise data centers because of federal mandates for data center consolidation initiatives. It puts more emphasis on shrinking space in the data center, which means denser, greater storage capacity on-premise, but then some of that data needs to move out to the cloud.

The possibility is also there for doing some bursting to the cloud for a cloud compute. This is a future desire that we would like to look into, though it is not on our official roadmap. The transition to public cloud hasn't even been tied in yet.

Going forward, we will be adding two nodes. We are still waiting on the hard drives. Once they are added, we will be expanding our capacity by 70 percent.

Their tech support has been great. They are responsive, answer questions, very knowledgeable, and have been willing to jump on calls with the backup software vendor to assist in troubleshooting with any type of issue that we've run into with our backup (Commvault). Their support staff has jumped on and lent their expertise to the Commvault staff, explaining or helping to troubleshoot why Commvault was having issues.

We did use a different solution. We switched because of cost and scalability. The initial purchase price, ongoing support, and maintenance costs, also coupled with the difficulty in scaling made it almost a no-brainer for us to move off of them.

The initial setup was pretty straightforward. Their support staff was there to walk us through the setup and explain things along the way. When we did run across anything that wasn't clear, they were right there to clear it up. From that respect, the setup was made significantly easier because we were able to work with their support staff. They were able to remote in and assist with any questions or configurations that we might have otherwise had trouble with.

We had two data centers and needed the data to replicate between the two data centers. Therefore, we purchased two storage nodes. One for each data center with a controller satellite and the secondary data center to control both of them. Data essentially replicated from our primary data center to the secondary data center.

Our setup really was extended by our own availability. It didn't take more than two weeks, but it was an hour and a half here and an hour there. The initial setup was done in a day (overall time). In under 48 hours, we were able to have it up and running and fairly optimized.

It doesn't even require a full-time staff to maintain it. It requires someone keeping tabs on it, but we don't need a full-time storage admin to keep the system up and running. After the initial deployment, it runs. We just keep an eye on it. Since it's essentially redundant, we've got the two nodes, and they're replicating. It doesn't require a ton of staff to stand up and maintain.

We used a reseller, Alliance Technology. They did an initial install and configuration of the system drives on the storage nodes.

There were some issues in their setup, and whoever configured it didn't set the system volume up as a RAID 1 mirror for high availability. However, their pricing and recommendation of the hardware was very good.

We were happy with them, with the exception of the misconfiguration. We did run into an issue with the initial quote. For our initial implementation, they had only one storage node and we needed two. So, we had to go back and address that. Then, it also didn't include the optical transceivers that we needed for the 10G connections, but we were able to work with the reseller and get those shipped out. These were minor inconveniences in the procurement process. That was the initial delivery. Alliance did not assist with the deployment from then on. 

We worked directly with SwiftStack and their support team once the equipment was in-house and went into production with it

The annual support and maintenance costs compared to our old solution for backups had about a two-thirds savings, so about a 60% annual savings on our support and maintenance contract. That savings funded additional expansion for what it was costing us for the support and maintenance contracts on old solution. We bought an additional node. It also saved us on not having to do forklift upgrades, or rip and replace upgrades. Rather than having to do those, we could purchase an additional node and add higher capacity drives, which is something that other backup vendors weren't certifying.

This gives us annual savings on the support and maintenance contract, but also savings on our time and efforts. We don't have to do a disruptive rip and replace, moving everything over. We can add a node, migrate the capacity, and elegantly decommission a node if we choose to do so. If it's no longer supported or if there's hardware issues, we can migrate the data and do it in a non-disruptive fashion.

We have had a 40 to 50 percent reduction in CAPEX on the acquisition of new hardware, which is probably conservative.

We didn't repurpose existing servers. While it was an option on the table, we had the money within our budget to buy new hardware because of 60 percent or more savings that we had because we didn't have to maintain the support and maintenance of our old systems.

We bought new hardware which provided better capacity and density. Then, this year we did the same thing because we've had several years of savings, so we bought new hardware. This is on the storage nodes. 

We did actually repurpose the controller. The controller didn't need to be physical. It could have been virtual. At the time, our virtual infrastructure was a little overextended. We had a physical system which was capable of hosting the controller side of things. So, we did repurpose hardware for the controller. However, for the storage systems, because capacity and density are such an important part of what we were doing going forward, we bought chassis geared more towards getting as much capacity in as small amount of space as possible.

There is no vendor lock-in. The ongoing support and maintenance costs are not through the roof like some vendors, especially those that specialize in backup appliances. So, they're very economical in regards to their ongoing support and maintenance. 

The pricing and licensing are capacity-based, so it's hard to put my finger on them, because so many different vendors charge in different ways. We are still saving significantly over any of the other options that we evaluated because we can choose the best hardware at the best price, then put SwiftStack software on it. So, it's hard to complain, even though a part of me goes, "It would be nicer if it were less expensive."

We sort of reevaluated the use of our Spectra Logic tape library. We also reevaluated the Data Domain that we had been using. We looked at a couple other object storage solutions at the time which were Cleversafe and DDN.

At the time, these solutions were more expensive and seemed to follow a similar pattern of providing appliances that would then lock you in. Thus, you were beholden to the manufacturer to deliver an upgraded hardware box, and you still had to buy their certified drives. E.g., even though it was going from a dedupe appliance to an object storage system, you were almost going from a dedupe appliance to an object store appliance, which had its own vendor lock-in.

We wanted the capability to be able to add capacity and drives without having to pay a markup for them, and be able to look at the best bang for the buck across all the vendors. So, we knew that we were going to lose that flexibility if we went with DDN or Cleversafe, because they were selling the entire box, whereas SwiftStack is agnostic. They don't care what the box is underneath. As long as it's an x86 compatible system, you could mix and match. This was one of the deciding factors that hardware-agnostic approach. At the end of the day, if we wanted to, we could basically take SwiftStack out of the picture, and we would still continue to function. They just facilitate making the management of the system easier. You could do it without them. It would be a lot more difficult and require a lot more time, effort, and energy, or someone who knows the technology.

We chose SwiftStack over NetApp or Dell EMC because it is hardware agnostic and the initial capital expenditure was significantly less. Also, the ongoing support and maintenance were significantly less. The flexibility and the ability to scale faster because we weren't tied to any one particular vendor's certification of specific hardware or specific hard drives was another driver.

Know your use cases and how you plan on utilizing it. As part of that use case, understand the flow of your data and how you want that to look. If you're going to send it out to the cloud, understanding that is an important part of an evaluation. Some of the competition out there send you to their cloud, and they're trying to commoditize or potentially lock you in.

The biggest thing about SwiftStack is freedom. It's freedom from vendor lock-in. It's freedom from one cloud provider. It's freedom to scale when you want, how you want, and when you want. Look at how easy or how painful is it to perform upgrades. How long do you have to wait for the manufacturer or the vendor to provide a new chassis or certify new hard drives? Depending on how big a pain point that is within your organization, and depending on what your budgets look like, those are all things to take into consideration when you're looking at the SwiftStack solution.

You need to have somebody who understands Linux, and that's not uncommon in the data center. However, if you're a Windows only shop and only have Windows admins, then that's something to take into consideration. But, if you have a Linux admin, even a junior admin, you can deploy this solution with the help of their support team and be perfectly happy. Look at what you have and how easy or painful is the upgrade process, the initial purchase price, the ongoing support maintenance price, and the innovation. How quickly can you bring the latest and greatest into your solution?

If you start hitting pain points on any of those, SwiftStack gives you the capability to get past some of those obstacles, because you're not tied down waiting for the vendor to innovate or deliver certification on hardware that's been out for six months. It provides us a lot of freedom.

SwiftStack has their finger on the pulse of the storage industry. They are doing a good job of understanding that there's a significant portion of people who don't want vendor lock-in. They look at what is in the best interest of the customer.

Object storage for a SaaS platform is our primary use case. We host a SaaS platform and we use this as our back-end storage.

I don't think it has improved the way the organization functions. It just delivers a better cost point. We can sell storage more cheaply by utilizing this product and it gives us resilience. It gives us the ability to deliver a better SLA to our customers.

In addition, SwiftStack has decreased our cost for storing and utilizing data, definitely by half. Our evaluation versus using Amazon S3 showed we're certainly cutting our costs in half.

The most valuable features are its 

• resiliency
• deployment cost.

The resiliency gives us uptime that is better than what we're able to deliver with competing products.

I would like to see better client integrations, support for a broader client library. SwiftStack could be a little bit more involved in the client side: Python, Java, C, etc. We don't have a lot of issues, but if we do, we don't really get any support from them at all. It's not really in their business model, but it would be easier to integrate if they supported the clients a little bit better.

I don't think we've had any downtime since we brought it up a couple of years ago.

The scalability is phenomenal. It seems infinite, as long as you put enough storage in place, add enough nodes. We've scale-tested it in Amazon to meet any kind of needs we want, as long as we keep up with the hardware.

Their technical support is really good. We haven't had any issues with them. Our cases are few and far between. We've opened up fewer than five cases the whole time. Mostly we've just used them for questions and general information, but not for anything specific where there's an issue. Their response time is within a day.

I have used different solutions in the past, but only ever open-source, never anything commercial.

This organization was using open-source Swift prior. We switched to SwiftStack when we began selling it to customers. We switched to the commercial version in case we need support, but we really haven't needed any support.

The initial setup was very straightforward. We didn't repurpose any existing servers for our initial SwiftStack deployment.

We used the open-source version first to become familiar with it. When we purchased the SwiftStack version, the installation was pretty easy because we already knew the fundamentals of it, through OpenStack. 

The initial deployment, until was fully operational and integrated with our environment, took about two weeks. The deployment took one person, an operations engineer. He also maintains it on a day-to-day basis.

We did not use a third-party.

One area we have seen return on investment is our SLA, being able to offer a better SLA to our customers. That's definitely an advantage in the market.

Other than the standard licensing fees, you need to have the hardware.

The only question we had was staying with open-source or buying the commercial version.

My advice would be to get familiar with the open-source product first because it is more difficult to use but it gives you better fundamentals on how the actual system works. Then, when you do purchase SwiftStack, you'll be pretty much at an expert level. I'm not sure if I would be as comfortable with it by just outright purchasing it and not knowing the internals. You really get to know the internals by using the open-source version first.

The team at SwiftStack has been really good to work with. Everyone from the support folks to the product engineers - and we've even been working with the development teams - they've been really knowledgeable, have really understood our business. Even inbound, the salespeople have really known what we need to get out of it.

In terms of the performance, it's definitely meeting our needs. You have to build to the use case for it. It's definitely the slowest storage subsystem in our environment, but we don't put any high I/O workloads on it. When working with petabytes of data, we find that data can be ingested and accessed at a fast-enough rate. Of all the platforms we have, it's definitely the slowest, but if you build a use case around it knowing that upfront, you can work around it.

Our headcount hasn't changed by using this solution. At the end of the day, our people are maintaining the hardware. SwiftStack doesn't create any overhead. It's more the actual hardware where we put in the most work.

In our organization we do not have named users using it. We're a SaaS platform, so it's the customers using it, not us. They're in the hundreds of thousands.

We plan to increase usage. It's our go-forward platform for object storage, so any place that we have a need for object storage we're using it. We're expanding at about 50 percent per year and the scalability means there's no problem dealing with that.

I would rate SwiftStack at eight out of ten. What comes to mind with that rating are the price and higher-availability.

We are a data center operator and service provider. We deliver cloud storage as a service solution to other customers. So, it's a multitenant cloud service solution, like Amazon S3 or Azure Blob Service. Therefore, cloud storage is our use case.

Our customers are getting file volumes, storage volumes, or object containers from us. They put data on them and manage them on our portal.

We are using the current version of the product.

We launched a product. We don't use it internally for our own use. We deliver it as a service to other customers. The impact on our business was that we launched a new product which has allowed us to generate additional revenue for our business with it.

We repurposed existing servers for our initial deployment of this solution. This allowed us to save because we didn't have to buy new hardware for one of our initial deployments. That was a nice feature. We were able to buy because of the wide range of hardware that they support. We're able to buy affordable type of white box hardware (commodity, efficient hardware) that drives our cost down.

It helps you store more data with less head count. Today, we are storing about eight petabytes of raw capacity.

• The scalability: The ability to scale the platform to very large capacities, while remaining manageable. 
• You can do file and object in the same platform using their proxyFS capability.
• We have had good technical and operational support, which has been an important factor for us.
• The hardware is flexible. They provide a wide range of options.

• The biggest room for improvement is the maturity of the proxyFS solution. That piece of code is relatively new, so most of our issues have been around the proxyFS. 
• Having the full feature set and the management APIs available, there is a lot of room for improvement there. 
• The code upgrade process at scale, managing code upgrades at large scale. 

So far, stability has been good. We haven't really had any major stability issues.

The performance is good. It is a secondary storage platform designed for archive and backup, so performance for the right use cases is very good. We have been pretty happy in that regard.

We found scalability to be good. The platform is capable of scaling to very large capacities. Overall, manageability at scale is pretty good. There are areas that they are continuing to improve, like code upgrades, which are needed to take it to super large scale. However, compared to most solutions, scalability is pretty high for very large multitenant capacity requirements.

We maintain the platform with less than five people. They predominantly are just cloud engineers. This doesn't count people who touch the platform peripherally, like network engineers.

Our customers' users number in the hundreds.

We have about 35 servers in our environment today. We are getting ready to go to between 40 and 50 servers in our environment.

The technical support is good. I would rate it as a nine out of ten.

We switched to SwiftStack due to technical problems with the previous company.

The initial setup was moderate in terms of complexity. From a scale of one to ten (with ten being complex), it was probably about a six to seven. Getting the network designs, selecting the right hardware, and building a cluster with a lot of roles and servers involved. Each of those has roles on it that have to be clearly defined on a per server basis. Also, getting user management clearly defined and set up. It's a pretty lengthy process where you need their help getting it set up initially. It is not an easy self-install process.

For our clients, we give them accounts on an existing platform. This happens very quickly, in a matter of hours. We don't do a lot of custom configuration on a per customer basis for our product.

We used SwiftStack consultants for our initial deployment, but not for individual customer accounts that are turned out. Our experience using the consultants for this was good.

For our overall cluster deployment, we use SwiftStack consultants. 

We launched this product last year. It is too early for us to quantify ROI.

One of their advantages of being a commercial open source platform is, for the scale that they offer, the pricing is pretty competitive.

We also evaluated Scality and Cohesity.

It helped us to decrease our costs for storing and utilizing data. This was based on a comparative basis versus other choices that we considered.

It is a really good object storage. I would be careful about use cases around proxyFS, because it's a less mature, earlier stage component. It is a good platform, as long as it's a technical fit. The support is very good, and that is an important criteria for choosing it. 

When working with petabytes of data, we find that data can be ingested and accessed at a fast rate. We are able to ingest on a per client basis, typically at about 100 to 250 megabytes a second.

We are growing it every month. We continue to sell customers on the service and continue to build new data centers where we're deploying it. So, we do plan to continue expanding its capacity.

We have two use cases. The primary one is a backup target for our backup software and we also use it for archiving off of our primary storage.

The biggest impact, which really doesn't get noticed until you need it, is in our data protection environment. Up until we utilized SwiftStack, we were spinning physical tapes. We now have a disaster recovery facility at a co-lo, and our SwiftStack cluster extends to that disaster recovery location. Because it's a backup target, all of our data gets replicated to our offsite facility automatically. 

It has enabled us to store more data with a smaller headcount. We had 50 tapes and managing tapes can be interesting at best. You have to know where they are, you have to keep them in an environment where they don't degrade rapidly. You have to have a person who's dedicated to really managing where the tapes are and what's on the tapes, how they get written, how they get copied, and how they get recovered if you have to recover data, which is huge. That whole process - and we're a fairly small environment - was half to three-quarters of an FTE engineer. That is a person we can now use somewhere else because the data just goes into SwiftStack and it automatically goes to our offsite facility. We don't have any spinning tapes. We don't have to worry about buying tapes. We don't have to worry about tape attrition. All the management around that really went away. The data protection software actually does the management. It's all automated. It has saved us a lot of time.

Another area where it has helped is that we're not expanding our primary storage like we would have had to, since we're leveraging the lower-cost SwiftStack storage system. Enterprise storage requires another, say, half of an engineer at some level, to manage it, keep the storage correct, move things around. I manage our enterprise storage and it can take a considerable amount of time out of my day. I log into the SwiftStack just to look at how much I'm using and see if I have reached capacity yet. I might look and say, "Oh, look, I have a couple of drives that failed. I'll get to those in a couple weeks." Whereas, with my enterprise storage it's, "Oh no, I have a drive failed. I have to fix it today." It reduces the amount of overhead.

The other way it's added value to our workflows is the data archiving, where we take data off our primary storage and put it into our object store, SwiftStack. It is much easier to manage from a growth and maintenance standpoint, which again, saves time and therefore money.

In terms of the hardware flexibility, with SwiftStack not being a hardware company, I literally buy any hardware that's the least expensive, from any vendor. When I have hard drive failures, I usually wait, and then, once a month, I'll go to Amazon or NewEgg and look at the drive with the lowest storage cost per terabyte. Currently, 10 TB drives seem to be the least expensive per terabyte. I'll just buy that drive and swap them all out once a month. I let hardware fail and then I'll replace it with a larger-capacity drive. Over time, it increases my capacity as well over my overhead. So from a flexibility standpoint, I think it's fantastic. I can go to anybody, anywhere - any vendor - and get my hardware.

There was a large cost saving over using our primary storage, which is our traditional enterprise NAS. We used a single supplier for our hardware but we always look around when we do new. The ability to grow, both vertically and horizontally, because of the SwiftStack deployment model, is so easy that we really don't even think about it. We, literally say, "Hey, we need to get more storage. Do we need capacity or do we need performance?" Performance really hasn't been an issue, so in some cases, we may just buy SaaS JBOD shelves and hang them off our existing servers, which we've done once already. Or we might buy lower-performing servers with a lot of storage slots and add nodes across our cluster. That saved us quite a bit of money.

I can't say exactly how much it has decreased our cost of storing and utilizing data, and the big reason is that data growth doesn't stop. But I know it's less expensive. With our enterprise storage, to get the same level of protection that I get with SwiftStack out of the box, I might have to pay for my initial storage, then whatever protection level they have - whatever RAID level - and then I'll have to buy two or three software packages on top of that to do the mirroring and data protection at that level. And then, I might actually have to use more backup software licenses to back up that data as well. By the time that all adds up, we would probably be at the $4,000 per terabyte level. I know what my backup software costs, and it's outrageous, per terabyte. Whereas, with SwiftStack, I'm $500 or less per terabyte. Done. All in. Those numbers are general numbers. They're not accurate by any stretch of the imagination. But they are pretty close to the level of difference between the two.

The biggest feature, the biggest reason we went with SwiftStack, rather than deploying our own model with OpenStack Swift, was their deployment model. That was really the primary point in our purchase decision, back when we initially deployed. It took my installation time from days to hours, for deployment in our environment, versus deploying OpenStack Swift ourselves, manually. Since then, there has been a lot of value-add that we've gotten out of it with the SwiftStack Gateway and ProxyFS, and the Metadata Search that they've added over the years.

It performs much better than I expected. We have a fairly large capacity network that supports our SwiftStack hardware. So performance, for us, has really never been a large issue. As a backup target, which is probably the one place that it would matter, our max ingest rate is about 2 TB per hour, which is more than adequate for our needs.

When I started, SwiftStack was just a deployment model for OpenStack Swift. It did what it needed to do. There may have been some room for refinement procedurally in how to do certain management tasks.

Over the years with ProxyFS, I don't know where the improvement would lie - whether it lies with SwiftStack or other vendors - but, in general, we need a model where more third-party companies support REST APIs, open REST APIs into object stores such as OpenStack Swift. I really don't see any great strides being taken to do so. There are a few, but a lot of them do the big players, like Amazon S3, and not the open-source players.

The other thing that I've been looking for, for years as an end user and customer, for any object store, including SwiftStack, is some type of automated method for data archiving. Something where you would have a metadata tagging policy engine and a data mover all built into a single system that would automatically be able to take your data off your primary and put it into an object store in a non-proprietary way - which is key. A lot of them say they do it, but they do it with their own proprietary wrappers and then, if you don't have their system sitting in front of it, you can't access your data anymore. I think SwiftStack, with its value-add, that's where they're going. If they do that, they have a storage system that would kill all the others.

When we first deployed, we had a few issues. SwiftStack is based on OpenStack Swift, and this is where I love the SwiftStack support. There were, initially, some bugs in the code, and I would work with their support staff, literally all night long, and within two days we'd have a code fix. So we did have some stability issues early on, two-plus years ago. Over the past couple years, there have not been a lot of stability issues at all, and that includes my doing really silly things with the deployment; either a mistake in configuration or doing something that, on paper, seemed right but wasn't. Even that was so easy to recover from.

I've never lost any data at all through any of it. We've had nodes go offline. We've had some pretty crazy stuff happen, and I'm extremely impressed. We've never lost any of it.

As far as I'm concerned, the scalability is endless. Scalability is not an issue. I don't even think about it. If I need capacity, I purchase the stack license, purchase my hardware, and off we go.

Their support staff is second to none. They're the best support staff I've ever worked with, with any vendor of any caliber, in the past 20 years. That includes day-to-day support and help with setup issues I've had. I hold them up as the model for every other vendor, and that includes big, corporate enterprise vendors which have support that is absolutely horrible these days. And I've been doing this for 30 years. SwiftStack has just been a pleasure.

At a previous employer I had experience with Amplidata, Core System, and DDN WOS. The way we got to SwiftStack is that I came from a medical facility where they did research into genomics, Big Data. We were leveraging object stores there for data archiving, and to have less expensive, long-term storage for large amounts of data.

When I came onboard here in 2014, I looked at their needs and said, "Hey, they have the same exact problem, just on a smaller scale. And that's how it started. I proposed it, brought it in as a backup target first, and that worked so well that we started extending it into data archiving.

For us, the initial setup would be complex. We have two regions, and we have two zones in one and one zone in another. The most complicated part of our configuration is the network connectivity to our disaster recovery site and having enough bandwidth to that site. We've been pretty lucky that we have pretty good bandwidth to our disaster recovery site.

In general, I don't think it's more complex than any other solution, and probably less so than a lot of these, "converged, hyperconverged, super-duper-converged," computational clusters that are being built now.

Once we had the hardware and everything was in place, the initial deployment took me a day, and that was with nine nodes and three zones. We started out with a petabyte of storage, initially, raw, and, the deployment was literally a day. It took a very short period of time.

Long-term, we had always intended to have offsite. When we first deployed it, we decided to keep everything at our one site and get some learning done with it, all in one data center. When we first deployed, what helped reduce the time it took was that everything was in the data center. We had all the networking right there within two or three racks of each other. It was quite easy to deploy the nodes. That was always our strategy.

When we first deployed it, it was intended to be a backup target. It took us quite a while to work with our backup vendor to get them to support it properly so we could use it. It was not the fault of SwiftStack. In fact, they helped out considerably in working with the data protection vendor to help them support the object.

Once that was done, it was pretty much just leveraging the system. We've always had that model of: first do it onsite, then do it offsite. It was always going to be primarily for backup and then, eventually, move into archives. We're currently doing more and more archive. Right now, half of the capacity is as a backup target and the other half of the capacity is for data archives, digital assets.

We needed one person for the deployment: me. We're a really small shop, and that may be why it didn't take me long to deploy, because I'm also the network guy, the primary storage guy, the enterprise compute guy. I didn't have anyone else to get things done. I did everything. Of course, I had people help me rack and stack, and help me cable, etc. But the actual deployment is literally so easy that it's really a couple of mouse clicks. And it's just me for maintenance.

We didn't involve any third-parties. SwiftStack itself helped us out immensely.

The ROI is both monetary and in time. The only way it could get any cheaper would be if we stopped generating data.

That's really the bottom line to all this. Until people stop generating data that we have to store somewhere, we're going to be paying money. It's just how best to utilize the money we're spending on it. My opinion is that using SwiftStack is a good way.

All in, with hardware and everything else - and I hate to say a dollar amount because it's been awhile since I computed it - I know I'm under the $300 to $500 per terabyte mark. I call that my "all in" price, which has replications built in and protections built in. It's not like you're spending that dollar amount on enterprise storage, and then you have to buy some software for replication, and buy other software to do mirroring, and other software to actually back up that data in case your storage itself dies.

The costs of enterprise storage add up when you look at everything you need to run it. With SwiftStack, I can use a whole data center in my current deployment model. The price per terabyte that we pay for the SwiftStack software doesn't seem all that much to me right now. It may in the future, but right now, it doesn't.

You don't need the fanciest hardware out there but you need enterprise-grade equipment. The real important thing is to map out the connectivity of all your nodes and know how the data gets traversed so you don't create bottlenecks in your network, in your data transfer; communication between the nodes, front-end communication. Those are really the two big things. Everything else is pretty straightforward once you have your configuration down and your network path down. Everything else is really relatively easy.

I buy SwiftStack storage, generally. Actually, that's all I've bought in the past two years. Primary storage stays pretty constant. I've actually reduced the amount of primary storage by 20 terabytes over the past two months. That's really how we're trying to do our storage. We'll buy SwiftStack and reduce the amount of primary storage, the amount we keep up at our primary level, and just buy the archive storage. Honestly, 70 to 80 percent of the storage we have is unstructured data that we don't need to access more than once or twice a year.

We do not currently use the 1space feature. That is on my roadmap to get deployed. We really don't have a big "cloud strategy". We don't use off-prem storage. All of our storage is on-prem at the moment.

As for working with petabytes of data, most of the bottlenecks for ingest aren't at the SwiftStack layer, they're, generally at the application layer, or depend on the method you're using to ingest it and how threaded it is. Going back to the example of our backup software, where I see the metrics all the time, at a rate of 2 TB an hour, I'm really CPU-bound by the systems that are pushing the data into SwiftStack. If I had more nodes to send data into SwiftStack... It's not a SwiftStack bottleneck. It's on the end-user space or in computation on the client side more than the SwiftStack side.

I don't think SwiftStack has enabled us to store more data than we did before. The reason is that part of the license that you get is the deduplication part. In our backup target, we deduplicate the data or it goes into the object store. In that regard, it's probably a wash. For the archive data, there's no deduplication, but the idea is that the cost is so low that it's also a wash, or we come out a little better. Would it allow you to store more? I'd say it's break-even. At the end of the day, it's cheaper so I can add storage. The cost of putting storage there, even with the larger amount going into it, is still cheaper than our enterprise storage. You're really bound by either drive capacity or data center space.

Initially, in my test environment, I used some older servers that we had kicking around which we were in the process of retiring. Those particular servers - it sounds silly - really weren't conducive to SwiftStack because they had a lot of features that actually prohibited easy maintenance. You really do want no RAID controllers or anything else. We quickly learned that the least expensive servers were absolutely the best servers to have for SwiftStack. During the first month or so, we used old hardware that we had kicking around. Then, when we decided that this is definitely something we want to pursue, we bought enough for what would be all on-premises, all on a single site, and then we deployed production in that. Later, we got out disaster recovery facility and we literally moved one set of nodes to our DR site. That all happened transparently to end users. It just worked. They didn't notice anything going on during that time.

We have about ten physical users of the solution. The video editing guys are big users because we wanted to get their data archived first since they're the biggest utilizers of our enterprise storage. Our marketing department has a huge amount of digital assets: catalog images, web images. Those are probably the two biggest. Then, our IT, because of the backup target, as we do all of the protection of our enterprise system as well, with Oracle Databases.

• Management control
• Deployment

• Management of clusters is easy
• Simple to reduce the man hours needed for a deployment
• Control
• Troubleshooting.

Management UI can be improved and have more functionalities.

I've used it for approximately one-and-a-half years.

No issues encountered.

No issues encountered.

No issues encountered.

I'm satisfied.

I'm satisfied.

It was simple.

• S3
• Google
• Azure