Blog

Filter by:

Blog Subscription Form

7 network-automation insights from KubeCon | CloudNativeCon

Charles Stucki
By Charles Stucki | 12.17.18 | No Comments

At KubeCon | CloudNativeCon you don’t have to convince anyone that applications are the center of the universe, nor that automating deployment is the key to success. One clever speaker noted that in this industry too, the last ones to have their jobs automated away are the ones programming the automation.

And you don’t have to convince them about overlays and underlays. This is an overlay crowd. You don’t hear about networking hardware any more than you hear about microprocessors or solid-state storage arrays. 

We know application development keeps getting faster with modern micro-service-oriented architectures, cloud technologies and agile DevOps processes including continuous integration and deployment (CI/CD).

As the highly respected developer Kelsey Hightower - speaking at KubeCon - emphasizes, CI/CD is the endgame using the best tools you can find to take the evergreen complexities of deployment out of scope for developers. 

1. CI/CD is the goal.

Many digital executives maybe don’t think about deployment, because in whatever cloud, deployment is not about features, rather it is mainly about networking including security settings. Networking is lagging far behind application development in terms of agility, even in the cloud.

Getting to NetOps is more than process change.  Just like DevOps did in development, NetOps requires cloud-native technology that embraces continuous change that flows from applications.

The minds behind Kubernetes, like Brian Grant, will tell you that cloud native is made possible by Observability which is made possible by building it into systems composed from cloud-native primitives.  “Without Observability, all control loops are open,” he summarized for a crowd of enterprise technology professionals here this year.

2. You must build Observability into the system.

3. To have observability, you must have granular software primitives.

That control loop starts with intended state. Observability enables you to observe current state, compute Diff from intended state, and act. That is why for cloud-native overlay networking, intended state i.e.  application intent is the starting point, as I wrote in my last post.

In this post, let’s look at what application-intent means when you break it down into more tangible capabilities – and keep the count going:

4. Application developers define the service graph

Which services can talk to which? In microservice-oriented applications, developers declare intent: which services perform which roles and can communicate in which direction and by whose initiation, with which other services related to which functions or roles in the application. 

Aka RBAC. To date much of this is known as Role Based Access Control. In the past, networking people may have had to detect or infer this because these relationships were buried in monolithic code. But in modern applications this is made explicit in a manifest file.  Developers and networking professionals use this manifest to declare the flows that need to exist.

5. Microservices need to use ID name space

Authenticated service instance identities take on roles declared in the service graph.  The intent that is clear from the service graph, can get lost when service instance IDs get translated into IP addresses.  Applications can’t rely on IP Addresses for service to service communication, because IP addresses change at an accelerating pace. The solution to this problem is to grant access, create any routing rules, and define any other network flow policy based on a verified identity that is meaningful to the application instead of IP addresses.

6. Service discovery, targeting, and route control must be based on ID

Dynamic networking requires determining the right flow right now.

Much of the interest over service meshes is their ability to keep pace when workloads move or replicate with discovery and verification of the identity and health of a target for a communication flow, all based on ID.

Note that service mesh is a flat network model. An area that still needs work is traffic steering, multicasting, publish-subscribe and other route control policies that are important to distributed applications across multiple clusters including hybrid and multicloud cloud operations. 

7. Microsegmentation based on ID is still required

Isolation, subnetting, anti-affinity policies need to be made explicit. This is the other side of the routing question. These are policies about what should not happen between services wherever they may appear.  Developers usually don’t describe the absence of some flows, so this becomes a critical addition by the professionals responsible for deployment (and compliance.) Having Observable primitives that can verify the flows and the absence of flows is also critical to achieve production readiness.

This problem is greatly simplified if you start with a white list, i.e. at a zero-trust or default-deny, and only allow an authenticated communication flow where it is authorized by the authenticated user acting in the authorized role. Yes, that is several facets of authorization and authentication.

Let us know what you think at www.bayware.io.  In my next post I’ll dive into service meshes.