United Cloud and Cisco Solve the ‘In-House or Outsource’ IT Conundrum

A constant battle within any IT department is the choice between building a custom solution in-house or outsourcing it. This dilemma has been pervasive in my work for United Cloud. We have always tried to strike the right balance between internal expertise and leveraging the right partners. But the correct choice is not always the easiest to make.

To understand how we’ve made our decisions, it’s important to understand our journey as a company. We started some 15 years ago as SBB (Serbia Broadband), which was the country’s biggest cable operator. Over the years, we acquired other assets in neighboring countries and have become the United Group. Today, we cover four markets with telecommunications operators in Serbia, Slovenia, Bosnia, and Montenegro. We have the biggest DTH satellite TV platform in the region, and we also have an OTT platform that targets expats from the territory of former Yugoslavia. Dealing with people from all over the world means we need to serve customers from as far away as Canada or Australia.

As we acquired several smaller companies and considerably grew in size, the Group management decided it would be beneficial to establish our own Technology Research and Innovation Center and start developing our own solution. The rationale behind this decision was that we have had several vendors (Cisco included!) within the chain of video delivery, and that chain was very difficult to manage. Changing or implementing anything new was quite a challenge and we could never do it from end to end ourselves. 

Throughout this growth, our cable operator has frequently turned to Cisco for their expertise —including for our eventual transition into the Cisco ACI infrastructure. Everything and anything within the network, from CMTS to backend components (once the digitalization of TV started), has been supported by Cisco. In a way, they have been our strategic partner for the whole lifetime of the company. 

But we hit a turning point where we saw that we had developed substantial know-how in the IT department and we wanted to see how much we could do in-house. That's how our Group Technology Research & Innovation Development Center started - United Cloud was born and our new adventure began.

Growing Pains

United Cloud was tasked with developing a cloud TV platform that would serve all four of United Group telecommunications operators, as well as offer our solution on the open market. Our initial idea was to add more servers to our existing infrastructure, so we would need blades and would need to be connected with fiber interconnects. We looked at project bids from different service providers, but then eventually decided to build everything ourselves, in-house.

But building the solution in-house made our company structure extremely complicated. We essentially turned into companies within a company, with everyone working as separate entities. We ended up with a Technology R&I Development center that didn’t even touch the network. And the division of labor and company hierarchy was quite a challenge to deal with. Our network employees had their own set of tasks, and when we came in to kick-start our cloud TV offering, or even to ask them to change small things or troubleshoot something, it was a distraction for them. 

On the other hand, once we started the project, the data center and SSB (where the whole solution was installed) was a traditional system based on Nexus 752 architecture. We didn't want to move away from that system because we wanted to stretch out that investment for as long as possible. But when we looked deeper into the bandwidth we needed for our massive delivery of video services, it turned out we had to acquire additional modules and cards that came with a forbidding price tag.

We were in a very tricky situation because it was like we were trying to fit an old Volkswagen Beetle with a jet engine: It's doable, but comes with a considerable price tag. We decided in the end to turn to our old partner and base our cloud TV platform on the Cisco UCS architecture, which turned out to be very successful.

Our Winning Horse

We found the solution to our ‘Volkswagen retrofit’ problem in Cisco’s Nexus 9000 architecture with leaf-spine topology. We have a long-standing history with Cisco, going back about a decade. They understand what it’s like to work with our business. We approached Cisco with our new cloud TV project requirements and they returned to us with a Nexus 9K architecture quote that was about ten times cheaper than the price we would have to pay if we wanted to just upgrade our old Nexus 752 architecture. We thought: Why not get something newer and better if it comes at a smaller price? We decided partnering with Cisco—yet again— and upgrading our legacy architecture would be the best way to build our cloud TV business. 

Cisco then approached us with the idea of ACI. Our initial response was no because, again, we wanted to do as much as possible in-house. We simply put the pressure on the network guys in SBB, and they did the work. For the cloud, we do our own automation with a virtualization of the servers using tools like Ansible. But for the network, they just call the network staff in SBB. 

Over time, network-related requirements became very frequent and we found ourselves constantly pushing towards SBB, which they, naturally, didn’t appreciate very much. Eventually, Cisco approached us with the proposal to consider ACI to offload the network employees, since our new architecture already supported ACI. We decided to do some testing, as it looked promising.

The Cisco solution provided a pre-integrated, off-the-shelf solution for fabric automation, which was very attractive for us. Furthermore, when we put things into a broader perspective, our operations are spread across four countries, and there is a good chance they will expand to different markets. Going with a multi-site approach did make the most sense. 

Now, the data center reaches across four countries. Some of the centers are already Nexus 9000 ACI-enabled, and the others will likely be expanded within the same topology when the time comes.

The new Cisco ACI setup would allow United Cloud to freely operate and enable additional capacities in the network without engaging the infrastructure team. In addition, the same infrastructure would be used for the Private Cloud environment, where the ACI can be integrated with existing PCs based on UCS Director, Cisco UCS, and VmWare, allowing enterprises using managed PCs to work on their portion of the infrastructure.

The result is significant time savings and agility. We have a great deal of flexibility in deploying any L2 or L3 connectivity as needed in extremely fast manner. Our goal is to have everything prepared ahead of time to be ready for further growth. This ensures we will add the necessary flexibility to our organization and tear down the fragmentation we had built up. 

Finding the Right Balance

When I look back on our journey between in-house and outsourced, I realize the two can coexist. Some solutions will make sense to build internally with our expertise. But others, while still possible, simply won’t be cost or time effective for us to develop ourselves, and so it makes more sense to use partners like Cisco.

When we decide whether or not to outsource, we need to focus on our strengths. Our core business is TV, not networking. So, if we need to work on the orchestration of the network, it makes sense to turn to a partner like Cisco instead of spreading ourselves thin by trying to reinvent the wheel. We have big aspirations at United Cloud, but it’s reassuring to know we don’t have to do everything on our own.