Can we burn it all down and start again ? 
View this email in your browser
IN THIS WEEK'S ISSUE: Personal Transformation & Dancing Elephants.  Hey, turn on those images, they might be cute. Or not. Probably not. But we might. 
Table of Contents
(aka The Project Plan)

Issue Number 62

 

08/03/2017

 
The "Drew Isn't Here This Week Lets Wreck the Place" issue. 
 

Thought For The Week:

Be the person that never uses "Reply All". For all our sakes. 
 

1. Personal Transformation

by Ethan Banks

I recently attended Cloud Field Day 2, a Tech Field Day event, as a delegate. A recurring CFD2 theme was that of old companies used to selling physical infrastructure transitioning their business to the cloud era.

For example, consider Gigamon. As an infrastructure-centric company, how should Gigamon re-tool their product set for the cloud, while at the same time preserving their existing revenues? That’s an especially poignant question for them as a public company.

For years, Gigamon has been a company making pricey orange boxes with unicorn-powered silicon that can copy, filter, and slice packets from local networks, getting the desired data over to tools for analysis.

What happens to Gigamon when a company has moved some of their computing resources into the public cloud? All of a sudden, the physical wires are gone, presenting Gigamon with a multitude of problems, all of which they are aggressively addressing.

  1. How does Gigamon gain access to the packets they were previously able to see flowing by on the wire? There are no accessible physical wires in the public cloud. Getting copies of packets from virtual compute means getting access to a virtual wire and moving the packet access to the world of software, rather than hardware.

  2. Gigamon has been selling platforms in the form of hardware and software. If the hardware part of the equation goes away for some of their customers, they need to sort out a revenue replacement.

  3. Deploying compute resources in the public cloud doesn’t equate to a virtualized version of an enterprise’s formerly physical data center. When properly taken advantage of, public cloud implies a change in application architecture, where efficiencies with cost benefits are gained by only spinning up workloads where they are needed. How does a Gigamon, used to being racked, cabled, and left alone handle ephemeral infrastructure? Or put another way, how does Gigamon become visibility fabric for cloud-native applications?

I won’t break down the technical detail of the Gigamon cloud solution. You can watch the CFD2 videos with Gigamon here for details. In any case, based on Gigamon’s financial growth numbers, they are doing something right. Gigamon is climbing aboard the AWS train, offering what they claim is “pervasive visibility in AWS.” Gigamon is making the transition.

The parallels to human careers are startling.

  1. How do you add value to the network when that network is no longer physical switches and routers, but rather a virtual construct living in a public cloud? You need to learn that public cloud environment, and get mental access to that style of architecture.

  2. How do you replace the revenue you stand to lose if you’re not working on hardware like you once were? You move the knowledge you had in networking hardware into cloud expertise. Take what you know about hardware, apply what you can, set aside what you must, and learn the new stuff. Swap out the hardware revenue you once made with cloud revenue instead.

  3. How do you advance your old way of delivering networks--that comfortable architecture you’ve whiteboarded variants of so many times to solve well-understood on-premises problems? Can you just lift-and-shift that architecture to cloud, doing the same thing you’ve always done, just clicking your way through the AWS interface? No, you really can’t. There are similarities, but cloud networking is a different beast with far different constraints. You’ll have to learn how to do cloud-native networking, unlearning some of what you know along the way to get the job done properly in the cloud era.

If a behemoth like Gigamon can start to make the transition, you can, too. You’re far more agile. You just need the will to turn the wheel in the direction you want to head.

Sponsor: Cato Networks

What SD-WAN Vendors won’t tell you about SD-WANs

Cut WAN costs, improve performance, increase security – are software-defined wide area networks (SD-WANs) really the answer to today’s WAN woes? 

Join us as Steve Garson, President of SD-WAN Experts, speaks about the reality of today’s SD-WANs. It’s a packed webinar filled with the practical questions anyone should ask when evaluating SD-WAN appliances and services. 

Topics to be covered in this webinar include:

  • What aspects of network performance can SD-WANs really improve?
  • When is service insertion and service chaining needed?
  • Why is security still a problem for SD-WANs even though they encrypt all traffic?


2. Elephants Don't Dance

by Greg Ferro

If only there was this feature, or that function. If only the hardware could have 4 more ports, or have the faster interface. I want to keep using BGP because I understand it so lets use it to connect Link State routing protocols or maybe use it as a database API to fetch link state data. 

When your vendor or reseller sales grunt turns up at your office and asks what you need in the product, have you ever thought of saying "I want less features so there is less to go wrong" ? If not, why not ? 
 

Big Companies, Small Achievements


Big organisations can achieve big things. Huge tasks like making ASICs or building a global sales organisation, or a supply chain that delivers large numbers of goods need big companies to operate them. Humans perform these tasks and large groups of humans tend towards dumbness. Look at a rock concert or people who watch sports ball to see how much dumb can exist in a single place. 

Its also fact that big companies are slow and stupid. Any large institution from government, corporate, religious, or social sectors are always slow, lumbering services. 

What does this mean ? Small changes, small achievements. 

If you deal with a big IT vendor you should understand that you have two choices. One, wait for the next big product to trundle down their driveway and park itself on your front lawn. Two, do some tinkering to improve on the basic design. 

Small achievements are about the best you can expect from big companies. Elephants don't dance.
 

PS: Should Networking Be A Big Thing ? 


I do not think networking should be a big thing. A Tesla Model 3 with self-driving software is much more complicated than an average router and costs less than most. Here is what I think : if you could halve the cost of your network purchasing, I would replace it twice as often. Small is fast, disposable and flexible. Networking should be a small thing. 

Thanks, Internet

All kinds of amusing things wash up in our social feeds. Here's one that caught my eye.
Now, lets talk about wireless security !!


 
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

Take The Packet Pushers Audience Survey


The Packet Pushers annual audience survey is live and online. Once a year we ask our listeners for feedback on how we're doing. We also collect demographic information to help us lure sponsors into our trap. No, wait! I mean, to give sponsors an idea of who's listening and why it's an audience they want to reach. Yup, that's what I meant.

In any case, we'd appreciate if you could take a little of your time to complete the survey. We won't share individual responses or details with anyone. We do share aggregate data with sponsors as part of our media kit. Thanks in advance for your support--this means a lot to us!

LINK

AWS Whitepaper - Infrastructure as Code


While I find AWS endlessly confusing & hard to use, I often wonder if thats because don't think like AWS. Have I been trained/learned to think like a Cisco solution over the years ? Is it my fault or is AWS just all wrong ? 

Maybe we can find some insights in this whitepaper. Hot tip: it didn't make much sense to me. 

Infrastructure as Code treats these configuration files as software code. These files can be used to produce a set of artifacts, namely the compute, storage, network, and application services that comprise an operating environment. Infrastructure as Code eliminates configuration drift through automation, thereby increasing the speed and agility of infrastructure deployments. 



LINK

Dell Storage Networking I/O Guide February 2016


Haven't just poxed AWS in the previous link, I got to read this 106 page guide from DellEMC on the, literally, hundreds of possible configurations to connect servers to the network. 

In all honesty, no wonder your average CIO (who, generally, has the technical prowess of flatulent monkey) looks at the public cloud and says "that looks easier, I want to do that". 

OTOH, this guide is done very well and reduces the pointless complexity of modern server/storage/networking to something almost comprehensible. 



LINK

Streaming BGP Data

Using model-driven telemetry to collect BGP data with Cisco-flavour ? Some insights into the process here. Actually, the whole site is a great read and worth keeping on your list of things to check up. Maintained by a bunch of Cisco salary slaves. 

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.

PASS


Its been a quiet week. Lots of small announcement but nothing that I think is worth your time and attention. Back in the issue!

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: Your data centre is on fire, do you :


Here's a brief description of the survey

A. Hit the Halon suppression so you have time to get out ?
B. Be cool & relaxed while posting photos on twitter ?  
C.  Start messaging your 'squad' and planning a blowout weekend now that network upgrade is cancelled ?  
D. Look for flammable materials to throw on top. This is make sure that everything burns so you can finally upgrade the network properly  
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