The Wisdom of the Giants in SD-WAN

Podcast on YouTube

When it comes to your branch how can SD-WAN upgrade without also uprooting? Tall trees may tell.

A Branch’s Reach Should Not Exceed Its Grasp

They are the showy exterior of your organization: your branches, your stores, your schools, your sites. But insofar as networking domains, these are the humblest of locations with little or no networking expertise and sophistication. In the past, your networking grasp was feeble in the far reaches of the branch.

Now the story goes that SD-WAN is changing that. It’s putting the prowess of your brightest networking pros and the autopilot  automation of SDN steadily into these network extremities. But this is only the beginning of the story. So allow me to disabuse you from the enrapture of the shining fruits and perfumed flowers of the branch that is SD-WAN today.

You have been tricked. This was not the story, merely the first act.

Focusing on SD-WAN, my friends, we see the fruits. Take a step back and look wider. Now we see the tree. Now we see the roots.

One Tree: Everything Is Connected

The levity with which some people and vendors approach branch networking with SD-WAN quickly fades when they realize the simple truth that, beyond the branch, everything is connected. It is one tree.

Ungrounded SD-WAN solutions ignore what’s below the branches and clouds at tree tops. But approaching enterprise networking grounded in reality, you see the whole picture: your wide-area is not only your remote and branch connectivity. Everything is connected between branch sites, campuses, headquarters, data centers, and certainly today, multicloud—SaaS and your own cloud-based applications.

You would never be so credulous as to protect a tree’s exterior, believing it’s safe from harm. And no one would mistake strung-up ornaments for the tree itself. How about vines overlaying the tree? Yes, they could reach the branches. But they still aren’t your tree, nor its species, and they cannot be grafted on. This is SD-WAN for dummies and by decoration, but it parallels some SD-WAN propaganda.

SD-WAN savvy would never use proprietary control and data plane protocols that won’t graft and interoperate with your wider network. Security would not be secondary and sheath, but foremost in the immune system of the network first. Add-on network functions like VNFs would be symbiotic and seamless with network design and management. And other virtualized branch services would felicitously fold into the SD-Branch canopy or NFV-centers in nearby limbs.

This is multicloud and multi-site thinking, end to end and top to bottom. While its natural given Juniper’s portfolio, it’s quite different than the thinking of some other SD-WAN vendors whose niche interests, I leave to be addressed with the words of a fine woodsman. “When we try to pick out anything by itself, we find it hitched to everything else in the universe.” -John Muir

Layer Upon Layer

Just under the bark are the newest layers of a tree. Pushing out and up, a tree’s trunk core and deep roots nourish new growth and give it strength to endure the tests of time.

Drawing a parallel to networking growth and longevity, you may have observed this strategy at Juniper, where investment is steadfast in Junos and our platforms. Customers enjoy the benefit of this continuity, as investment protection and the ability to simply extend and build on base systems with SDN, like SD-WAN, employing our NFX, SRX, and MX Series systems and interoperating with the routing of all Junos-powered platforms.

You may observe another approach in the industry too. Vendors that continually force rip and replacement of systems. There are sales motivations for this, but another cause runs deeper...

When you engineer something anew, you usually architect for a minimum viable product and getting to market quickly. Take a tech startup for example: it’s faster to build software as a monolith or a mesh of purely cloud services, than to construct a devops pipeline, platform architecture, and microservices that scale. Taking that MVP route, eventually they will throw away their early work, to redo it at scale, with extensibility, with reliability and economically. This is invisible to customers of SaaS companies, but when translated to packaged-and-sold hardware and software systems, this architecture fetters customers with technical debt and forces rip and replacement inefficiency.

In networking, it’s wiser to sow scale and flexibility into the seeds of your base networking technologies and topologies. Architecting for growth in layers, allows you to scale your rootstock and your core so to speak, evolving today’s investments tomorrow.

Evolvable architecture is how the cloud giants design their software, and happens to be how Juniper designs our portfolio. This is why we did not acquire an SD-WAN solution. And this is why we built SD-WAN backward: we tackled the hard problems first (multi-tenancy, scale, reliability, NFV, etc.), so we could design once and for all, and offer the simplicity of one solution.

Reach for the Clouds

With so many SD-WAN solutions in the market, and mostly built with haste, as you might imagine, the winds of technology change will cause many to snap and topple. They weren’t designed beyond SD-WAN connections for the branch and cloud endpoints.

The wisdom of giant trees would suggest that as you reach for the multicloud, strength lies in swaying and adapting with the winds of change, and evolving and using the strength of the whole.

About Juniper Contrail SD-WAN

Juniper’s newly dubbed Contrail SD-WAN solution and its component parts were designed to inherently secure from within and to scale to support thousands of tenants each with thousands of sites. It was designed where SD-WAN is merely the first act of your transformation story. So it will grow with you to SD-Branch for site virtualization and consolidation, and even incorporate NFV-cloud services into your network service. Of course it’s multicloud-ready, connecting up to the likes of AWS, but just as importantly, it ties right into your core WAN routing today from your campuses and data centers.

Podcast on Soundcloud
Podcast on YouTube

image credit MichaelGaida/pixabay

#SimpleAF Networking in 2018

Last week at its flagship customer event, NXTWORK, Juniper Networks set a valiant vision for its role in the future of networking: “Engineering. Simplicity.” Next week as we take respite from engineering and set some 2018 goals, simplicity sounds good. Here are some of my ideas inspired by engineering for simplicity and Juniper’s new #simpleAF tag. Simple as fishsticks…of course.

Da Vinci called simplicity: ultimate sophistication. It would come more easily to those solving more primitive challenges, but maybe you, like Juniper, audaciously tackle cloud-grade problems, and in such domains and at such scale, simplicity is anything but simple to achieve.

The thing about creating #simpleAF simplicity is that it’s not just about tools or products. If you’re a  network operator, another tool won’t make a revolutionary nor lasting impact toward simplifying your life any more than the momentary joy of a holiday gift. Big impacts and life changes start inside out. They don’t happen have-do-be, rather they are be-do-have. Juniper is doing its own work to put simplicity at its company’s core being, but this article, besides some gratuitous predictions, is about transforming your network operations, putting simplicity at your core for a happier prosperous 2018.

Be… the NetOps Change

To be the engineer of network simplicity, it’s time to lose the title of network admin, operator or architect and embrace a new identity as a:

Network Reliability Engineer

Just like sysadmins have graduated from technicians to technologists as SREs, the NRE title is a declaration of a new culture and serves as the zenith for all that we do and have as engineers of network invincibility. And where could invincibility be more important than at the base of the infrastructure that connects everything.

Start with this bold title, and fake it until you make it who you truly are.

Do… It Like They Do on the DevOps Channel

Just like SREs describe their practices as DevOps, network reliability engineering embraces DevNetOps.

While Dev and (app) Ops are working closely together atop cloud-native infrastructures like Kubernetes, the cluster SRE is the crucial ops role that creates operational simplicity by design of separation of concerns. Similarly, the NRE can design simplicity by offering up an API contract to the network for its consumers—probably the IaaS and cluster SREs in fact.

The lesson here is that boundaries are healthy. Separate concerns by APIs and SLA contracts to deliver simplicity to yourself as well as up the chain, whether that is to another overlay network or another kind of orchestration system.

It’s important that your foundational network layers achieve simplicity and elegance too. Trying to put an abstraction layer around and over top of a hot mess is a gift to no one, least of all yourself if it’s your mess.

So how do we clean up the painful mess that is the job of operating networks today? I’ve examined borrowing the good habits of SREs and DevOps pros before, in the shape of DevNetOps blogs and slideshares. Here is a quick recap of good behaviors to move you from the naughty to the nice list, along with my predictions for 2018.

1.     Start with Networks as Code
Prediction: When people say the network CLI is  dead, they jump straight to thinking about GUIs. Well for provisioning changes, you ought to start thinking about Eclipse Che or an IDE instead of product GUIs, and start thinking about GUIs more for observability and management by metrics. Networks as code start with good coding logistics. This coming year, I think we’ll see DevNetOpserati practice this simple truth and realize the harder one that networks as code is better on top of automated networking systems themselves. In other words, networking and config as code belong on top of SDN “intent-driven” systems, not box-by-box configurations in your github repo; nevertheless, that may be a good step depending on where you’re at in your journey.

2.     Orchestrate Your Timeline as a Pipeline
Prediction: It follows from coding habits that you follow a review and testing process for continuous integration (CI). While vendors dabble in testing automation services and simulation tools, I predict that we will see more of a focus on these in 2018 and opinionated tools that orchestrate the process workflow of CI and eventually continuous delivery/deployment (CD). This is whitespace for vendor offerings right now, and the task is ripe for truly upleveling operator simplicity with process innovation. While the industry talks about automation systems like event-driven infrastructure (EDI) and continuous response, mature DevOps tooling is ready and waiting for DevNetOps CI process pipeline automation. Furthermore, it’s more accessible in terms of codifying or programming with a higher reliability ROI.

3.     Micro and Immutable Architecture
Prediction: 2017 was the year everyone went koo koo for Kubernetes and containers. It has mainstream adoption for many kinds of applications, but networking systems from OSs to SDNs to VNFs are all lagging on the curve of refactoring into containers. I’ve reported on how finer-grained architectures are the most felicitous for DevOps, DevNetOps, and the software and hardware transformation that networking needs in order to achieve the agility of CD. We must properly architect before we automate. We’ve started to see containers hit some SDN systems in 2017, but I predict 2018 will be the year we start to see VNF waypoints as containers with multi-interface support in CNI and a maturation of higher-order networking in the ruling orchestrator, Kubernetes.

4.     Orchestrated CD from Your Pipeline
Prediction: I’m doubtful that we’ll hit this mark in 2018 in the area of DevNetOps, mostly because of some of the above prerequisites. On the flip side, it’s obvious that in 2018 we are going to see the network play a big role in micro- services CD thanks to the rise of service meshes that do a much better job of canary and blue-green deployments. CD for actual networking systems is likely experimental in 2018 or bleeding edge for some SDN systems.
 

5.     Resiliency Design and Drills
Prediction: This is the fun practice of chaos engineering, designing and automating around failures to stave off black-swan catastrophes. This design is already showing up in preference for more smaller boxes instead of fewer larger boxes. Most enterprises are also getting around to SD-WAN to use simultaneous hybrid WAN connectivity options. There is more to do here in terms of tooling and testing drills in CI pipelines, as well as embracing the “sadistic” side of the NRE culture that kills things for fun to measure and plan for invincibility or automatic recovery. In 2018, I think this will continue to focus on evolving availability designs until we make more progress in areas 2 and 3 above.
 

6.     Continuous Measurement
Prediction: The SRE and NRE culture is one of management by metrics; thus, analytics are imperative. There is always progress happening in the area of telemetry and analytics, and I know at Juniper we continue to push forward OpenNTI, JTI and AppFormix. 2018 beckons with the opportunity to do more with collection systems like Prometheus and AppFormix, employing narrow-AI deep learning for the first time to raise new insights beyond normal human observation.

7.     Continuous Response
Prediction: With the 2017 rage around intent-based or -driven networking, there is sure to be progress in 2018. While the past few years have focused on EDI, I think the most useful EDI actions are largely poised to get subsumed into SDN systems with controllers in them, similar to how Kubernetes’ controllers implement the continuous observation and correction to the declared state. There is however a tribe of NREs that look to automate across networking systems and other IT systems like incident management, ticketing and ChatOps tools. As I wrote about in May, I think the maturing serverless or FaaS space will eventually win as the right platform for these custom EDI actions.

Have… a Happier Holiday

As an NRE, it’s not just about doing DevNetOps behaviors or processes nor is it about having the greatest tools or code. When you’re network reliability engineering for simplicity, it’s equally about what’s really important when you take the NRE cape off and go home: not getting called in and enjoying a happier holiday. And so, simplicity is what I wish for you this holiday season, and for the next one, may you be further down the road of engineering simplicity.

image credit Manuchi/Pixabay

Micro-services: Knock, Knock, Knockin’ on DevNetOps’ Door

A version of this article was published on October 13, 2017 at TheNewStack https://thenewstack.io/microservices-knock-knock-knockin-devnetops-door/

“You’ve got to ask yourself one question: ‘Do I feel lucky?’ Well, do ya, punk?” – Dirty Harry

Imagine that putting this famous question to the sentiment of IT deployments, it points to IT and even business performance with scary accuracy. High performers – “The most powerful guns in the world,” to borrow Harry’s words – pull the trigger on deployments with high confidence, while deployment dread is a surefire sign of lower performers, advises the State of DevOps report.

In his talks, Gene Kim, author of The DevOps Handbook, corroborates that deployment anxiety is associated with hapless businesses half as likely to exceed profitability, productivity and market share goals, and evidently with lower market-cap growth.

We may conclude high-performing teams wear the badge of confidence because they’re among the ranks in the academy of agile, deploying more often – orders of magnitude more often. Their speed is in taking lots of little steps, so they have regular experience with change.

And feeling luckier is also an effect of actually being luckier. Data show high performers break things less often; and when they do, there are more clear-cut forensics. They bring in better MTTF and MTTR than lower performers’ old-fashioned police work because the investigation and patching proceeds quickly from the last small step, instead of digging for clues in bigger deliveries peppered with many modifications.

Less, more often, is better than more, less often

Imagine conducting IT on two technology axes: time and space. If it’s clearly healthier to automate faster, smaller steps with respect to the timeline or pipeline, then consider space or architecture. Optimizing architecture design and orchestration to recruit nimble pipeline outputs, what stands out in today’s line up of characters? Affirmative, ace: micro-services.

The principles of DevOps have been around a while and in emerging practice for more than a decade, but the pivotal technologies that cracked DevOps wide open were containers and micro-services orchestration systems like Kubernetes. Looking back, it’s not so surprising that smaller boundaries and enforced packaging from developers, preserved through the continuous integration and delivery pipeline, make more reliable cases for deployment.

A micro-services architecture isn’t foolproof, but it’s the best partner today for the speed and agility of frequent or continuous deployment.

Micro-services networks and networking as micro-services

In a technical trial of service meshes versus SDN, there are three key positions networking takes in today’s micro-services scene:

1. In a micro-services design, the pieces become smaller and the intercellular space – the network – gets bigger, busier, and hence, vital. Also, beyond zero-trust-style protection of the micro-services themselves, it’s important to have this network locked down.
2. Service discovery, service/API gateways, service advertising with DNS, and service scale-out or -in with load balancing are all players in networking’s jurisdiction.
3. Beyond micro-services, any state replication, backup, or analytics over an API, a volume, or a disk, also rides on the network.

Given the importance of networking to the success of micro-services, it’s ironic that networking components are mostly monolithic. Worse, deployment anxiety is epidemic: network operators have lengthy change controls, infrequent maintenance windows, and new code versions are held for questioning for 6-18 months and several revisions after availability.

A primal piece on DevNetOps cites five things we can borrow from the department of DevOps to remedy network ops in time and space, starting with code, pipelines and architecture.

Small steps for DevNetOps

Starting into DevNetOps is possible today with Spinnaker-esque orchestration of operational stages: a network-as-code model and repository would feed into a CICD pipeline for all configuration, template, code and software-image artifacts. With new processes and skills training of networking teams – like coding and reviewing logistics as well as testing and staging simulation – we could foil small-time CLI-push-to-production joyrides and rehabilitate seriously automation-addled “masterminds” who might playbook-push-to-production bigger mistakes.

The path to corrections and confidence on the technology time axis, begins with automating the ops timeline as a pipeline with steps of micro modifications.

Old indicted ops practices can be reinvented by the user community with vendor and open-source help for tooling, but when it comes to architecture, the vendors need to lead. Vendors are the chief “Dev” partner in the DevNetOps force, and motives are clearer than ever to build a case to pursue micro-services.

Small pieces for DevNetOps: Micro-services

After years of bigger badder network devices – producing some monolithic proportions so colossal they don’t fit through doors – vendors can’t ignore the flashing lights and sirens of cloud, containers and micro-services.

It’s clear for DevNetOps, like for DevOps, micro-sized artifacts are perfectly sized bullets for the chamber of an agile pipeline. But while there’s evidence of progress in the networking industry, there’s a ways to go.

Some good leads toward a solution include Arista supporting patch packages separate from their main EOS delivery; the OCP popularizing software and hardware disaggregation in its networking project; and Juniper Networks building on disaggregation by supporting node splicing and universal chassis for finer-grained modularity and management boundaries. Furthermore, data center network designs of resilient scale-out Clos network fabrics with pizza-box-sized devices are gradually favored over large aggregation devices. And in software-defined networking, projects like OpenContrail are now dispatched as containers.

In the world of DevOps, we know that nothing does wonders for deployment quality like developers threatened with the prospect of a page at 2am. But for DevNetOps that poetic justice is missing, and the 24/7 support between the vendor-customer wall hardly subdues operator angst when committing a change to roll a deployment. Moreover, the longer the time between a flawed vendor code change and the time it’s caught, the more muddled it gets and the tougher it is to pin.

The best line of defense against these challenges is smaller, more-frequent vendor deliveries, user tests and deployments. Drawing inspiration from the success of how DevOps was bolstered by micro-services, imagine if while we salute DevNetOps continuous and agile operations today, we compel vendors and architectural commissioners to uphold designs for finer-grained felicitous micro-services, devices and networks for a luckier tomorrow.

A version of this article was published on October 13, 2017 at TheNewStack https://thenewstack.io/microservices-knock-knock-knockin-devnetops-door/

For more information on defining DevNetOps and DecSecOps, see this article and my short slideshare:

DevNetOps Overview from James Kelly