IP is a network protocol, but what's new in networking seems to have more to do with virtualization and services than with IP. The "New IP" is therefore really more about what we do with networking and how we do it. Two concepts -- microservices and network-as-a-service -- may tell the story of the future.
Microservices are a notion inherited from application design and development, an extension to old ideas like software componentization and service oriented architecture (SOA). When we apply it to networking and the cloud, what we're talking about is the definition of a mass of small but useful features or components that are accessible in the cloud and that can be used ad hoc to compose applications, services or experiences.
A microservice might be something like the "where am I?" service that returns location, or a "who's near me?" or a "what's the traffic like?" or "tell me about this zip code." By itself, it's a bit like the answer in a game of Trivial Pursuit, but if you could weave data among these microservices in an orderly way, you could build an application.
The interesting thing about microservices is that they could make the whole notion of moving to the cloud unimportant. Microservices would be there already, and by defining an easy path to solving problems or getting information without traditional application development, they could revolutionize how we view computing.
A lot of the things we already think about can be framed as microservices pretty easily. I used location services as an example, but the Internet of Things (IoT) is really a perfect microservice application. Instead of hanging a bazillion devices directly on the Internet, and hoping a user can sort out which they are interested in and that none of them will be hacked or spoofed, we would define some IoT-related microservices that provide a front-end to all those devices.
As a result, they would not have to be on the Internet at all, and we could control how we deliver their information. "Give me status from all sensors that fit this pattern" is a logical kind of query, and this would be easier for IoT app developers to do than it would be to try to locate specific sensors and learn how to talk with them.
Making the connection
An obvious challenge to this microservice vision is the problem of connection and traffic. Today, I know where an app is located, presumably, via a URL. I could know that about a microservice, too, but would I weave a web of application features from those microservices I've found? I don't want to haul traffic to my phone and back every time I link to a new microservice to fulfill my needs. I have to be able to "pipeline" work between them, or have some agent broker the work on my behalf.
Microservices could in a sense anonymize the Internet, hiding resources behind a web of services. Is that good or bad policy? It's hard to say.
Then there are the actual connections. Today, my simple web access might be a hundred microservice apps, and connecting all that is a challenge in itself. The network-as-a-service (NaaS) concept says that I can ask for connectivity on demand and it will be provided. I could use NaaS to link all my microservices into a functional service or app, tie the results to me, and I'm done, right? If we did that then I could hide all the Internet behind microservices for sure. I only need to connect what I want to use, and when I don't need it... gone.
Today, we assume open connectivity, but NaaS could assume only explicit connectivity. We don't need to firewall ourselves from something we're setting up for ourselves, so a lot of the security issues we face today would disappear. We could build tight authentication into users who request microservices and NaaS, and tight security into the services themselves.
It's almost like we'd have a chance to go back and do everything over again, to fix some of the issues we've encountered with the Internet without requiring that the Internet itself changes. We would just build a kind of shim between the Internet, resources and us.
Heading down the road
Maybe this is an extreme example, but I think it's obvious that we're heading down the road to both microservices and NaaS with the service and technology trends we already see. The cloud, software-as-a-service, mobile personalization and IoT are all easily conceptualized in microservice/NaaS terms. And both microservices and NaaS are examples of the application of virtualization to emerging services and applications.
Microservices and NaaS could change everything about our online experience, and that could bring about massive changes to infrastructure. OpenFlow, for example, could be a ready solution to NaaS because routing there can be explicit. Network functions virtualization could be the way to deploy and connect microservices because it deploys virtual functions already. However, the operative word, of course, is "could."
They say a million chimps typing for a million years could write every book ever published or that ever would be. Maybe that's true, but authors might be more efficient. If we think we're heading for NaaS and microservices, then explicit plans would help us get there quicker and produce a better result in the end.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp., special to The New IP