The Management Dimension of Populism
In our populist future, the easy management vision falls apart for two reasons: scale and virtualization.
The services of the future might be more sophisticated than those of the present, but that sophistication will have to be invisible to the user ... or those services will fail. Networking is growing not because there are more Fortune 500 companies, but because every business, every consumer, is becoming network-dependent. No mass market can survive complexity, and what has to make things simple is management.
I remember 20 years ago when a reporter assigned the network management beat might as well lie down and cradle a rose. You made the front page when two executives of rival firms fought a duel with black-powder muskets ... or something like that. Even today, nothing chills an active discussion about the future of networks and services like the letters "OSS" or "BSS." Today, while most operators and even many vendors know that has to change, there's not much progress on the "how?" side.
Management practices have been fairly simple up to now. You build a network from devices, and the devices have ports and trunks and features that are represented in one or more data structures we call "MIBs" for "management information bases." You check MIB status periodically in an operations center to see if things are working or when you have a problem reported, and you take remedial action. It's simple.Easy Management Unravels
In our populist future, this easy management vision falls apart for two reasons: scale and virtualization. Traditional network management had perhaps two hundred thousand consumers, all of which were at least mid-sized businesses, because that's how many network service consumers there were. Today we're looking at many billions of consumers, and at the price they'll pay for services there's simply no way that any human at any operations center is going to look at or fix anything. The stuff either has to be automated or it's fire-and-forget, meaning best-efforts.
Most of our management initiatives in the last 20 years have been aimed at the best-efforts goal. You don't manage services, you manage resources. You have infrastructure, you have service requests, and you have a service level you plan for. If you can keep the infrastructure running as your plan demands, you generate the service level you targeted. This used to be the basis of "directory-enabled networking," and it's still how much of the IP services/applications are managed.
Virtualization breaks that, along with a bunch of other management rules. A "service" or a "network" is now a collection of instances of functionality hosted on some pool of resources. Every service/network competes for the resource pot, and all of them are unaware of the others. Some require fairly stringent quality of experience and others not much at all; some are very valuable and others less so. This alone makes effective management of the resource pool hard to apply overall; you have to recognize at least all the individual classes of service.
It also makes that simple task of looking at an MIB tough. A real router in a network has an address and an MIB that offers its status. A virtual router might be smeared across a couple VMs on a couple servers connected with virtual and real switches. What's its status? How do you control it to fix something when the resources that actually host the functionality are shared with all those other services, applications, and users? Imagine a dozen users dialing up their bandwidth. Now imagine a couple billion, and you get the picture.
You can argue, I think, that management is the forgotten piece of the virtualization pie. Everyone seems to want to push it off into someone else's bailiwick. In Network Functions Virtualization (NFV), the ETSI team made operations out of scope, which means that anything different needed for NFV operations was now an orphan. Yes, there are other groups who could claim ownership of NFV operations, but it's not easy to manage an evolving NFV functional vision when someone else is doing the functional evolution.Management Evolves
We do have some hints of how this has to work, though. First and foremost, we know that management of future services is really about service automation. You have to be able to create populist services in a "factory" where behaviors and their associated resources are stamped out like cookies. We know that stamping process has to include making all the necessary management connections to support whatever level of management we might want to impose.
We also know that the range of management options extend from per-customer-and-service management where we "see" and "control" (in software) detailed service behavior, to our best-efforts vision, where all we do is keep a resource pool running and hope for the best.
What this means is model-driven, composed, management practices. If a service is stamped out by a factory there has to be a blueprint, which means something that converts the parameters of an order into the desired output. That blueprint has to connect the management dots, and that's what's going to make getting to populist-ready management difficult. Right now, nobody at the standards level seems to be looking at those two tasks as a unit, and I don't see how it can be made to work if that unified vision isn't a given.
Good old-fashioned innovation at the vendor level might save us, but to get that we might have to forget the cherished notion of standardization. Why not? Facebook, Twitter, and most of the new services we've come to rely on were innovations that have been fit to standards selectively after the fact. Management of future services may have to follow that same course.
Read Tom Nolle's first post in his series on information populism on No Jitter: Why We Need a Populist Technology Revolution.
Follow Tom Nolle on Google+!
Tom Nolle on Google+