“No one ever got fired for buying…” – has been a common refrain of IT managers and procurement teams for decades. It used to be said about IBM. It’s been said about Telstra. And its been said about one particular network hardware company for some time. But there are challengers. I spoke with Juniper Network’s Chief Marketing Officer Michael Marcellin and Kevin Lane, the Senior Infrastructure Engineer at James Cook University about why there’s more than one player in town when it comes to network hardware.
Juniper Networks ran a two-day summit event recently, with one day set aside for channel partners and the other for customers. Marcellin said the company’s market growth has been fuelled by customers looking at cloud solutions and ensuring their workloads are secure.
“You still need infrastructure to whatever cloud environment you see. Companies are either at or moving to a multi-cloud environment. They may have users with Office 3665, developers on AWS and their own internal cloud-like environment,” said Marcellin.
This is where Juniper sees their opportunity, with a more software-centric model that can look across different environments. Interestingly, Marcellin said Juniper Networks has, in many cases, split their software from their hardware. So, you can potentially run Juniper’s network software on other equipment or on Juniper’s hardware. That software can be either purchased and on a traditional maintenance agreement or by subscription.
With the nature of network architecture changing, not just with increasing dependence on the cloud but also with the increasing use of SDN, there is a need for network engineers to update their skills. One of the initiatives Juniper Networks has kicked off is the establishment of their OpenLab facilities. There are eight of these facilities globally with two in Australia, in Melbourne and Sydney.
“This is to address the skills transformation of or customers and partners,” said Marcellin.
As well as providing traditional education services, Juniper runs hackathons and gives customers an opportunity to bring their specific problems in so they can be looked at and resolved with experts on hand. This was done with one very large customer where students and Juniper engineers work for a week on the challenges with the customer’s own engineers.
Lane and his team deliver PaaS to all his internal users. That is challenging as James Cook Univeristy (JCU) as many of the researchers he supports are not at a central campus. With the need to quickly deploy new or faster connections as needs change, Lane was looking for a network solution that was able to adapt.
That meant finding networking gear that could be easily upgraded from 10Mbps to 20Mbps and beyond as the university demanded. Internally, he is running connections as fast as 160Gbps.
“I can do that will the equipment I have in place. All I need to do is change the optics,” said Lane.
Some of the other factors Lane needed to consider were the need for low power consumption, quiet operation and the need for gear to fit into exisiting network cabinets. While many businesses consider their data centre environments closely, Lane said JCU has hundreds of network cabinets, many of which are sitting in people’s offices.
He also noted the need for a simplified UI that allowed his team to see what’s happening across the network easily.
Performance was also crucial. While many companies think about comms at the borders particularly, internal capacity is critical said Lane. Its commonplace for users to move up to a petabyte of data at one time. So, being able to easily augment capacity as needed is critical.
When choosing his network vendor, Lane had to go through a strict process. As a quasi-government entity, he had to follow government purchasing guidelines. But one of the things Lane was particularly interested in was a trash record for innovation. In particulate, he was interested in how various vendors addressed SDN.
But some of the vendors he looked at either didn’t support it or tried to drive him towards their own, proprietary platform.
When it comes to buyer’s remorse, Lane said that lack of hard focus on SDN during the procurement process is something he wishes was different.
“It wasn’t an installation requirement, it was a support requirement,” he said. “I really wish we had taken the time, event though it was very early days, that we had gone SDN from the beginning”.