I started at VQ Communications in March and although I’d previously experienced working with a global technology company I was excited to join a company where there is a focus on ‘big’. For our conferencing management software, this means staying ahead of our clients who already have some of the largest deployments of video and audio conferencing, based on the CMS platform. This focus on scale has both tactical and strategic implications for UX.

UX needs to use design patterns for filtering, sorting and searching that are resilient to large volumes of meeting and calls data. Scale creates challenges that are usually only revealed when talking to users. For example, users often leave the default call name, making auto-complete search tricky when there are hundreds of calls all called ‘New Call’. Email search patterns provided a useful starting place for the challenges of volume searches.

One client now makes approximately one million minutes of video and audio conference calls a day. Volume on this size is exciting for UX as it means finding new ways to reveal the most important aspects of the data so that operators, can view both correct and meaningful data they require to monitor and support growing amounts of calls– quite a challenge. Acano Manager 2.0 had already introduced the idea of Dashboards and Analytics long before I joined. So now it’s interesting to start to think about some daily monitoring tools that support user goals moving from managing individual meetings to monitoring hundreds or even thousands of meetings.

What’s next? Well, I’ve barely scratched the surface in understanding the UX challenges and opportunities that ‘big’ brings. But I’m excited about pushing the boundaries of what’s possible with conference management. More from me again in the coming months as I continue on this exciting UX journey.

If you’re technically minded and interested in the path to big, read our CEO’s blog ‘The path to big’, where he talks about how we use Microsoft’s open source software platform to increase the resilience of the Acano Manager software.

Hi, Mike from VQ again.

I thought you might be interested in some of the things that have been going on here at VQ Towers (a wildly amusing reference to the fact we’re not in any form of skyscraper or exotic business park. Our office home is infact a 2 storey building and we occupy the top floor). It’s actually a very pleasant office; spacious and light although at the rate we’re adding people, not spacious for very long. We recently commissioned VQ.Sofa@realtimeconnect.com which, as the name suggests, connects into a system enabling us to make calls from the office sofa.

Here’s a picture taken of (most) of the team a couple of weeks back…

We’re located about 90 minutes west of London in a fantastic part of the country; plenty of green fields, open spaces and small market towns. Nearby we have Bath and Bristol which provide plenty of big city things to do. Great bars and restaurants. One of my favorites is the Bordeaux Quay on the harborside in Bristol – http://www.bordeaux-quay.co.uk/brasserie.php. I found this site which sums up harborside nicely: http://www.heatheronhertravels.com/10-things-to-do-in-bristol-harbour/. London is an easy 90 minutes away so all the goodies it offers are near enough to be used but far enough away to keep us sane.

Back to business, the big thing that is simply staggering is the rate at which users are adopting CMS based services. One of our biggest customers is now doing 1 million call minutes a day and growing at something like 20% per month. The customer did 350,000 calls in February. We’re seeing 3300+ participants in calls concurrently on this system.

This is absolutely fantastic because it tells us that the users like the services that CMS delivers. The old days of having to convince users to use video calls are long gone; the platforms are delivering services that delight users and they consume enormous quantities of them.

The customer referenced above is running an 8 node cluster; another big one ramping is at 10 nodes currently with an upgrade to 15 scheduled. One of the big activities for Acano Manager (AM) 2.3 was extended load testing. We spent the backend of last year developing a test tool we call the ‘virtual Call Bridge’ or ‘vCB’. It allows us to test large call volumes on a single CMS server by wrapping the CMS server with some Nancy magic and then simulating the CDR traffic generated by real calls. The current test pattern cycles around 2000 participants joining CoSpaces and then as soon as everybody is in call, we shut all the calls down and then repeat. This cycle repeats about every 120 seconds.

The vCB testing of AM 2.3 yielded some interesting results.  We were able to induce a problem in one of the key queues within AM that writes commands to the call bridge; this, over time, would backlog up as AM tried to optimize commands and performance went out the window as we spent most of the time optimizing the queue. We were able to fix that in the gap between RC1 and the final release of AM 2.3. Another issue struck at about 800,000 calls; it turned out to be nothing to do with the number of calls and was, in fact, a function of the number of commands the test tool had issued to AM’s API. It crashed AM’s web server which handles the API requests.  With these resolved, the latest batch of tests saw us getting to 10,000,000 calls on a 15 node cluster. The test stopped because we’d reached the test limit. We reset that to 20,000,000, have restarted the tests and should see results in about a week.

In addition to the vCB tests, we have banks of servers running against real CMS and Acano Bridges; we have approximately 80 call bridges at the moment being used for development and testing.

The plan now is to do a relatively quick turn for AM 2.3 MR1 where we plan to fix the problem introduced with CMS 2.1 when the validation rules changed on blank PINs. MR1 will also include new functionality giving more control of Call IDs during the LDAP import process.

Moving past AM 2.3 and 2.3 MR1, we’re working on AM 2.4. The 2.4 work started about 5 months ago with the objective of enabling AM to work as a distributed cluster of nodes. We’re looking for another massive hike in performance and the ability to support large numbers of users signed into the portal. It will also be resilient. 2.4 is at test parity with 2.3 which is great news and a testament to the automated test infrastructure we’ve put into place to grind every build that’s produced. Expect to see more details on 2.4 over the next couple of weeks as we start to get data that we can share. It looks incredibly exciting.

Wrapped in with all of that, the work we did for AM 2.2 has become a case study for Microsoft. We’ll be writing more on the significance of the move to .Net Core very shortly.

Please feel free to drop me a line if you’d like to talk thru aspects of Acano Manager or what we’re doing. It’s always great to talk to customers or people interested in what we’re doing.

Regards

Mike

ISE 2017 redux – it’s the cloud stupid!

OK so nothing surprising then (!) It’s all about delivering services via the cloud and the subscription revenue model.

Let’s recognise the show for what it is though, the UC section is a tiny portion of the RAI facility with the key areas taken up by the increasingly bright screens and projectors.

Call me jaded, but walking past yet another curved display – isn’t this just like 3D TV – a solution looking for a problem to solve? And all those displays started to believe you would need to wear sunglasses to use them.

Hall 11 of the show was packed with companies talking about, and providing evidence that the cloud is now the major delivery mechanism for customers to connect. A smattering of black boxes and end points – a 4k Endpoint for $200’s! But mainly lots of 42” monitors proudly showing impressive network topologies.

Cisco dominated the event with a huge stand, and pride of place was the Sparkboard. It was also great however to see Videxio, AVISPL and Starleaf alongside Pexip investing in the event.

It was also good to see the Lifesize Alumni Simon Dudley, Jon Tracey, Andreas Weinold and Mike McCarthy at the show with the new briefs.

 

 

 

 

 

 

So that leads me to why go to ISE?

Like InfoComm, and a lesser degree Enterprise Connect, with one flight you can have 20 meetings. It becomes a magnet for scheduled, and walk up meetings. In a day and a half I squeezed in three scheduled formal meetings, and numerous “catch ups” with partners, customers and industry influencers.

Next stop, for me, Enterprise Connect at the end of March. No doubt I will meet the Lifesize boys again!

Giles Adams

Selenium Grid combined with Docker is a simple but powerful solution to getting Selenium based infrastructure up and running quickly and easily.

Rather than dealing with the hassle of manually configuring and installing Selenium Grid we decided to go with Docker, it’s quicker and easier to use.

Our Selenium grid is used heavily for Protractor testing and to run our Jasmine unit tests on a constant cycle making sure we don’t introduce issues into our product.

The docker selenium image repositories are located at:

https://github.com/SeleniumHQ/docker-selenium

It includes instructions on how to get the containers up and running, which is great as it’s 1 docker run comamnd per container and you are up and running.

However, let’s take this further and combine it with docker compose to make using it even easier to use.

This compose file is designed to:

1. Pull down the required images from docker hub for you.
2. Allow easy create, start, stop and destroying the grid.
3. Do the hard work of joining the containers together in a docker network (docker link is deprecated).
4. Easily scale the number of Chrome or FireFox nodes.

version: '2'

services:
    selenium_hub:
        image: selenium/hub:3.0.1-aluminum
        container_name: selenium_hub
        privileged: true
        ports:
            - 4444:4444
        environment:
            - GRID_TIMEOUT=120000
            - GRID_BROWSER_TIMEOUT=120000
        networks:
            - selenium_grid_internal

    nodechrome:
        image: selenium/node-chrome-debug:3.0.1-aluminum
        privileged: true
        depends_on:
            - selenium_hub
        ports:
            - 5900
        environment:
            - no_proxy=localhost
            - TZ=Europe/London
            - HUB_PORT_4444_TCP_ADDR=selenium_hub
            - HUB_PORT_4444_TCP_PORT=4444
        networks:
            - selenium_grid_internal

    nodefirefox:
        image: selenium/node-firefox-debug:3.0.1-aluminum
        privileged: true
        depends_on:
            - selenium_hub
        ports:
            - 5900
        environment:
            - no_proxy=localhost
            - TZ=Europe/London
            - HUB_PORT_4444_TCP_ADDR=selenium_hub
            - HUB_PORT_4444_TCP_PORT=4444
        networks:
            - selenium_grid_internal

networks:
    selenium_grid_internal:

To use this docker compose file you could issue commands like:

docker-compose up -d to bring up the 3 containers and run as a background process.

However, @Yantrio, our Linux magician, a while ago came up with the idea of using Makefiles to help simplify the commands.

https://www.yantr.io/post/docker-makefiles/

Take this Makefile:

NODECHROME=5
NODEFIREFOX=1

.PHONY: default up down start stop scale

default: up

up:
    docker-compose up -d
    docker-compose scale nodechrome=$(NODECHROME) nodefirefox=$(NODEFIREFOX)

down:
    docker-compose down

start:
    docker-compose start

stop:
    docker-compose stop

# Have to restart hub due to it trying to connect to destroyed nodes
scale:
    docker-compose scale nodechrome=$(NODECHROME) nodefirefox=$(NODEFIREFOX)
    docker restart selenium_hub

It abstracts away having to remember to say put -d on the up compose command to run as a background process.

You simply can do:

make up to create and start all the containers

make down to stop and remove all the containers

make stop to just stop the containers

make start to just start the containers

But, the key win is how to scale the selenium grid.

You simply call:

make scale NODECHROME=10 NODEFIREFOX=5

To bring up another 5 Chrome containers and another 4 FireFox containers.

As docker compose will see you already have 5 Chrome containers and scale up to the requested 10 containers by making another 5.

Scaling down your grid is as simple as lowering the number of containers you require.

As the comment suggests, we restart the hub container to get around network connection timeout issues when containers disappear.

Simples!