With Mobile World Congress underway, we’re reminded that carriers are investing heavily in 5G with full intent to monetize. So it’s time to revisit the railways vs roadways question.
If you came up from the infrastructure side of ICT, you think of your networks as railways.
You build faster, smoother, more secure and more reliable railways. You conform to standards to enable interoperation. You put a lot of work into tracking who has rights to which services, optimizing routes, and regulating traffic flow to avoid congestion and outright failures and collisions.
Railways are scarce and precious. Payload owners get to choose only from whatever catalog of address management and routing services and levels of security the railway owner enables.
Short form: You hear networking people say, “our network does not trust any application.”
However, if you became an application developer in the cloud era, you think of networks as roadways. (Superhighways actually)
“Thanks, whomever, for designing, building and maintaining every better, nearly speed of light, roadways that forward packets. We’ll pay tolls as needed so you can do all the great engineering to maintain these that I don’t have to worry about.”
“But otherwise, we’ve learned the basic protocols to get on and off and to flow smoothly along. So we, the users, will isolate and secure our resources as they travel. And, using our own global-views of telemetry (ala Wayz) we’ll choose our routes and manage our flows to avoid and adjust to any congestion.”
Roadways are plentiful and mostly marginally free to use once you’ve paid for access. Payload owners gets to do anything - over the top - that does not interfere with efficient packet forwarding.
Short form: You hear application people say, “our application does not trust any network.”
A tantalizing example of pushback on the roadway model is visible in ATT-VMware extension of SDWAN to 5G. In the roadway model, 5G is just another available path. Today, most cities have many available paths due to the presence of fiber services and direct connections of all kinds.
But, note the warning that 5G latency is so low that detecting data exfiltration will be very difficult. That’s the railway model saying, “you better let us handle application security for you.
In Roy Chua’s SDxCentral article I mentioned in my last post, Roy reminded us about Cisco’s intercloud strategy that went by the way side, even though multi-cloud is clearly needed today.
Several attributes are perhaps more obvious now vs then:
- Developers, developers, developers, developers: Cloud growth is fueled by developers. Clouds are superior platforms for accelerated application development and deployment. Economies of huge scale and operationally agile scale-out drive profits not demand.
- Linux-Up: Clouds work for developers because they don’t have to know or care about any infrastructure below Linux. Infrastructure is clearly vital, but it is all the concern of the Cloud provider.
- Applications are the means of Digital Production: Digital companies’ production is organized around agile application development teams. Developers passionately avoid creating dependencies with any other application or infrastructure teams.
In summary, if Developers are defining the world, then networks are roadways.
To be specific, is this model, just as in the cloud players’ networks, there are layers of networking. The actual network (aka Layer 1-3), and then a subset of over-the-top networking (virtualized Layer 3) that applications care about to support secure messaging between microservices on any infrastructure – Linux up. Messaging (aka Layer 4-7 services) is built into applications and/or application orchestration systems.
So this brings us back to addressing multi-cloud needs via SD-WAN.
SD-WAN is aware of types of applications, e.g. Skype or Office365, that pass through particular points in the network - the branch edge. It provides security services at that point and allows users to assign the wide-area links those application types should use.
Some SD-WAN solutions offer multi-cloud capabilities, meaning you assign application types to take direct connects to a cloud or exchange location – rather than just going over the Internet or MPLS.
In the absence of an end-to-end application orientation, this is good automation of some course-grain configurations. But compared to the modern roadway model, this has at least 2 problems.
One: Flows passing through the branch edge are a subset of all of the flows of most applications. So SD-WANs are well-designed intersections with helpful signage at some of the key points along the roadway.
SD-WANs are not method by which payload owners – DevOps - isolate and secure their payloads, and use telemetry to choose routes and manage all the flows end to end.
That is the case unless your SDWAN is actually your end-to-end private network – like Aryaka or Cato; or unless your SDWAN is actually an integrated part of a global SDN solution – like Nuage.
Which brings us to problem Two:
Whether your SDWAN is multi-local, as most are, or are end-to-end like an Aryaka or Nuage, SDN solutions are not roadways, but rather more sensitive, payload-aware railways. That is, the services available are defined by the networking teams that own and operate the Aryaka or Nuage system – application owners get to choose only from a catalog and use advertised APIs.
In the roadway model, applications do not choose their services and security levels, they define and execute them iteratively. We see the overwhelming demand for this developer-defined model in the rapid rise of Service Mesh.
Roy Chua is even suggesting carriers consider organizing themselves accordingly.
In subsequent blog posts, my colleagues at Bayware and I will discuss how orchestrated systems including Service Meshes (L4-7) and Bayware (L3) that follow the roadway model, are actually made up of a few simple types of elements. This can come as quite a shock to professionals who grew up watching the railway networking model grow every more complex.
This simplicity is not only possible, but essential.