Welcome!

Linux Authors: Hovhannes Avoyan, Pat Romanski, Elizabeth White, Yeshim Deniz, Brian Lavallée

Related Topics: SDN Journal, Java, SOA & WOA, Linux, Virtualization

SDN Journal: Blog Feed Post

Self-Driving Cars, Amazon and Networking

Networking has similar requirements around capacity

Google’s pursuit of self-driving cars has been well documented over the years. The promise of fleets of self-driving vehicles that could potentially make driving safer while simultaneously shortening commute times makes it one of the most attractive futures technologies around. But where would self-driving cars be adopted first?

While there will certainly be some people with deep pockets in Silicon Valley who will want to be early adopters, commuter driving is not likely the place where this catches on first. A few self-driving cars on the freeway will not change the commute times in a meaningful way because they would be minorities amidst a sea of normal cars operating by the same people who have made commuting a nightmare up until this point. With commute times unchanged, it means that individuals would still have the same commute. The only difference is that they could text or read or do whatever while they sit in stop-and-go traffic.

Broader adoption will be led by use cases where the technology eliminates a problem.

To see Plexxi’s integration with OpenDaylight, tune into the March 14 live demonstration on SDNCentral. For full details, check out the event registration page.

Most of the cargo that moves within US borders is still transported by truck. These trucks operate under strict federal regulations that given how many hours drivers can man the wheel in any one day. This means that the distance that goods can move is dependent on the number of hours and the conditions on the road. What would happen if one of those constraints was lifted? Self-driving trucks would allow shipping companies to keep their goods on the move for a much longer period of time each day.

One scenario that could play out would be drivers riding along in the cab while the trucks negotiate major highways. There will still be a need for the actual drivers – filling gas, maintenance, unmapped roads, unusual traffic conditions, and so on. Plus, adoption is not going to start with completely driverless vehicles; a hybrid approach with someone present would make the transition easier.

But which companies push this first? Amazon is an interesting match.

Amazon’s business is retail, but they are really a giant logistics company. Their skills are in managing their supply chain. They have mastered the art of maintaining warehouses using advanced technologies like the Kiva Systems robots.

But despite all their prowess, it’s tough to compete with the same-day availability that local stores offer. Sure, Amazon has spun up same-day delivery services in a handful of markets, but these will be very limited by proximity to the goods being shipped. In essence, if people live within range of an existing warehouse, they can get same-day service.

To expand the service to more goods and geographies, Amazon could build out more warehouses. But the retail market exists on razor-thin margins. Building out a bunch of infrastructure to support same-day delivery might not be an economically viable model. But what would happen if Amazon could extend its warehouse capacity to where it was needed in a model that was more dynamic and elastic?

Self-driving trucks might make it possible to essentially provide rolling micro-warehouses stocked with goods based on trending demand. You wouldn’t pack the trucks with every good, but you might be able to stock them with basic staples that map to historic demand for certain areas. The trucks would be dispatched from their super-regional warehouses and then distribute en route to the next warehouse. There is still a last-mile problem; you wouldn’t use huge semis to deliver goods to individual homes. But Amazon could continue to use existing distribution channels. That said, it wouldn’t be a stretch to extend the self-driving car model to smaller delivery trucks as well, giving Amazon complete ownership over the delivery process.

So how does this relate to networking?

Networking has similar requirements around capacity. Where Amazon builds general warehouse capacity, most networks build out similar aggregate capacity. Without knowing what the traffic load will be or where it will manifest, both Amazon and network architectures provide high amounts of centralized capacity from which they serve their users.

However, Amazon’s problem is not solving its aggregate warehouse capacity problem. Instead, Amazon needs to provide capacity in much smaller sizes but in the locations that capacity is required. Similarly, solving the aggregate network capacity problem is interesting, but it is perhaps more meaningful to be able to provide smaller amounts of capacity where and when it is needed.

The question is how do you provide the required fluidity of capacity?

We have trained our industry for the past few years to think about applications as portable. Accordingly, we have spent a lot of time focused on how to make the network adjust to moving application workloads. But it’s not just the compute workloads that need to be portable. The networking workloads have a similar requirement. But how do you make capacity fluid when everything is statically wired?

Maybe that’s a problem worth solving too.

[Today’s fun fact: Men can read smaller print than women; women can hear better than men. I don’t know about other guys, but my wife certainly hears everything I say under my breath.]

The post Self-driving cars, Amazon, and networking appeared first on Plexxi.

Read the original blog entry...

More Stories By Michael Bushong

The best marketing efforts leverage deep technology understanding with a highly-approachable means of communicating. Plexxi's Vice President of Marketing Michael Bushong has acquired these skills having spent 12 years at Juniper Networks where he led product management, product strategy and product marketing organizations for Juniper's flagship operating system, Junos. Michael spent the last several years at Juniper leading their SDN efforts across both service provider and enterprise markets. Prior to Juniper, Michael spent time at database supplier Sybase, and ASIC design tool companies Synopsis and Magma Design Automation. Michael's undergraduate work at the University of California Berkeley in advanced fluid mechanics and heat transfer lend new meaning to the marketing phrase "This isn't rocket science."