The initial setup was pretty straightforward but we also had very good support from the local A10 team here in the Netherlands. Our headquarters are based in Amsterdam. The A10 Dutch office is just a couple of streets away from us, which also made it easier to work on this together. But having said that, the systems themselves are pretty easy to deploy.

Our initial deployment, back in 2016, happened in what were our six main data centers at the time. The easiest one for us was here in Amsterdam because it's almost next door to our office. The deployment itself, the physical installation and activation of the system, is not really the critical activity. Most of our time was spent integrating the systems with our own administration systems, so that we could deploy automatically. And there was the whole setting of profiles for IP addresses to understand how the detection should work and how the scrubbing should work. That was a bit of a software development effort which took about three months in total. But once that was done and we had all the integration tested, the actual deployment was basically determined by delivery time of the boxes, and that is true now for the deployment to new sites. Once a box is delivered, it's typically up and running in a couple of days.

Our implementation strategy was to make the solution part of our standard architecture for all data center networks. As of now, we have deployed the technology in 20 data centers around the world. Whenever we start a new site, we immediately put in this technology as well to make sure that we protect our customers on that site. And we try to automate the installation as much as possible so that deployment can be done remotely, from the configuration perspective. That way we don't need to send specialists onsite to a remote data center to get it up and running.

The solution's initial setup process is straightforward.

The box was deployed really easily. When we had to do the distributed mitigation, it took some time because we had to work with the aGalaxy and aGalaxy was pretty new for A10. We had to work directly with the engineering. Initial setup was done within a week because it was easy.

If you're just starting to work in a sample environment, what we did the first time, the process can be done really quickly. But, when you want to do something, like engineering or custom configurations, this can take sometimes months.

I'd break the initial setup into two parts. I did not do the network part of the setup, although I know our network team had some issues with the initial setup because of the limitations of the devices at that point in time.

For the network part of the setup, one of the limitations the device used to have, and no longer have, was with BGP. The way we run our environment is that the TPS device is actually a BGP device within our network and it peers with other devices. That's not a common setup that A10 is usually used for. It's normally used in an environment where there are routers to the north and south of the device, so that there's usually another device that you reroute traffic to when there's an attack. But because we wanted to be in an always-on, asymmetric situation, we didn't have that ability. So they had to build it for us.

They also had to build what's called ECMP, which is equal-cost multi-path. It's basically load balancing on the network side. They had to build that in for us as well because that was a requirement for how we were going to build the environment. So there were some growing pains when we first brought it online just to make sure that everything was working. They built it into the product for us and it is now working perfectly fine. It is a standard feature now in the newer versions. They've added the ability to have BGP route-on and route-off as an option. Some teams do use that functionality where they have the two routers and they route on only when there's an attack. In our case, we are always on so we have the ability to turn that functionality off because we don't need it.

From the perspective of defenses through aGalaxy, that's gotten better over time. They've made a lot of enhancements to the product that we've requested to make our lives easier. We are currently running approximately 163 zones in our aGalaxy. Managing that number of zones and IPs can be kind of a daunting task, but they've added a bunch of features in the new versions of aGalaxy to be able to easily do that and onboard new IP addresses in an easier manner.

It took us about six-plus months to deploy. We had our existing solution in place and the new solution was hanging off of that for testing purposes. It was a good six to eight months before we were fully migrated over and we had our devices inline.

Previously we were using a different vendor for our mitigation, which was basically two 10-Gig connections that were shared across a switch stack, with all the devices being inline. That was very susceptible to failure because the traffic was always inline. Part of the new implementation requirements from the network team was that we have the ability to set up BGP, which is how it's set up today. So if for some reason there is an issue with a device, like a TPS, we can always pull the BGP route to that device and route traffic around it. Previously we didn't have that ability, so if there ever was an issue on our hardware stack, it would affect all services.

Setting up Thunder TPS isn't complex, and A10 provided excellent support. My team received pre-provisioned devices and sent them to our offices in Chicago and Toronto. We deployed it with their base configuration and brought the appliances online using their technical support. The whole process took about a month.

The initial setup was very simple. Again, we only use one feature, so the complexities of the setup were pretty much nil. They asked us how much traffic we intend to send to this thing. We spec'ed out the box. They said, "Well, this is the box you want." We did some 15 or 20 minutes configuration of the box and that was it. It was up and live. Everything was done in an afternoon.

The initial setup was pretty straightforward. You set up your routing tables, your interfaces. There was no magic there.

We have two and we had them both up and running within three or four days, meshed with our network. The process was to get it connected to our core internet routers and have it start talking to a third-party software and, after that, start the mitigation processes.

We are currently having some issues with the implementation. I think it is because the partner is not ready for implementation, and it's not that they don't have the experience. So, even though we have some issues right now with implementation, the product is very good.

It is very difficult to do the setup. It needs to be a little bit easier. There are not many resources on the internet for help, and there are also not many people who have knowledge of this product.

Its implementation takes two to three weeks. Two engineers are usually enough.

The initial setup was straightforward. Deployment only took a few hours. The  user training takes at least a day and then the whole site will go up in around a weeks time. It's all web-based so the back ends sometime require us to make changes but overall it's pretty simple and straightforward.

We only require one staff member for maintenance.