One of the concerns broadcasters express when moving to the cloud are the risks. But are these risks real?
Cloud computing is attracting much attention in the broadcasting community. We’ve moved on from simple web server and compute applications to major real-time signal processing through the implementation of virtualized and dedicated GPUs and FPGAs. Thus, allowing not only playout, but now the potential for making real-time programming. Admittedly there are still challenges to overcome with latency, but there is definitely light at the end of the tunnel.
We may think that moving to the cloud is putting all our eggs into one basket. But is this more of a psychological intrusion than a true analysis of the risk? Broadcast infrastructures are regularly installed in one building, albeit with many backup systems, and some even have offsite playout centers, but from experience, I’ve found the universe often throws us unexpected challenges in the guise of unforeseen risk and unexpected events. In other words, we cannot expect to think of all the risks all of the time.
Maybe there is another way of evaluating risk within the cloud? Instead of thinking in digital right/wrong, or good/bad type terms, we should be thinking more in terms of probability of risk. That is, we accept all infrastructures carry a certain amount of risk, it’s just with cloud computing, the risk is both easier to quantify and evaluate.
The rip-and-replace philosophy of dev-ops lends itself perfectly to this way of thinking. By accepting that we can simply delete entire infrastructures and rebuild them again in any cloud datacenter throughout the world, we remove an emotional attachment to the infrastructure. I’m sure psychologists will be able to tell us why, but there seems to be a certain egoic attachment to objects we design and own, which in turn greatly affects our thinking. For me, although this may still exist to a certain extent with cloud infrastructures, by virtue of the abstraction of the cloud, attachment is much diminished.
As an example of attachment to outcome, I used to manage a team of developers writing embedded code for products. When the code was finished and had past testing, I sent the product immediately to the sales department for further testing. And on quite a few occasions it would come back with an unexpected behavior that had not been picked up by the developers or in testing. This isn’t a criticism of developers, but to me shows an insight into their thinking. Developers code for success, whereas salespeople test for failure, because they know that’s exactly what their customers will do.
When we design any system we bring with that design a certain amount of our own bias, or emotional thinking. This is inevitable as emotional thinking forms a large part of the human condition. However, we can diminish its influence by analyzing monitoring data that is a representation of the emotionless “truth” as computers are not attached to their data gathering function. With Cloud computing we have available a much greater source of such data, and we can analyze it in the cold-light-of-day to determine a better risk analysis than we would have achieved with any physical infrastructure that we can touch.