Broadcom Service Virtualization Review

We use it to have a highly-available development process because we develop our front end and middleware in tandem with our services teams. When their stuff goes down we don’t want them to cause us a delay on deliverables to the client.

Having a virtual service to rely on, we’re able to continue development even when one of their services fails. They provide built-in data handlers for a variety of different protocols. The REST data protocol auto-parses everything, so you can do analytics. It can flex and provide different responses depending on the request, and is easily measurable and repeatable.

We have issues where one of our dev services goes down, but we still have commitments we have to keep. We’re able to continue development and push for service for our clients even when other aspects fail, instead of causing delays.

Improved Mac support would be an improvement. Also, when things fail, I’d like to see meaningful error messages. A more stable client-side application would be a big thing – their server side application is pretty solid.

It’s pretty good. It’s an Eclipse IDE app, so it’s a little old, and their Mac support isn’t as strong as it could be, but otherwise it’s pretty solid. Once you deploy the virtual services everything just kind of works.

We haven’t really tested it at scale. All of our work has been at the single-team level.

I've just used their community support.

We were the pilot team for the solution. It was fairly straightforward; install a package on a server, start up some services, and go.

It’s provided value. We’ve been able to continue development even when we wouldn’t previously have been able to continue. There’s been a learning curve, some hiccups, and a challenge to train new people on the solution. There is some barrier to entry.