cloud

Start Your Jargon Engines!

AMSTERDAM–Nothing like back-to-back trade shows to kick in the jargon engines! First was IBC, in Amsterdam last week; SCTE Cable-Tec Expo hits Denver this week.

 

 

Three terms popped up with amusing regularity at IBC: “Workflow,” “cloud,” and “virtualization.” Translations follow.

 

Examples, from piles of notes: Workflows can be 4K, file-based, and complex. Workflows in production and distribution are changing because the video content lifecycle is changing, one IBC session aspired to explain; “build a future-proof media production workflow,” another hawked.

 

Translation: A “workflow” is telco- and IT-speak for a business policy that needs to be teased out (with an API!) of its legacy (old fart) bindings, then recombined, as a spew of data recognizable by other spews of data (sister API!), to do its intention. Turn it on, turn it off. Encrypt it, decrypt it. Code it, transcode it, decode it.

 

“Cloud,” as it relates to the non-atmospheric, needs an immediate and explicitly silent sabbatical of an indeterminate length. We will happily contribute to that here.

 

Which brings us to “virtualization.” Always just like that, wrapped in quote marks on the page, and spoken with accompanying air squiggles.

 

Here’s what’s going on with “virtualization.” Everything in our digital lives that was purpose-built is at a brink. Depending on the point of view, the camera that is just a camera, nothing else, or the phone that is just a phone, nothing else, might be on the endangered species list. Why, because it becomes a feature, and not just in your phone or tablet. It gets virtualized.

 

But! If your digital life is like mine, your phone’s camera is already better than your regular camera (which you think might be in the garage somewhere), and your phone’s phone is a pretty crappy experience.

 

So, in one sense, “virtualization” unleashes a potential software renaissance for the core workings of our digital stuff, to trick them out with a continuously improving webbing of software-created accouterment.

 

In another sense, “virtualization” casts some of the stuff in our gadget gardens into the digital doldrums. A digital doldrum device is anything you still own, but don’t use because you can’t find the charger, BluTooth-to-USB dongle, or other mission-critical thingie.

 

Ultimately, the answer depends on the degree of usefulness of the potential accouterments of the renaissance.

 

Either way, it’s coming. Because to virtualize is to gear up to work at “web speed,” like all companies “born on broadband” (name any over-the-top provider of anything) already do.

This column originally appeared in the Platforms section of Multichannel News.

 

 

Take the “Instance,” For Instance…

Last week, while wandering through yet another “cloud” conversation, flagging unfamiliar terms to tackle, one came up over, and over, and over.

 

“Instance.” Another everyday word that takes on a completely different meaning, when speaking with Software People. (Not unlike “edge,” to Distribution Network People.)

 

Here’s an example, from that set of notes: “What that means in terms of scaling is that you can deploy instances much more on demand. So we were able to get instances scaled and deployed really fast, within a few seconds, and, as a result, all that new content, too.”

 

If you were to look up what “instance” means in software terms, you’d immediately bump into an “object.” Not an object like your keys, or anything you see near you right now, because the bitch of software is that it’s all pretty much invisible, unless you can see in code.

 

An “instance,” in this instance, is a glob of code, typically a software application, that no longer runs on its own special piece of hardware, which isn’t necessarily able to see or talk to other apps on other special pieces of hardware, that are also mission critical to whatever the purpose is.

 

In this case, the purpose is the sending of video — linear, on-demand, over the top, under the bottom, whatever — to the screen that wants to display it. And the “instance,” or “object,” is software speak for making that app run on general purpose servers, instead of vendor-specific gear.

 

The verb of the instance, is “to clone.” Let’s say the app’s purpose is ingesting and storing content. Instead of the “old way” of ingesting — either pulling it down from a satellite, or off of a backbone fiber, then pouring it into a purpose-built, probably proprietary storage server — the “cloud” way is to treat assets as “instances,” which can be cloned, nearly instantaneously.

 

Benefit: Finding and using storage space, quickly and efficiently. One of the good things about cloud — video or otherwise — is that it upends the (prior) need to submit a requisition for more storage, then wait four weeks, then order it, install it, and activate it.

 

That way is particularly snarly for those unexpected “surge moments.” In the world of IP, the peak metric item isn’t the Superbowl. It’s the FIFA World Cup. When sudden millions of people want something, in IP, it’s critical to be able to spin up compute, storage and connectivity resources, really fast. For instance.

This column originally appeared in the Platforms section of Multichannel News.

 

 

 

Shims, Scrums, Pigs & Chickens

It was bound to happen: Cloud-speak intersecting with the cable-speak. Including this one: The “web services shim,” which also goes by “compatibility shim,” and just plain “shim.”

Shims, in the physical world, are wedge-like things used to fill a gap, usually so that something fits more snugly. The book of matches shoved under the wobbly table leg. The wad of cardboard to temporarily secure the window sash. The tapered shingle to shore up the doorjamb.

Guess what: “Shims” happen in software, too, and for similar reasons. When you hear it (because you will), it’s likely that you’re in a conversation about bridging something existing, to something new. And because that’s happening pretty much everywhere right now, as the industry continues its steady transition to all things Internet Protocol (IP), get ready to bump into “shim” more often.

Here’s an example from a recent batch of Cable Show 2013 notes. The topic, during the annual CTO panel, was how operators think through what types of things (encoding, buffering, navigation) go in the cloud, vs. the gateway.

Here’s how Comcast CTO Tony Werner explained it: “Compatibility shims sit between the IP devices in the home – whether tablets or other devices – and our legacy systems, which weren’t compatible. As you start to have content and transport that’s 100% IP, you don’t need web service shims. But it’s part of that gradual migration.”

Think about it from a Consumer Jane perspective. There she is, watching TV. On her tablet (or smartphone, or connected TV, or game console – but not the TV remote), she decides to set up a series recording for the new season of Breaking Bad.

In a full-on, built-out, post-shim cloud, that action would flow directly into purpose-built servers – a DVR scheduler. An availability server. A lookup table, to handle any blackout conditions. Another server determines whether Jane is authenticated to get the show, and whether any parental control settings need to be applied.

But in these relatively early days of putting linear and on-demand video into the cloud, the work of it involves – you guessed it – shims. Ways to link what Jane’s initiating, from a screen not connected via a set-top box, to the DVR inside the set-top box.

As software-speak goes, the “shim” is luxuriously tactile. Then there’s the language of “agile” computing, which is also permeating the cable technology scene. In general, “agile” is about doing more things in parallel, rather than waiting to proceed until everything is 100% ready.

Here’s a few examples of agile lingo: The scrum. The stand-up scrum. (Including this beauty of a line from a recent email: “Hey – I’m in stand-up scrums for the next half hour. Can I give you a call after?”)

Perhaps not surprisingly, “scrum,” in software terms, doesn’t involve globs of sturdy people wrangling for the rugby ball. More, it’s about organizing people and work into short “sprints” of activity, to develop code in short, small chunks, rather than building one big monolithic blob of code that takes forever to build, test, and “drop” into the system.

Here’s how Cablevision CTO Yvette Kanouff put it: “In general, the move to agile means putting out bite-sized releases, as opposed to the one big release.”

More reasons to appreciate the language of “agile:” Within scrums exist “pigs” and “chickens.” Pigs do the actual work; chickens can observe the pigs for informational reasons but can’t join in.

Or, as one clever software-side person related last week: “Using a breakfast analogy, the chicken is involved — but the pig is committed.”

This column originally appeared in the Platforms section of Multichannel News.

 

 

 

 

Who’s Your Chaos Monkey?

Maybe this is happening to you. You’re in yet another conversation with a software-side person. You find yourself slightly aghast about a mindset. You quickly cover your naiveté with that neutral, knowing face that says “of course that’s the way it is. Sure. Duh.”

Last week, it was this dandy: “Chaos Monkey.”

That’s monkey as in wrench.

In software lingo, “chaos monkey” is code, developed by Netflix, and aimed, initially, at itself. It’s a “resiliency tool that helps applications tolerate random instance failures” — like, say, when you’re streaming something, and it stops working. So you click it and it starts again – probably from a different server, in a different part of however Netflix configures itself. Chaos monkeys hurtle around, finding faults like that. To be fixed.

“Chaos Monkey” popped up in a July 2012 Netflix blog (http://nflx.it/MVI4kN) and is part of an openly available online basket of “tools for keeping your cloud operating in top form.”

What’s that? Openly available? A video competitor is making code available to its competitors to help their “clouds” work better? (Find that neutral, knowing face again!)

Welcome to step one in the mental gymnastics necessary to make the inevitable transition from “how things are today,” to “after software devours the world.” It is this: By feeding your work back into the “open” ecosystem, you benefit. You benefit because other people take your progress and further refine it. They’re usually duty-bound to feed their improvements back into the community.

Give to get.

Here’s step 2 in getting your head around how software people think: Once you place all of your products and services in the cloud, in one big, unified glob of software, then part of your daily existence is to find your failures, and fix them. Quickly.

In software, there’s no taking of two aspirin and calling in the morning. It’s about finding where it hurts, and kicking there harder.

We all have our chaos monkeys. Mine of late is iCal, which deletes stuff out of my scheduled life so randomly and completely that a paper Daytimer is on its way.

But in for video distribution, chaos monkeys make sense. Moving video over big national backbones, into regional fiber networks, into hybrid-fiber-coax (HFC) plant, to homes, is a lot about load balancing. It’s a lot about making sure that stream leaves the server intact, and gets to your screen intact. Seems inevitable for some chaos monkey action.

Up next from Netflix, and available to all? Janitor Monkey, “which helps keep your environment tidy and costs down.”

I’ll take three, please.

This column originally appeared in the Platforms section of Multichannel News.