Back in the distant past of the 70s, there were public service announcements with the catchy title Speed Kills, sponsored by the Do It Now Foundation. They warned teens about the very real dangers of death from taking the stimulant, speed. Ray Manzerek of the Doors did an LA radio show PSA about Speed Kills in ’69 and Frank Zappa has done a Speed Kills spot. Most recently John Travolta did a ravolta-ing movie entitled Speed Kills that scored a 0% critic score on Rotten Tomato. Yikes. Interestingly enough – speed kills is also a true statement in the world of cloud-driven networking.

Whaaat? In particular, one of the fastest-growing segments of networking is the management and orchestration of Wi-Fi and network switching from the cloud, running as an application. Think Aerohive, Meraki, and others. (Note, on August 9th, Extreme Networks acquired Aerohive and has announced ExtremeCloud IQ, which integrates a proven, third-generation cloud management architecture with Extreme’s end-to-end enterprise networking solutions portfolio). But being in the cloud and being cloud-native and cloud-driven aren’t synonymous.

One potential solution can be “in the cloud” with a widely-distributed privately-built cloud installed at a number of co-los. This approach uses whatever tools the builder thinks appropriate, but doesn’t benefit from, nor is aligned with, the mainstream cloud ecosystems that are driven by the top three hyperscalers. This means feature velocity is slow and the ability to add new classes of applications is limited. Another way to build a cloud solution is with a VM-oriented product hosted at a major cloud provider. This type of solution tends to be expensive to operate and is limited by the capabilities available on the hosted cloud. In both of these cases, it is generally true that the cloud can’t be configured to run in a hybrid private cloud model either. Further, since neither of these can fully take advantage of scale-out architectures, they require very careful human attention to avoid outages, which none-the-less do occur and can last for many hours or even into days.

The third model for architecting a cloud is to build a truly portable third generation cloud constructed from open source components using an advanced microservices-based model. This model has multiple advantages. First, being built using a microservices approach lends itself to a highly-automated and scale out-oriented solution. This enables a very highly-available system that is dramatically less likely to fail. Think seven 9s resiliency. Second, by careful design, this solution can be operated on any cloud, or an on-premise private cloud or in an enterprise hybrid cloud hosted in the customer’s cloud provider of choice. This offers a great deal of flexibility. For example, a cloud service for retailers might be hosted in GCP or Azure, whereas other customers may use AWS, and others may prefer an Azure-based solution. Most important however is speed, … and “speed kills”. In particular, a microservices model enables each component to be developed independently and at high speed. Think of it this way: a gen one or gen two clouds that isn’t a cloud-native microservices-based approach is like 40 different cooperating modules of software competing in a 40-person potato sack race. Can they all move together – sure. Can they go fast — no way. Microservices, by contrast, is more akin to these 40 modules each running at the speed they need or want, and all communicating over a multi-channel walkie-talkie. Dramatically faster. So, where does “speed kills” come from? In the evolution of any species or system, the species that can evolve the fastest also improves the fastest and in time it outcompetes the slower, clunkier species. The species left behind either die out or find a small survivable niche. Said differently, the quickly evolving species kill off the others – or said differently – “speed kills”.

A logical question might be – “what does this look like in practice?”. Here are some hypothetical examples. In the marketplace, each vertical industry may have an affinity for a particular cloud provider or cloud type, or each may prefer to avoid certain cloud providers for a variety of reasons. Retailers may prefer Azure or GCP over AWS for instance. Given how many enterprise IoT providers are working with Azure, there may be customers with a preference for an Azure cloud to ensure cloud-to-cloud communications stays within the same cloud. A healthcare provider may prefer GCP due to HIPAA requirements. Here, a third-gen portable microservices cloud could be easily available in each of these situations and could even be customized to the users of each cloud solution.

Another way that “speed kills” might express itself is in the way ML and AI tools are leveraged. This is super difficult in a first-gen cloud, not simple in a VM-like cloud, but can be especially powerful in a properly-constructed third-gen cloud. In a third-gen cloud, there are also a few choices. One solution is a do-it-yourself AI approach. This model can be highly optimized, but – it is generally slower to evolve and more cumbersome because it can’t leverage the underlying native cloud’s own rapidly-evolving toolchains and ecosystems. The “go-native” model takes advantage of the chosen cloud’s infrastructure for maximum efficiency and speed. Again – “speed kills”.

Yet a third-way “speed kills” benefits can be delivered is by the natural capability to introduce not only new features but entirely new classes of applications. Think about this for simplicity as new tabs on the cloud application itself. Clicking a new tab might activate a cloud security application. Click the free 120-day trial button, and away you go. What about a new network evaluation tab? You click the free trial button, and the app compares, contrasts, and benchmarks the performance of your network versus other similar-sized networks both within your industry and across other industries. You get the idea.

Last, here are some simple historic example of “speed kills”. Remember portable electronic devices called MP3 players? How about small portable devices called candy bar phones? There used to be a very useful handheld electronic organizer products people called Personal Digital Assistants or PDA for short. There used to be very small portable digital cameras, much less capable than my DSLR, but very handy when convenience was paramount. There used to be handheld voice recorders. There were even phone/email machines often referred to as a “Crack-berries”, otherwise called a Blackberry. All of these were killed by the smartphone. The smartphone started late by comparison, but the combination of speed through the app store and sheer convenience resulted in the death off all of these other products. Also, interestingly neither Apple nor Samsung was big players in any of the first or second generations of any of the other devices that went extinct. This simply shows the power of speed, – indeed.

This blog was originally authored by Chief Technology Officer, Eric Broockman.