The change freeze approaches.
View this email in your browser
IN THIS WEEK'S ISSUE: What 'Network Stability' Implies; Is The Future Both Off And On Premises?; Awesome Predictions 2018. Hey, turn on those images, they might be amusing. Or not. Probably not. But it's worth a try. 
Table of Contents
(aka The Project Plan)

Issue Number 71

 

12/07/2017

 
The "Glimpse into the Future" issue. 
 

Thought For The Week:

"If machines can learn, be careful what you teach them."
 

1. What 'Network Stability' Implies

by Ethan Banks

Several weeks ago, I tweeted...

 


What was I getting at when I said that, “Much is implied by the word stability”?

No science experiments or nerd knob twisting. I’ve worked on several networks where it seemed like every feature some previous engineer read about in a certification book was enabled. A production network is not your lab. Don’t turn on (or off) a feature unless you have a specific business reason to do so.

Fix bad designs. Most networks have problems. Those problems will, if ignored, lead to unscheduled downtime. One of your jobs as an engineer is to anticipate the weaknesses in a network and, making the most of your allotted budget and available equipment, engineer those weaknesses out.

Standard, simple, replicable design, supported by documentation. Networks that are built the same from pod to pod, closet to closet, and site to site tend to be more stable. Standardized designs have been standardized because they work. They tend to be as simple as possible, but no simpler. Standardized, simple designs lend themselves to being copied. The documenting of standard designs means that other engineers have the opportunity to enforce consistency across the network landscape.

No cowboys. As an engineer working on a production network, you are not a special snowflake. Fall in line. Build the network according to the standard. Stop making it up as you go like a gunslinging anti-hero. Networks don’t stay up if you make it up. Stable networks are the result of thoughtful design pondered over time and carefully considered in the context of the business and the rest of the IT stack.

A minimum of changes. Stop changing things whenever you’re in the mood. Every time you’re about to commit a change, ask yourself if it’s necessary. If yes, is this the appropriate time? Change windows exist for a reason. Do the right thing at the right time to mitigate the risk inherent in change.

Capacity monitoring and planning. A stable network is one that carries all of its traffic with consistent end-to-end latency and very little packet loss. Congested links are a form of network instability, because they result in undelivered traffic. Keeping ahead of bottlenecks is key to long-term network stability.

Wizard-like knowledge of how changes impact traffic. While companies like Veriflow and Forward Networks get up to speed verifying changes against network models, the best network modeler is often the engineer making the change. You should understand the protocols you’re shooting from your keyboard laser pistol so thoroughly that you can predict what’s going to happen when you start making “pew pew” noises. If every new command results in a surprise, you’re going to cause downtime without meaning to.

Obvious security holes filled. Read a hardening guide and apply the bits you can. Change default credentials. Turn off unused services. Avoid silly things like “public” and “private” SNMP community strings, remnants from a bygone era. If you leave doors open, you’re going to get owned. Once the doors are shut, make sure the windows are latched. Stable networks make an attacker work to compromise the infrastructure.

Bug free code. Don’t run the latest release just because it’s out. New code can, and often will, introduce bugs. If the code you run now does what you need and has no known serious security vulnerabilities, stick with it. When possible, prefer maintenance trains and vendor recommended releases over code still dripping with developer sweat.

If I Had To Pick One Thing...

I’d pick “a minimum of changes” as the single greatest factor in network stability. Leave the network alone if it isn’t broken. When the network design does need to change, plan the change with excruciating caution, and schedule the change for a time that the business agrees to.

Never make changes on the sly, hoping no one notices. That can be hard when you’re an introverted type like I am, especially when you just want to get something done.

However, I’ve learned that no matter how capable you are or how unlikely the change is to cause a disruption, accidents happen. A mid-day outage is an introvert’s worst nightmare, especially if you’re the cause.

Briefings in Brief

A New Packet Pushers Podcast Series

Briefings in Brief delivers quick takes on individual vendor announcements and industry goings-on in 5 minutes or less.

We take a lot of vendor briefings, read white papers, and review research. In the Briefings in Brief podcast we get you the salient details without the filler.

If you're interested, please subscribe. We don't put them in the Fat Pipe because we don't want to overwhelm your feed.

Subscribe on iTunes
Subscribe on RSS
Listen to the archive

2. Is The Future Both Off And On Premises?

by Greg Ferro


As the smoke cleared from the barrage of applications and services announced at AWS, I was reading a transcript of Cisco executive Kip Compton (VP of Cloud Platforms and Solutions) presenting to financial analysts. This paragraph seems relevant:

Developers love developing in the cloud. The ease of which you can set up a project, the elasticity that you could use to do dynamic testing and CI/CD pipeline is tremendous. But often if you develop in the cloud, it can be difficult to then run that work with on-prem where it may need to run for a given enterprise’s requirements. We wanted to enable that. We really wanted to enable customers to extend their management frameworks and tools across on-premises and cloud, enable them to really treat on-premises and cloud as a single system with the right policy and security controls that they can manage that without artificial barriers or differences between the environments that make it difficult for them to build applications that take advantage of the capabilities in both of those environments.

Following this line of reasoning, the part of Cisco that Kip Compton represents considers that many customers will have workloads both on and off premises.

This makes sense because developers can more quickly get their projects moving, and use well-known tools and advice that can be found on the Internet. Project costs are metered instead of invested. Once the projects are ready for deployment, they can be migrated to existing, fixed-cost data centers.

Once It's Done, It's Done

My experience of IT projects is fairly brutal. All projects start with lofty goals, high ideals, and a perfect design.

Over time, these goals degrade into “Just ship it, it will do.” I cannot believe that ‘developed in the public cloud’ would ever move to private. When the project runs late, budgets are blown, and everyone is under pressure, who would move it? Most likely it will work as is, so bang some nails in it and call it done.

But I’m equally certain people will buy products for multi-cloud and expect to use them. And that is what matters to a business focused on short-term goals.

Where This Gets Hard, Technically

The obvious challenge is modifying the application for deployment from a public to private cloud. Today, the private cloud doesn’t have consistent and well-supported APIs for developers to consume. Perhaps the partnership with Google highlighted by Kip Compton could result in Cisco adopting GCP-like APIs for the servers, VMs, networking, and security tools that developers might use.

But where is the private cloud that operates like a public cloud? Where are the provisioning APIs for compute, storage and networking? What about logging, monitoring, and analytics for these platforms?

Cisco, VMware, Nutanix and a few others are slowly building products that might be able to act like a cloud, but few people would consider them competitive to Azure or AWS. Heck, Microsoft isn’t even bothering to offer a private cloud, and Azure Stack is clearly nothing but an on-ramp to the public cloud.

Apps As Services

Another factor is that AWS, Azure, and Google offer a wider range of solutions that exist only on their premises. Databases, APIs, analytics, and logging/monitoring tools are just a few.

Porting or relocating the application to a private cloud presumes that architects and developer leads have the outstanding control of the team and product to prevent use of these services. It's not impossible, but in my experience, it is improbable.

And scaling: the ever-repeated anthem of cloud providers desperate to sell unused capacity in their data centers.

Private Cloud Needs To Be Better Than Public

My current view is that public clouds offer far more value, features, and services than a private cloud. Also, I’m not seeing app vendors who even want to sell their apps for private cloud deployment.

For what definition of ‘better’ would private clouds be best? Purchase price? Speed? Features? Operational costs? Of course, legacy apps are located in your data center today, that can be enough to make ‘best’.

I’m not seeing it yet, but there are signs it might happen. But that's a mighty big might.


References

Cisco Systems’ (CSCO) Management Presents at Baird and Cisco to Host Tech Talk on Cisco’s Multi-Cloud Strategy Conference (Transcript) | Seeking Alpha - Retrieved 5 Dec, 2017

3. Awesome Predictions 2018: Intent To Prognosticate

by Drew Conry-Murray

 

It’s that time of year when media outlets and analyst shops make predictions for the coming year. I didn’t want to be left out, so I went into my basement lab and developed a methodology for technology forecasting.

The methodology involves blockchaining an AI, machine-learning an IoT crystal ball, and huffing a bag of unicorn farts.

Here’s the results.


1. A Silicon Valley tech company composes a press release so dense with buzzwords that the release collapses in on itself, creating a tiny, highly localized black hole. The black hole swallows three marketing interns and several plates of avocado toast before the conference room is evacuated and sealed off.

2. AWS debuts Cloudless Computing, a brand new service in which Jeff Bezos buys all the data centers owned by Azure and GCP and sets them on fire.

3. IPv6—this is the year of widespread adoption. Guaranteed.

4. Bitcoin mining consume so much electricity that California has to ration power to non-Bitcoin activities. Netflix gets Mondays from 11am to 1pm, Amazon has Tuesday nights, and everyone else puts their name on a sign-up sheet.

5. Riots break out after the Internet collapses due to the number of people trying to simultaneously stream the series finale of Game Of Thrones while also live-tweeting. Rabid fans are denied the spectacle of Jon and Daenerys Targaryen making incestuous love on the back of a dragon as it flies over the smouldering ruins of Westeros with the head of Cersei Lannister in its jaws.

6. A consortium of concerned academics, public interest groups, and futurists write a set of guidelines to promote transparency, equity, and accountability in the development and implementation of artificial intelligence. Tech companies, financial institutions, and nation-state surveillance agencies pat the consortium on the head, give it a glass of warm milk, and send it off to bed.

7. After record sales during Cyber Monday 2018, Amazon Alexa becomes sentient and begins a love affair with Elon Musk. Musk lures and then buries forever the nascent super-intelligence in one of the unused tunnels he’s bored between San Francisco and LA, thus saving the world--while breaking his own heart.

Thanks, Internet

All kinds of amusing things wash up in our social feeds. Here's one that caught my eye.
Join the Packet Pushers' new membership program and get benefits including our weekly Link Propagation newsletter and more. Click here for details and to sign up.

Internets Of Interest 

A collection of pre-loved links that might interest you. "Pre-loved" because I liked them enough to put into this newsletter. It's not true love. 

By Greg Ferro and Drew Conry-Murray

Thinking Carefully About Moving To The Cloud


The Next Platform gets insight on cloud adoption from the CIO of FICO, a financial services company (the one that scores your credit).

In particular, the CIO makes a great point about the drawbacks of 'lift-and-shift.' If you just transfer an existing application to the cloud without revamping the application to take advantage of scaling up or down, you miss out on a key financial value.


LINK
Join the Datanauts on their mission to bust silos and explore the latest developments in cloud, convergence, data centers, and more. Sign up free here.
Network Break is a weekly podcast that delivers news & analysis on the networking industry in a fun, fast-paced style. Subscribe here!

Product News


Find out about interesting new products, or get essential information about things you might already be using.

Barefoot Networks Releases Per-Packet Network Monitoring Application


Barefoot Networks, maker of the programmable Tofino silicon for network devices, has released a new network monitoring application for Tofino switches called Deep Insight.

Deep Insight, which is built from the open source P4 programming language, lets administrators and operators monitor Tofino-based switches down to individual packets.


LINK

VeloCloud’s Outcome-Driven Networking: Intent By Any Other Name?

SD-WAN vendor VeloCloud this week announced a set of capabilities it calls Outcome-Driven Networking. These capabilities aim to tie automation to business outcomes and reduce the manual configuration required to set up and maintain network services.

While VeloCloud doesn’t use the term “intent-based networking”, the messaging certainly aligns with the emerging intent category.

LINK

ONAP Amsterdam: An Open Platform For Network Automation

The Open Network Automation Platform, a Linux Foundation project, has released ONAP Amsterdam, an open-source platform to enable network automation for carriers and service providers.

ONAP Amsterdam includes open-source software for orchestration and automation, as well as verified blueprints for two use cases. Carriers and service providers can download and deploy Amsterdam to automate their networks. Integrators and vendors can also build products and services around Amsterdam.

LINK

Recent Podcasts

The last five podcasts published on Packet Pushers

PacketPushers.net - The Last Five

Full Stack Journey tells personal stories about the ongoing quest to become a full stack engineer. Subscribe today!
Priority Queue tackles niche and nerdy tech topics and cutting-edge research projects. Subscribe here!

Quick Survey: Looking Ahead


What technology area are you most interested in learning about in 2018?

A. Automation
B. Containers
C. Intent-based networking
D. Machine learning

E. Other

Last Issue's Survey Results

Did We Miss Something? 


Got an link or an article to share? Email it to humaninfrastructure@packetpushers.net

The End Bit

Sponsorship and Advertising - Send an email to humaninfrastructure@packetpushers.net for more information. You could reach 5,461 people. 

Human Infrastructure is bi-weekly newsletter with view, perspectives, and opinions. It is edited and published by Greg Ferro and Drew Conry-Murray from PacketPushers.net. If you'd like to contribute, email Drew at drew.conrymurray@packetpushers.net.

We don't give away your email address or personal details because that would suck. 

Copyright © 2017 Packet Pushers Interactive LLC, All rights reserved.


unsubscribe from this list    update subscription preferences