It is 2019 now, but the article "Fabric: A retrospective on evolving SDN" about the state of the art in networking technology written in 2012 by such luminaries as Martin Cassado, Scott Schenker, Teemu Koponen looms large. All unsolved networking problems become more obvious and painful nowadays when the new paradigm of continuous application deployment requires instant connectivity. The steady trend of gradually moving workloads from private data centers to public clouds further aggravates problems in the network domain.
Bayware’s team of engineers, with vast experience in the networking industry, has created a product that crucially changes the way connectivity between application services is established. In this paper we would like to explain in a nutshell where we see the root of the problem and what we offer as the solution.
AppDevs think of communication between application services as an imaginary personified and continuous circuit through the network. For example, service A, as a client, is connected to one end of a circuit with ID 123 and service B, as a server, is connected to the second end of the circuit. AppDevs design communication using data from the application namespace.
NetSecOps see communication between hosts connected to the network as a chain of impersonal and discrete routing or policy enforcement decisions (per node) that depend on IP addresses, port numbers, and network protocols that produce data plane actions. NetSecOps configure routing and policy rules using data from the network address space and the topology of the data plane. NetSecOps provision and configure resources that may reliably and securely deliver packets from/to any IP address while AppDevs and DevOps do not care about IP addressability, routability, or policy enforcement at all. All DevOps wants is service A to communicate with service B and to have a tool to monitor this communication. All possible communication between IP addresses is not of any use to DevOps.
Before deploying application services on the hosts, DevOps must bind service names to the host IP addresses via DNS and hope that the AppDevs imaginary circuit from A to B will be correctly mapped onto the data plane of the network. Actually the accuracy and reliability of the mapping depends very little on DevOps because they lose control over communication between services as soon as the packet leaves the network interface of the host. The accuracy, security, and reliability of service-to-service communication depends mostly on NetSecOps ability to correctly and promptly configure network physical resources and on the accuracy and availability of DNS records. Thus the process of continuous deployment can be broken or delayed at any time by the incorrect configuration of the network resources.
Over the last few years many products have been developed to help DevOps get more control over the communication between services facilitating continuous deployment. All of them, to a greater or lesser extent, strive to make more routing and policy enforcement decisions within the bounds of the host’s network stack that is controlled by DevOps and leave very little to the network domain. The ideal network is seen as an endless flat IP address space with the data plane stretching through the clouds and private data centers and that provides unique and routable IP addresses for each host that runs application services. The only service that is expected from the ideal network is routing and forwarding. This ideal is not attainable because of a number of issues.
Bayware established an absolutely new approach to the mapping of the AppDev’s imaginary, personified, and continuous circuit that is based on service names and roles assigned to network resources. We call it flows. Flows are personified, i.e. bound to an application namespace via cryptographically generated flow IDs. Each flow represents a secure and isolated network micro-segment that is instantiated according to required network policies and that lives as long as DevOps allows it. DevOps instantiates flows using contracts created using information from the application namespace and Bayware's unique primitives. We explain all the internals of the contract and how it works in the next article. Also, we want to clarify in the very beginning that Bayware flow IDs have nothing in common with MPLS labels that are meaningful only within the core of the network and are completely decoupled from the application service names and roles. Also, Bayware is not another SDN because flows do not depend on the configuration of the data plane from a centralized control plane.
DevOps starts seeing communication between services as a chain of discrete actions bound to flow IDs that is, in turn, bound to service names.
We assert that communication between application services based on the flow ID eliminates many inherent problems in an IP network and enables a genuine Application Service Mesh where every flow is an isolated network segment that is created by DevOps and that remains under the full control of DevOps.
If you want to see our product in action we invite you to watch the Bayware product demo .
CEO and Co-Founder