WinOps 2018: What happened when RiksTV moved all its services to the cloud

Trond Hindenes speaking at WinOps 2018

Over the past few years, the broadcast industry has witnessed rapid transformation as a result of digital technology. Customers are moving from traditional to on-demand forms of content consumption.

This has had a major impact on entertainment companies globally, and RiksTV is a great example. The Norwegian digital terrestrial television network has had to revolutionise the way it delivers services in order to remain relevant.

At WinOps 2018, SRE Lead Trond Hindenes spoke about the company’s cloud and DevOps journey. He also discussed the difference between “click-next” cloud usage and real automation through modern tooling, and getting developers involved in conversations around infrastructure.

Cloud transformation

Hidenes opened his talk with an honest description of the rapidly changing television industry and how his company has been transformed by moving to the cloud. “People want to consume content in a different in a way. Five years ago, our primary product was this old-school, antenna-based product. But that’s not interesting anymore,” he told the audience.

RiksTV knew it needed to move with the times, so it migrated to the cloud and shifted to a streaming business model. The decision has resulted in monthly growth for the company. “We’re in this transition from old-school TV to digital content,” boasted Hindenes.

This has been a gradual undertaking for the company. He explained that in June 2016, it would take 3 weeks to release updates via a manual process. But in October 2017, the company managed to dramatically reduce this to 1-2 days through Ansible.  Later that year, when the first customer facing service was moved to AWS, it was at 2-3 hours. Now that a V2 provisioning model is in place and the API is in the cloud, it is 14 minutes.

Enabling change

What was particularly valuable about Hindenes’ session is that he took the audience through a step-by-step tour of the cloud journey at RiksTV. To make migration seamless, the business had to reverse-engineer years of manual change. It took 12-14 months before everything was successfully saved as configuration code in Ansible.

During the second stage of the project, Hindenes and his team wanted to build a Windows platform framework.  When it came to designing this, they decided that VM images should be generic, that there shouldn’t be any specific configuration stored, that everything should be controlled through VM/instance tags, that clear ownership was required to break monoliths, and that there should be zero residue. They also had to plug existing Ansible code into the VM provisioning process and build microservices for generating VM names and securely storing auto-generated VM credentials.

The third stage saw them split up all of their Ansible roles into build and deploy tools and create a thicker image, resulting in a lighter deployment process and 25-minute reduction in deploy time. Hindenes and co then set up a VLS VM lifecycle service, which provides notifications of new VM images and schedules the replacement of VMs based on a codified rollout plan, and adopted a “kill switch” if something were to go wrong.

Although the cloud transformation at RiksTV is still undergoing, it’s been a great success so far. It was nice to see Hindenes reflect on some of these achievements, namely that the VM provisioning process is robust and it’s no longer an issue to perform replacement operations. Right across the board, failed nodes can be removed quickly, and there’s more optimisation.

Of course, Hindenes and the IT team at RiksTV have learnt a lot along the way. Reflecting on the project so far, he said modern organisations need to build robust systems; trust but verify; integrate with and don’t depend on; if it’s scary, you’re not doing it enough; the “buy vs build” mentality is outdated as we’re all builders now; tooling needs to fit with ephemeral infrastructure; and cloud requires rich automation.

Visit our blog for more WinOps 2018 coverage.

Share this:

Leave a comment

Your email address will not be published. Required fields are marked *

*

View our privacy policy