Blog

Filter by:

Blog Subscription Form

Self-service networking sans SDN

Igor Tarasenko
By Igor Tarasenko | 02.12.19 | No Comments

A debate on compute-first networking, in a workshop where I presented Bayware’s vision, highlighted a fundamental question – is there a better way for networks to serve applications?  I.e. how to enable application developers to obtain the service-to-service communications, aka network services, without mastering network infrastructure, VNFs and SDN.

A better way improves obtaining network services in three dimensions – easy to developinstant to deploy, and secure to use.

Seeking fundamental improvement, application developers have been using cloud-provided networking solutions that bind applications to that provider. Today, cloud-native and container-committed developers are trying service meshes that treat the network as a huge LAN.

While we agree that we have to leave configuration of network elements – appliances and VNFs – in the past, this Bayware post provides observations on why the service mesh oversimplification doesn’t work even with basic network services.

Moreover, any network bypass approach completely removes from the equation the possibility of the acceleration assists, e.g. in-line map-reduce and consensus, which, due to its distributed properties, the network can provide to applications.

Easy to develop

To make network service development as agile as programming applications, networking needs high-level abstractions. This ZDNet review cites VMWare CEO Pat Gelsinger speaking about “higher levels of abstractions, that allow us to go faster and do more things”.

Introduction of ever-higher abstraction is a continuous process in the application domain. Gelsinger points to the arrival of containers while function-as-a-service is already looming on the horizon. In contrast to the application domain, networking has operated basically at the same level of abstraction since its inception. The problem is well-known and this paper on abstractions for SDN illustrates one of the many attempts to find a solution.

Such a huge a difference between application and network domains stems from the fundamental dissimilarity of their service execution environments. Compute nodes accept code to run services while network nodes receive configuration to set services up. And configuration – whether of specialty network appliances or virtual network functions – by definition means numerous targets with disparate capabilities, which impedes continuous service development. 

A better solution would enable developers to write computer code that realizes networking logic in the same way as compute logic implemented.

Instant to deploy

Programming a network service is only the beginning. The service should be instantiated in the network just in time for an application request so that network delivers exactly what the current version of the application service intends. And this is the exact point where frustrations build up today due to the contrast of an unprecedented level of application deployment agility compared with the rigidness of traditional networking (more here).

Continuous integration and delivery (CI/CD) has finally breached “the IT wall between development and operations” as stated in this ZDNet review. As a result, application topology is not static but ever-changing. CI/CD automation makes it easy to add and remove services, chop existing ones into multiple, scale services out, and move them geographically.

To make the network responsive to continuous changes, a better solution would replace network service configuration, detached from applications, with deploying networking logic as computer code through an application’s CI/CD pipeline. Thus, compute and networking could be programmatically assembled, provisioned, and maintained on demand.

Secure to use

Securing application communication in the current realities requires departure from traditional protection principles. Firewalling and segmentation won’t work anymore – see this interview with Truman Boyes from Bloomberg.

When you talk to Boyes, now at MLB, he says, “Firewalls allow bad behavior: Insecure machines and processes are not fixed; they are filtered...”  And referring to heterogeneous environments he continues: “Perimeters mean nothing. IPs mean nothing. VLANs means nothing…”

On their own, applications have begun to fix the problem of trusted communication in highly distributed and ever-changing environments with mTLS. At the network level, no widely-accepted counterpart has appeared – apart from other network bypasses via tunneling, e.g. VxLAN-based.

Network-based security lags behind applications for another fundamental difference between the two domains: applications build trust relationships using their names, i.e. identities, while traditional networking is based on IP addresses with a location orientation.

An application would preserve policy control over communications in the network if application data traversed the network in lock step with identity-based policy.

Summary

Self-service networking – developers implementing network services as computer code, deploying them together with applications, and authorizing them for use by applications – would be a radical and welcome improvement of the application-to-network interface.

Preview of Bayware’s Solution

To improve obtaining network services by applications in all three dimensions, Bayware advocates allowing applications themselves to define and instantiate network services. 

Easy to Develop: As a high-level abstraction, Bayware employs clear communication patterns that define worfklows and norms in a role-based model. Programming combined with role designations enable any interaction schema – from client-server to consensus networking. The role logic compiles into a single target – RISC-V microprogram. This enables developers to program network services in exactly the same manner as applications.

Instant to Deploy: With Bayware, at the time of application deployment, the compute node receives both computation and networking logic. While the computation logic runs at the compute node, the networking logic – the microprogram – embeds into IPv6 extension headers and sends into the fabric of microprogram processing nodes – which are also Linux hosts – for execution. As such, there is no time gap between application deployment and network service instantiation.

Secure to Use: Instead of reusable locators, Bayware uses unique cryptographic identifiers assigned to each application instance. This enables moving away from IP to identity-based policy control in the network. As a result, networking logic securely binds to the identity so that only authenticated microprograms are able to instantiate network services.