Filter by:

Blog Subscription Form

Only if it is really simple and a lot more powerful

Charles Stucki
By Charles Stucki | 03.25.19 | No Comments

DevOps – like all other digital professionals – are constantly adopting new solutions.  But still, they maintain a very high bar to adopt anything new. 

In recent years, they have embraced containers and container orchestration. Containers have proven to be a vast improvement and the perfect complement to developers building microservices.  Container orchestration, led by Kubernetes, has also been a great improvement for deploying applications that elastically scale to take full advantage of cloud infrastructure.

As these technologies were, anything DevOps adopts has to be as simple or simpler than what they are already using, and it has to be a lot more powerful.

By the way, simple, in this world, is not an colorful and intuitive GUI.  These professionals use command line, full stop. These same commands get automated into CI/CD pipelines, ie so automation can execute code.

Simple means conceptually clear and clean. These professionals are problem solvers for mission critical assets that experience constant change, and they are always under tight deadlines.

As our goal at Bayware is to achieve simpler and more powerful application-specific networking and security for DevOps teams to use in hybrid and multi-cloud deployments, we have a keen interest in how to leap networking forward.

What are the pathways to both simpler and more powerful?

Well, first…compared to what?

Traditional networks are configuration centric.  SDN centralizes and automates the configuration.

One of the key problems with SDN is it gives APIs to applications but remains a separate domain that is common to all applications and somewhat fragile to constant change. Even while they continue to try to extend capabilities towards applications and clouds, SDNs are control not orchestrated systems.

We previously noted that Service Mesh has implemented an orchestrated model. Since each service mesh is dedicated to one application, it eliminates most network configuration by directly serving the application intent. The major drawback is that it works well in approximately one trust domain – a single, flat virtual LAN for example - because it is a layer 4-7 technology and cannot route.

To cross trust domains, companies today fall back into SDN, SDN-like, or even traditional, network-element-configuration models. To be specific, configuring security rules for a mesh of peers, and configuring routing rules for a mesh of Ingress and Egress gateways takes on the configuration complexity of legacy SDN networking. As such, these become VNFs (virtual network functions) that have moved into the application domain, but still require specialized skills in large supply for extensive configuration.

And, if not with those solutions, then how do you implement an orchestrated Layer 3 networking model across trust domains while maintaining the low- to no-configuration ie using the application defined model? 

The answer is by doing these things really well one application at a time. A DevOps team is dedicated to one application, and so must the network they use be dedicated to one application.

1– Meet DevOps on their platforms

  • Assume only IP connectivity
  • Require only Linux hosts
  • Remove control elements from the data path
  • Use application workload identities for addressing 

2– Follow the Orchestration model, with these simple ingredients

  • Human readable code decomposed into small units, ie microservices
  • Workload policy agents
  • Gateway policy engines
  • Global Orchestrators – Authorize, inform and gather telemetry from agents and engines. 

3 – Automate any required complexity, automatically create services based on known relationships in an application

  • Authorize workloads and authenticate flows
  • Discover and translate addresses
  • Filter to ports allowed in the application
  • Create encrypted tunnels
  • Gather telemetry and check heartbeat 

4 -  Default to high security everywhere

  • Use strong KPI practices and strong encryption for every communication
  • Use certificates and tokens pervasively
  • Use cryptographically generated addresses
  • Make every flow its own (isolated) microsegment
  • Default to zero trust on perimeter and throughout
  • Have all flows and all rules time out if not reauthenticated

How do you avoid complex configuration of the gateways, which is one of the key challenges of the service mesh in hybrid- and multi-cloud settings.

The answer is that you don’t want to configure them. You want to have them respond to the flow instructions originating from authorized workloads – ie network microservices mentioned above.

This is possible with active networking in general and with application defined networking specifically. A few forms of active networking are already in use with hardware-enabled models in the forms of P4, segment routing, and network service headers.

An active networking solution for DevOps has also to hold to all four of the foregoing principles, i.e. Use DevOps-familiar platforms, be orchestrated, automate any required complexity, and be secure by default. 

It can be a robust and horizontally scalable solution if built from the right primitives. 

And if the only input required is the same application deployment manifest used by the DevOps team for container orchestration, this becomes what we call application-defined networking. My colleagues and I at Bayware will explore this further in subsequent posts.