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.

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.

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.

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.

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.

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. 

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.

It was simple.