The scalability is fine. One of the concerns in running in AWS — and AWS costs you — is that you don't have any control. As long as you keep an eye on the AWS costs for that ShieldX server, you don't get any fits from AWS costs.

As threats evolve and ShieldX evolves with it, it's like you've got a forever-evolving beast and the solution is evolving to meet the threats. It updates itself automatically to tackle those threats, which is why it's such an easy and lightweight product to manage. It really does everything for itself.

The scalability seems good, so far. I haven't rolled it out that much, but I don't think it should be that difficult. Everything seems like it is scalable to what I need, though we haven't rolled it out to that many servers yet. I don't see it being a problem.

We plan to do more soon. We want to implement this 100 percent in our environment, which is not large. Right now, we are at 50 percent. This will probably be done in the next two months, before summer.

My boss and I are the two people in the organization who are using the solution.

There are two parts to the scalability. 

The first part is that for virtual firewall-types of platforms, virtual security controls, and virtual microsegmentation controls, they scale better than anyone in the industry. The key differentiator there is that they've implemented what they refer to as microservices. In a traditional, virtual firewall - a Palo Alto, Check Point, or Fortinet-type of firewall - if you virtualize it, in the event you need more capacity, you're just adding CPUs to the firewall as a whole. ShieldX has taken every single service that is required to protect workloads and instantiated them as individual services that can individually scale.

That's really important because if, for example, SSL decryption - which is one of the most CPU-intensive functions - needs additional horsepower, we can provide CPUs just to SSL decryption, without having to provide CPUs to an entire monolithic firewall. That's really key to ShieldX's story and there's no one else in the industry that does that. I can scale horizontally as far as I can imagine. As long as I've got the CPU resources, I can continue to scale it. 

The second part is the downside. Compared to a traditional firewall, which isn't really a fair comparison, you're not taking advantage of ASICs. You don't have hardware-based firewall processing. You're dependent upon standard Intel CPUs, and that's where we want ShieldX to get more efficient in how they're using those CPUs so that we're using less of them.

We have about 2,000 servers currently protected. We will continue to grow. It's in the heart of our data center, so as we grow our data center, the ShieldX environment grows along with it.

Scalability is the key here. We feel that scalability is better than what we had with our prior vendor. We're in the process now of scaling this out though the infrastructure. Based on what we've done so far, the migrations looks very solid both in terms of its resource utilization, deployment capabilities, and licensing costs. All of these are very positive, and we expect this to continue through our deployment.

Right now, we are protecting about 1000 users with the infrastructure on the enterprise side. We have somewhere around 20 million active users as we are beginning the process of protecting on the customer services side. All of this is being maintained by two to three people. With my prior vendor, we were looking at about eight or more people working with the vendor to protect at the same sort of scale. Basically, we're doing more with less and fewer people.

We have three people working on deployment and maintenance right now. We have a senior designer and two individuals working on the configuration and operations of ShieldX. We also have a ShieldX employee who does our architectural design.