The Best SDN for OpenStack, now for Kubernetes

In between two weeks of events as I write this, I got to stop at home and in the office for only a day, but I was excited by what I saw on Friday afternoon… The best SDN and network automation solution out there, OpenContrail, is now set to rule the Kubernetes stage too. With title of “#1 SDN for OpenStack” secured for the last two years, the OpenContrail community is now ready for Kubernetes (K8s), the hottest stack out there, and a passion of mine for which I’ve been advocating for more and more of attention around the office at Juniper.

It couldn’t be better timing, heading into KubeCon / CloudNativeCon / OpenShift Commons in Berlin this week. For those that know me, you know I love the (b)leading edge of cloud and devops, and last year when I built an AWS cluster for OpenContrail + OpenShift / Kubernetes then shared it in my Getting to #GIFEE blog, github repo, and demo video, those were early days for OpenContrail in the K8s space. It was work pioneered by OpenContrail co-founder and a few star engineers to help me cut through the off-piste mank and uncharted territory. It was also inspired by my friends at tcp cloud (now Mirantis) who presented on Smart cities / IoT with K8s, OpenContrail, and Raspberry Pi at the last KubeCon EU. Today, OpenContrail, the all-capability open SDN is ready to kill it in the Kubernetes and OpenShift spaces, elevating it to precisely what I recently demo shopped for in skis: a true all-mountain top performer (BTW my vote goes to the Rosi Exp. HD 88). Now that you know what I was doing when not blogging recently… Skiing aside, our demos are ready for the KubeCon audience this week at our Juniper booth, and I’ll be there talking about bringing a ton of extra value to the Kubernetes v1.6 networking stack.

What sets OpenContrail apart from the other networking options for Kubernetes and OpenShift is that it brings an arsenal of networking and security features to bear on your stack, developed by years of the performance-obsessed folks at Juniper and many other engineers in the community. In this space OpenContrail often competes with smaller SDN solutions offered by startups. Their said advantage is positioned as nimbler and simpler solutions. This was particularly true in their easy, integrated installation with K8s (coming for OpenContrail very soon), but on the whole, their advantage, in general across the likes of Contiv, Calico, Flannel, Weave, etc. boils down to 2 things. Let’s have a look…

First, it is easy to be simpler when primitive. This isn’t a knock on the little guys. They are very good for some pointed use cases and indeed they are simple to use. They do have real limits however. Simple operation can always come from less knobs and fewer capabilities, but I believe an important goal of SDN, self-driving infrastructure, cognitive / AI in tech, is abstraction; in other words, simplicity needn’t come from striping away functionality. We only need start with a good model for excellent performance at scale and design for elegance and ease of use. It’s not easy to do, but have you noticed that Kubernetes itself is the perfect example of this? – super easy 2 years ago, still is, but at the same time there’s a lot more to it today. It’s built on solid concepts and architecture, from a lot of wisdom at Google. Abstraction is the new black. It’s open, layered and transparent when you need to peel it back, and it is the solution to manage complexity that arises from features and concepts that aren’t for everyone. General arguments aside, if you look at something like K8s ingress or services networking / balancing, none of the SDN solutions cover that except for very pointed solutions like GKE or nginx where you’d still need one or more smaller SDN tools. Furthermore, when you start to demand network performance on the control (protocol/API) and data (traffic feeds & speeds) planes with scale in many other K8s metrics, the benefits of OpenContrail that you get for free really stand apart from the defacto K8s networking components and these niche offerings. Better still, you get it all as one OpenContrail solution that is portable across public and private clouds.

Second, other solutions are often solely focused on K8s or CaaS stacks. OpenContrail is an SDN solution that isn’t just for Kubernetes nor containers. It’s one ring to rule them all. It works on adjacent CaaS stack integrations with OpenShift, Mesos, etc., but it’s equally if not more time-tested in VMware and OpenStack stacks and even bare-metal or DIY orchestration of mixed runtimes. You might have heard of publicized customer cases for CaaS, VMware and OpenStack across hybrid clouds and continuing with the same OpenContrail networking irrespective of stacking PaaS and CaaS upon pub/prvt IaaS or metal (here are a few 1, 2, 3). It’s one solution unifying your stack integration, network automation and policy needs across everything. In other words, the only-one-you-need all-mountain ski. The only competitor that comes close to this breadth is Nuage Networks, but they get knocked out quickly for not being open source (without tackling other important performance and scale detail here). If the right ski for the conditions sounds more fun to you, like the right tool for the right job, then wait for my next blog on hybrid cloud…and what I spoke about at IBM Interconnect (sorry no recording). In short, while having lots of skis may have an appeal to different conditions, having lots of networking solutions is a recipe for IT disaster because the network foundation is so pervasive and needs to connect everything.

With OpenContrail developers now making it is dead easy to deploy with K8s (think kubeadm, Helm, Ansible…) and seamless to operate with K8s, it’s going to do what it did for OpenStack networking, for Kubernetes networking very quickly. I’m really excited to be a part of it.

You can visit the Juniper booth to find me and hear more. As you may know, Juniper is the leading contributor to OpenContrail, but we’re also putting K8s to work in the Juniper customer service workbench and CSO product (NFV/CPE offering). Moreover, and extremely complementary to Juniper’s Contrail Networking (our OpenContrail offering), Juniper just acquired AppFormix 4 months ago. AppFormix is smart operations management software that will make your OpenStack or K8s cluster ops akin to a self-driving Tesla (a must if your ops experience is about as much fun as a traffic jam). Juniper’s AppFormix will give you visibility into the state of workloads both apps and software-defined infrastructure stack components alike, and it applies big data and cognitive machine learning to automate and adapt policies, alarms, chargebacks and more. AppFormix is my new jam (with Contrail PB)… it gathers and turns your cloud ops data into insight… The better and faster you can do that, the better your competitive advantage. As you can tell, KubeCon is going to be fun this week!

DEMOS DEMOS DEMOS

+update 3/28
Thanks to the Juniper marketing folks for a list of the demos that we'll be sharing at KubeCon:

1. Contrail Networking integrated with a Kubernetes cluster (fully v1.6 compatible) -
   • Namespaces/RBAC/Network Policy improved security with OpenContrail virtual networks, VPC/projects and security groups (YouTube demo video)
   • Ingress and Services load balancing with OpenContrail HAProxy, vRouter ECMP, and floating IP addresses, improving performance (remove KubeProxy) and consolidating SDN implementation (YouTube demo video)
   • Connecting multiple hybrid clouds with simple network federation and unified policy
   • Consolidating stacked CaaS on IaaS SDN: optimized OpenContrail vRouter networking "passthru" for Kubernetes nodes on top of OpenStack VMs
2. Contrail Networking integrated with an OpenShift cluster (YouTube demo video)
3. Contrail Networking containerized and easy deployment in Kubernetes
4. AppFormix monitoring and analytics for Kubernetes and workload re-placement automation

I'll light these up with links to YouTube videos as I get the URLs.

Fond Memories of 2016

2016 was a year full of fun and adventure. To change up this blog installment, here is the video Linh and I shared on Facebook with our friends and families.

Some more quick fun facts about my 2016…

• Linh and I got engaged on October 12 in Half Moon Bay
• I have a new niece, Felicity, who I adore and got to visit in Jersey and can’t wait to see her again soon
• I posted 165 times on Facebook (I’m sure that’s a record for me, but that’s what you get when you hang around with a Facebook star like Linh)
• Linh and I went to Canada together on an extended business/pleasure adventure. It was her first time in Canada, first time meeting some of my family this year there and elsewhere, and the fall colours ;) were beautiful
• Along that theme, we went to a hockey game. Linh’s first, my umpteenth, but it was a good match really far along in the playoffs
• We built a garden that we love at our apartment home in San Jose
• Linh and I both re-started painting. Although Linh was more productive in making many pieces, it has been wonderful to get back into it for us both. It’s fun to paint pieces for our friends and home
• We ate countless oysters and in many fine establishments including *** Per Se
• We went horseback riding on the beach
• I traveled to a new country for me, Korea, and countless other places mostly with Linh… well I can count quite a few. Let me see: New York, Las Vegas, Los Angeles, Portland and Dundee/wine country, Oregon, Marin, Napa (twice), Seattle (twice), Chicago (3 times), Austin, Atlanta, Miami and Orlando, Washington DC, Yosemite National Park and Tioga Pass, Lake Tahoe, Paso Robles, SLO, Morro bay, Arizona, New Jersey, (old / UK) Jersey, England (London, Manchester, Cambridge, Oxford, Nantwich…), and on the trip to Canada just Niagara-on-the-Lake, Ontario wine country, Toronto, Montreal, Ottawa and Gatineau Park, Greater Vancouver and Roberts Creek on the BC Sunshine Coast.

The Road to Intent-Driven Infrastructure Is Paved with Confusion

Winding down 2016, I’ve participated in a few conferences, KubeCon / CloudNativeCon and the Gartner Data Center Infrastructure conference. I’ve also worked on the acquisition of AppFormix by Juniper to give us a leg up in cloud analytics based on big data and machine learning. The sum of my learning and conversations piqued my analysis and skepticism with some commonly encountered and complementary hyped topics:

• Intent-driven infrastructure/networking
• Machine/deep learning-based autonomous infrastructure
• Self-driving infrastructure/networking
• Declarative infrastructure and infrastructure as code

With more freshness and luster than the long-in-the-tooth SDN, NFV, cloud, XaaS, all of these topics are already well-traveled and racked up millions of blog and PowerPoint miles in 2016, but often I see these topics and terms conflated or interchanged like they are the same thing.

Based on my recent discussions at the Gartner conference and some of the networking pundits I read, the most anticipated and highest form of infrastructure enlightenment is intent-driven infrastructure. This is mostly covered as intent-based or intent-driven networking in my circles, but it certainly can be applied more broadly as an approach to systems. Unfortunately, “intent…,” in my observation, is the term with the most offenders misusing it, abusing it, substituting it or mixing it with terms like automated, policy-based, declarative, or smart/intelligent infrastructure.

Embellishments and lofty labeling aside, I believe the term “intent” is easily and often abused because it is a precarious business to understand intent at all. With the way I use the word “intent” normally, doing something based on intent, seems like it could be exercise in mind reading.

If you’ve seen that, and scratched your head, then you’re not alone. Seeking to better understand this myself, I undertook a journey of reading and research, but especially looking at intent in its truer form studied in psychology. In this blog, I suss out a few of the difficult aspects of understanding intent, searching for key tenets and considerations for constructing an intent-based and -driven technical system. However, instead of keeping it all technical, I look for support of these traits from reflection on and inspiration from the traditional intention of intent.

What is intent?

A logical place to start is in defining and really understanding the terms.

When one reads about intent, we find the dictionary definition, of one’s purpose or meaning. Have you ever been on the bad end of a miscommunication where the intent didn’t come across properly? It happens all the time because intent is generally communicated as much by what we don’t say and don’t need to consider as much as what we do express. Miscommunications and mistaken assumptions won’t do for technical applications unfortunately.

So can we apply intent or user intent to technical applications? Certainly not the general way that we define intent because intent is never outwardly expressed. Rather it is the internal precursor to what we say or do, or even more generally who we are. Nevertheless, technocrats are well-practiced at making inspired metaphors, so let’s go with it, and find out what we can usefully borrow from what we know of intentions in their true forms.

Studying intent a little deeper with the help of psychological research, we find out where intentions come from and some description of the unspoken context that makes up intention. Here’s a snippet lifted from Wikipedia, where there is copious more detail if you’re interested.

“intentions to perform the behavior appear to derive from attitudes, subjective norms, and perceived behavioral control.”

From this we can say a few things about the context surrounding intentions:

• Our intentions are shaped by the state of our attitudes (which may be capricious)
• We don’t usually intend to act outside of social norms, especially not outside of the law
• We don’t intend to act beyond our perceived capabilities and knowledge

What is intent-based and intent-driven?

To apply the idea of intent to a technical system, these two terms come up in recent language: intent-based and intent-driven.

When I hear these, I think of configuration in different regards.

With respect to intent-based, we can say that the basis of the system, that is foundational, more static configurations, should be in the form of user intent.

With respect to intent-driven, we can say that ongoing execution and more-dynamic control should be in accordance with user intent and the intent of interfacing systems that help “drive” the system. For technical applications, I take this to mean that how a system’s own APIs, self-feedback loops are interpreted and oriented are also re-configurations aligned with intent-based user configuration and intent of other system actors.

Of the two terms, let’s continue with intent-driven because it encompasses intent-based.

Expressing Intent to Technical Applications

Using the abovementioned definition and understanding of intent we can translate some the findings to come up with key tenets for intent-driven systems and their configurations.

If intent is a purpose or meaning behind a behavior, then it isn’t the behavior itself (words, actions…). It’s the meta behavior. It’s inherently abstract in the what, and doesn’t really consider many details of the how or the motives of the why, but will certainly have contextual requirements for the why, what and how. I believe the when, where and who, are usually abstract considerations as well, if not even explicit in our intentions, but this varies.

The first thing that falls out of this in many people’s observations is notion of something abstract.

Since in human communication, our words and actions closely approximate the intent, but we abstract away unnecessary detail, we can say that abstraction is an important aspect to translate to technical applications of intent.

Abstraction isn’t a new desirable tenet of technical systems neither. We talked about it for years as a desirable aspect of SDN systems in the networking industry. Abstraction is a double-edged sword however.

Abstraction allows us to encapsulate and hide detail which provides flexibility. Losing specificity, however, introduces unpredictability. Unpredictability and variability in the nature of acting out our own intentions is exactly why miscommunications happen. It is also why many of us never achieve our intents. Another interesting point borrowed from the psychology of personal development, is that a lazy man has intents, and an achiever has goals. When it comes to goals, the more clarity, specificity and measurability, the more likely we will follow through on course.

The difference with technical systems is that there is no question of follow through or execution in other words. Systems execute, and don’t have lazy days. The value abstraction provides is that for a set of abstract user input we have many ways to achieve a result without changing the input or its form. This flexibility is important because it allows us to avoid lock-in and innovate, creating new ways to get the same result. New and different results, however, that still meet the abstract intention, may or may not be so welcome, so we need to strike the right balance of abstraction and very likely ascend to grander abstractions in layers… more on this below.

Moving on, if we have to express the meta behavior, the intent, directly, then we should not specify the how, but rather the where, when, who and especially what. An intent can certainly embody these things, and of course systems deal in these too. This important aspect, points us to adopt the virtues of a configuration that is declarative for technical applications, as opposed to imperative directions that control the detail of the how.

We also learned that our own intentions are guided by subjective norms and law. If we had to expressly communicate those for a technical application, this translates to policy-oriented configuration constraints. Subjective norms may also change based on the environment, time, actors, etc. It would be useful if these variable norms, could also be policy adjustments resulting from the insight of self-learning technology with or without human verification.

When it comes to human intentions restricted by the possible and capable, I think the technical translation easily points to what is programmed and resourced for the system. I don’t think this is a key tenet by any means because it is so obvious. Interestingly, some technical systems can grow new capabilities through extensibility or training, and those new capabilities are basically new programming, and we would likely have to reshape the form of the input intent to take advantage of them. This is similar to how we change our own intentions based on new knowledge and capability.

What about our intents being shaped by our attitudes?

Just Deal with It

How could an attitude bias inspire a technical translation? Attitudes are our internal states, moods, feelings. Systems have internal states as least. This aspect could be simply mean when executing a system to realize an intent, there is a consideration of the internal state of the system.

Have you ever had to do something when you were tired, sad, frustrated? Sometimes humans also intend to achieve things that are in conflict with our own attitudes, and even require us to change our attitudes. This is kind of like a system dealing with its own internal state and feeding that back to itself to carry out the intention in spite of its state. To me this reveals, an interesting tenet of the inter-workings of an intent-driven system. They should be self-aware of their ability to meet their purpose using real-time telemetry and analytics about its own performance, scale, and productivity. They should automatically pace, scale, and heal themselves in accordance with the input intent they accept.

Architecting Intent-Driven Systems

Above, we covered where, when, who, what, and how, but not the why of an intent, and yet an important aspect of an intent is that it also embodies the why, the purpose or meaning behind. It’s not something we are as used to thinking about for technical applications. When we look at the why of any real intention we have, we can get another intention and can recursively ask why again, until we climb up to our core worldview, morals, values and beliefs. Taking inspiration from that, points us in the direction that I hinted at above when I mentioned layers. A system that is acting on an intent, is really just focused on a single purpose, but often in service of a larger purpose. This points us to architecting our systems with composability, and decomposing systems into services, subservices, and micro-services insofar as we can still clearly define small purposed systems without getting into the minutia.

Where to Start

There is a lot of intent-driven research and development happening in networking, but really that is a bad place to start thinking about intent overall because as above, when we ask why, for an intent-driven network system, we ascend to the higher level. There is no network built out of the intent to build a network, except as a pure science project. Intent never describes a network, intent designs connection and has explicit or implicit criteria like security norms, latency and bandwidth.

Of course that intent is in service of a larger intent. If we keep asking why, we will ascend to what is really of value. If we take an Enterprise as an example, the value a business gets from technology is derived from applications. Infrastructure and network connection is down the chain of value and intent past the apps and their development and orchestration systems that manage the infrastructure and connections they require.

In short, looking up is the best place to start. If a system is down the value chain, we need to consider what will encompass it. Generally, that points to the application stack first, and second to the ITSM or I&O management tools that should take business policy and governance intent as additional constraints.

In Summary

After a closer scientific look at intention, I’m now a lot clearer about intent-driven systems. We’ve extracted a few key tenets about intent-oriented system configurations and intent-driven systems themselves.

While there are values to each one of these aspects individually, it is only when applied collectively that we can really say intent-driven. So if we go and make intent-driven systems are customers going to be clamoring for them? It is worth a lot of the hype? I don’t think so. The systems developers will get value in organizing this way, but the users are never going to get out of bed in the morning and say to themselves, “I’ve got to get an intent-driven X.” Users and businesses are always going to be sold on meeting their own higher intentions.