At NAB, Cinegy announced the initial launch of "Cinegy as a Service". All of Cinegy’s software technology, starting with Cinegy Air, will eventually be ported to run via cloud-based services such as Amazon Web Services (AWS), enabling prospective users to spin up and test drive Cinegy technology in an HD or 4K cloud. No hardware required.
The topics covered in this post include:
The term 'cloud' can mean a lot of different things.
Depending on whether you ask a developer, a system administrator or a CTO, you will get a different response about what the cloud means and what it can do for them.
For now, let’s just think of the cloud as a collection of technologies.
Things such as:
Web or HTTP technologies
Subscription based access to software
All of these have one thing in common: you access them via the Internet, and they are therefore remote to wherever you are.
What are the service models?
IaaS or Infrastructure as a Service is the least abstracted model of Cloud computing, and usually consists of virtual machines using a particular operating system or systems living on shared hardware. These are still deployed and managed by you (examples include Amazon EC2 platform and Facebook games such as Farmville so they can scale as user numbers increase).
PaaS or Platform as a Service represents a scalable application server abstraction, such as Microsoft’s IIS or Tomcat, with no consideration for the underlying hardware, operating system, and storage layers managed by the provider. It provides elasticity to control resources based on demand (examples include Amazon Beanstalk and Microsoft Azure Cloud Services).
SaaS or Software as a Service is abstracted further, from both infrastructure and platform, providing an endpoint to retrieve or submit information. SaaS exposes an application or API with complete abstraction from underlying technologies (examples include: Amazon S3, Google Docs, Salesforce (CRM)). This is an application delivery model which enables users to access an application over the Internet and is usually based on a subscription of a monthly or annual fee.
– The hardware is someone else’s problem, you just make sure you chose the suitably sized VM and then configure it how you want. This isn’t as true as it could be, and we’ll cover some of the challenges later.
– Like with electricity or gas, you pay only for what you use but you need to be aware of all the charges that are associated with what features you are using.
– Investment when you need it, not up front, so you can spread your costs and respond to demand changes more easily, as Lewis mentioned the way in which funds are available is changing and this could help with dealing with that.
– The cloud vendor can provide hardware resiliency and data protection. You can spread your deployments geographically.
– Only paying for what you need with no need to factor in for hardware refresh cycles or datacenter upgrades, etc.
– No ordering new hardware and waiting 3 weeks for HP or Dell to deliver the wrong server. You just start up a VM and then start working on the software deployment.
– With the IaaS model you retain control of the servers, so you can install what you want on them.
– Option to outsource upgrade and maintenance if you wish.
With the new version of our Cinegy License Service, which can be made available to anyone who wants to use it, we can now support licenses for VMs running in AWS.
Some options are:
Add extra capacity as required for infrequent or onetime events such as elections, the world cup, the Olympics, etc.
You really want to try out that shiny new beta version of the software to see what Lewis has broken now but can’t risk any of your production boxes to do it.
You are planning your move to version 11 and want to test out the upgrade process for your database or you want to test the various Cinegy components against your current database.
You can have some pre-configured VMs sat in the cloud that you can spin up and use if you have a catastrophic hardware failure of parts of your Cinegy system. This means you don’t need to have spare servers sat in a rack using up space and depreciating in value.
Currently we are using the AWS platform to host the cloud based machines as they were the only ones to offer GPU based instances for deployment which is required for Cinegy software.
However, the Microsoft Azure platform has recently partnered with NVIDIA to offer Tesla and GRID GPU backed VMs. So it will be interesting to see what impact this has on the marketplace, and we will be keeping an eye on their developments.
Having said that, what have we found to be the current challenges to deploying on AWS?
Hardware refresh cycle – yes you don’t have to manage the hardware but this also means you are restricted to the capabilities of the offerings of the cloud vendor. For example, you are unable to use HEVC (H.265) until AWS make Maxwell based instances available.
Multicast – Unfortunately Amazon and Microsoft do not currently and as far as I know have no plans to support multicast on their network. This means that you will need to use unicast streams instead. The only way around this at the moment is to deploy a Linux based machine to act as a duplicator or repeater which is going to significantly increase the amount of traffic flowing.
Cost Balances – Remembering that you are being charged for every hour that a VM is running inside AWS can be tricky, and remembering to shut down your test VM’s at the end of a Friday can be trickier. Understanding and comparing the costs of running systems in AWS compared to traditional infrastructure costs can be problematic if you aren’t sure of the exact usage model for your cloud deployment.
Using existing local services – If you already have a mature infrastructure deployment then you aren’t going to want to build core standard services again. This means if, for example, you want to use your existing active directory deployment and keep communications secure, then you will need to configure a VPN between you and Amazon or use their direct connect service to access it. This leads into the next point of
Amazon concepts and language – As with any new technology, there are new terms to understand and learn. The difference with the cloud is that not only are there a lot of new terms and acronyms but there are also new ways of describing existing technology.
Creating a VPN on AWS can be done in 4 different ways for example. The first is referred to as a hardware VPN, and to set one of these up means having to create a virtual private gateway and a customer defined gateway, for example. However, a customer defined gateway is merely a software construct that defines your own firewall appliance that you already have deployed in your data center.
Alternatively, this can be performed via an AWS direct connection that provides a dedicated private connection from a remote network to your VPC, which can then be combined with an AWS hardware VPN for additional security.
If you have more than one remote network, then use a VPN CloudHub to create multiple VPN connections via the VPC to allow them to all communicate with each other.
Finally, you can use a software VPN so you would deploy an EC2 instance that is running a software VPN appliance.
Example Customer Architecture
As an example, see the diagram below, showing the type of architecture that could be used with the Cinegy services running in the cloud. This will enable a remote site to provide the main office site with up-to-date logging data and proxy versions of assets.
We have the system running in AWS. Cinegy Archive is running on a standard SQL EC2 instance. We have a NAS instance deployed to store the low quality assets and an Admin EC2 instance that will be used to run the Cinegy Archive Transfer utility.
We have the remote OB site, which is also running Cinegy Archive that is used to ingest the content on a daily basis. There is also a NAS storage here and an admin station which will be running the Cinegy Archive Transfer utility.
We have the main office, which again has a NAS storage and the Microsoft AD system and Cinegy Workspace users.
A VPN is established from the remote site to AWS, and this is used to transfer each day low res media files, and also the database nodes exported via the Cinegy Archive Transfer utility.
A second VPN is established between the main office and AWS, and this is used for SQL queries for Cinegy Workspace, and also the Active Directory permission queries. It is also used to access the low res assets.
Finally, the high res assets are transferred back from the remote site to the main office via courier on drives. These are then added to the local NAS storage in the main office so that they can be accessed over the LAN.
We have already made changes to the Cinegy License Service to support software-based licensing specifically for AWS.
We have been going through the process of creating our Amazon Machine Images or AMIs, and are also going through the process required to allow us to make our AMIs available on the marketplace.
We will be making a Cinegy Air AMI available imminently, which will support a Bring Your Own License model (BYOL) to start with.
The BYOL model means that a customer has a choice of surrendering some of your existing Cinegy Air licenses to use with AWS or speak to our sales team to purchase some more.
We have been working with customers who are looking to the cloud to solve problems for them, and those who want to know what they can do with the cloud currently. Some are looking to migrate existing HD channels into the cloud as a part of a hardware refresh and site move, for example.
The closest of our future plans for Cinegy in the cloud is offering a version of the Cinegy Air machine image in the Amazon marketplace, which has a monthly cost associated with it. The current monthly cost is projected to be 360 euros; however, this may vary slightly once we have feedback from pilot customers. We are offering new customers who purchase the Cinegy Air AMI through the AWS marketplace the opportunity to receive an hour of support via the usual channels on the standard SLA response if they register their details with us.
The next item which is slightly further out will be AMIs that cover other Cinegy products such as Cinegy Archive, etc., and these would also come in the Bring Your Own License and periodic charge versions.
Finally, the largest and furthest out item is offering a service where Cinegy would host and run the software for you in the cloud. Cinegy as a Service.
The exact details of how this will be offered and how it will work are still being discussed but here is what I can talk about at the moment.
You would pay a monthly or yearly charge, for example, and use the service which we would deploy, configure and support for that cost.
The benefits this would bring for our customers and partners would be things like:
Reduction in the dependency on the traditional IT department to deploy and maintain the servers.
Reduction in the need to have those skills within your team – enables partners to offload the traditional components of a Cinegy deployment allowing them to focus on the broadcast chain and workflow components.
Deployment of new versions of Cinegy products can be scheduled by us at a convenient time for you.
Deployment of fixes and tweaks to the system will be quicker as they will be carried out by Cinegy engineers.
Increased capacity in the system can be requested and costed in a more specific manner.
One of the first aspects of this type of service would be Cinegy Workspace 11, which Raffi has talked about in detail in the TechCon.