Nati Shalom's Blog

Cloud-Native VNFs: What’s All the Fuss About?

---

This article was originally posted on Wireless Week on January 17, 2017.

---

Virtualized Network Function (VNF) vendors like Versa Networks, Athonet, and Clearwater are working to re-architect their VNFs for a cloud-native world. They’re doing this because VNFs –like any other application – can leverage the economies and agility of the cloud, if they’re architected as a cloud native-application. This transition can unlock tremendous value for the VNF vendors and their customers (telecom service providers and operators of large enterprise networks) by making network services agile, scalable, and API driven.

Where We Are, Where We’re Going

Many (probably most) network functions – think routers, firewalls, load balancers, and such – have already gone through the transition from physical appliances to virtual ones. Thus, they’ve become “virtualized” network functions, delivered via software that’s abstracted from the underlying hardware.

To be certain, this is a major evolution, but it’s only a step. The next step to cloud-native VNFs adds scaling and management efficiencies that give operators of large networks the same benefits for their VNFs that they’re currently enjoying with cloud-native applications.

Cloud-Native VNFs: What’s in the Box

Take a look at the main attributes that differentiate a cloud-native VNF from one that’s not. A cloud native VNF is:

• Automated, fast deployment, upgrading, and updating, all via APIs
• Simplified management
• Easy and automated scaling as network service demands change
• Lower upfront costs

However, most VNFs are packaged today as a virtual appliance, usually designed to run on a specific set of hardware. They were not designed for cloud-native architectures or hardware agnosticism, and they require human intervention for setup and deployment. They’re not API driven, and they do not support automated scaling as load demands fluctuate. Moreover, most VNFs do not support multi-tenancy.

By contrast, cloud-native VNFs scale easily via common APIs, enable visibility into additional devices in larger environments, and deploy to a wide selection of popular networking platforms. An important factor here is the use of open source standards already widely in use by telecoms and other operators of large networks, like TOSCA and YANG.

What Cloud-Native VNFs Deliver to Operators

All of the value provided by VNFs springs from their software-defined, API-driven nature. This makes deep automation possible, removing human intervention from the process and making fast, reliable deployment and operation possible.

Probably the biggest single value creator for operators requesting cloud-native VNFs is self-management. Cloud-native VNFs offer built-in automation for both installation and configuration. Most also support multi-cloud environments (VMware and OpenStack in the private cloud; AWS, Azure and GCP in the public cloud), which are an increasingly popular deployment and operations model for enterprises. The auto-scaling capabilities of cloud-native VNFs is critical in these environments.

Container support is becoming a bigger deal as well. Platforms like Docker Swarm, Kubernetes, Mesosphere, and CoreOS present new packaging models for VNFs, and cloud-native VNFs offer a shorter implementation path for containers than do their non-cloud-native counterparts.

Monitoring and analytics are a big plus in cloud-native VNF environments, too, as these capabilities are built into the architecture for things like failure detection, performance monitoring, and capacity management. A cloud-native VNF is aware of its behavior and performance relative to pre-defined SLAs, and can automatically trigger remedial action when something goes wrong (and something always goes wrong).

Multi-tenancy is another big win, as it directly impacts the bottom line. Cloud-native VNFs allow multiple users to share the same VNFs, so operators can serve more customers with fewer licenses and hardware.

Managing All those Cloud-Native VNFs: It’s Hard

Turning an existing VNF into a cloud-native VNF can be hard. And it’s not the only hard thing that needs to be done. All those cloud-native VNFs have to be orchestrated. There must be a services layer that manages all that nifty automated deployment, scaling, monitoring, and healing.

Early cloud-native VNF providers had no choice but to build their own proprietary orchestrators. Now there are open-source orchestration options like Cloudify, and they’re built using those open standards mentioned earlier (TOSCA, YANG, etc.). A good cloud-native VNF orchestrator lets VNF vendors and operators build out the management capabilities they need, with the assurance that they’re minimizing vendor lock-in by participating in an open community of like-minded operators, all of whom are trying to accomplish similar end goals with their cloud-native VNFs.

Engage With the Community

Swisscom, Proximus, and Telia had a great idea: they sponsored a Call for Innovation in the cloud-native VNF space. Their goal was to collect the best ideas and proof points for NFV and cloud-native VNF deployment and operations. More than 50 companies submitted entries, and 11 were selected as finalists. Early this year, these finalists will begin working with the three sponsor organizations on proof of concept deployments. This project is worth watching as a crucible for refining the best ideas in NFV, including the design, deployment and operations of cloud-native VNFs that solve real problems for telecoms and operators of large networks.

NFV and DevOps Converging to Bring Telecom Lessons to the Enterprise

---

This article was first posted on Telecom Reseller on January 9, 2017

---

American poet Robert Frost began “The Road Not Taken” with “Two roads diverged in a yellow wood.” But when looking at the quickening pace of transformation in NFV, it might be more appropriate for us to talk about how the two roads of NFV and DevOps are beginning to converge.

Forgive the lyrical mashup, but there is something poetic happening as the technologies and business models that underpin network virtualization mature. In the year ahead, we’re going to see the convergence of NFV and DevOps—developed by telecoms—making its move into enterprises. This “Enterprise NFV” shift will benefit enterprise operators of large, global networks and hybrid cloud deployments.

Telecoms like AT&T, Deutsche Telekom, Telefonica, and China Mobile embraced NFV in 2016, driven by the maturity of open source projects like OPNFV, Cloudify, ARIA, Open-O, OpenStack, and Kubernetes. At the same time, the business models for VNFs are beginning to modernize, adapting to fit modern, scale-out design principles. The result of these shifts is that enterprise operators of big networks are beginning to pay attention to what service providers have achieved with NFV.

This enterprise NFV shift allows for network management and orchestration services to become an integrated part of the application design and deployment process—DevOps. In essence, Enterprise NFV allows the network to “follow the app” through its lifecycle, automatically and dynamically configuring network services to facilitate application development, testing and scaling.

A simple example of this can be seen in the initial deployment of an application to a private cloud. That application is likely to need network changes like configuration of security groups, changing firewall rules, installing and configuring load balancers, DNS operations and IPAM management. Open source tools like Cloudify provide all the NFV orchestration needed to support this deployment in a DevOps setting, automating installation and deployment, monitoring of KPIs, and auto-healing and auto-scaling based on those KPIs.

That’s a reasonable example to illustrate how NFV and DevOps are already uniting for telecoms. Now, let’s consider a more complex—and more likely—scenario that we’ll see more and more of in 2017: hybrid cloud NFV for large enterprises.

As enterprises increasingly adopt hybrid cloud in the year ahead, they face a new level of network operations complexity. NFV and DevOps offer compelling benefits for scenarios like bursting, where the network must be automatically and dynamically reconfigured to adjust load balancing and traffic steering and to re-configure firewall rules and implement routing changes.

Similar to bursting, blue/green operations refers to load sharing between two clouds, which is useful for testing new applications or version in a controlled setting. It demands automated network reconfigurations as applications move from dev/test into production. The merger of NFV and DevOps gives enterprises using blue/green a telecom-proven approach to achieve this.

Enterprises benefiting from the union of NFV and DevOps in 2017 will look to standards-based orchestration to get them there, just like telecoms have with standards like TOSCA and open source orchestrators like Cloudify. Enterprises likely will want just one NFV orchestration manager, one that supports application deployment across multiple clouds (from VMware to OpenStack) as well as multiple data centers and availability zones.

The lessons of NFV and DevOps are moving from telecoms to the enterprise in the year ahead. By this time next year, it will no longer be “the road less traveled,” but rather a well-marked path for enterprises embracing DevOps and hybrid cloud. Choosing this path will make all the difference, and you want to choose it before your competitors do.

 

A Big Win to Kick Off a New Year

There’s no better way to start a news year than with a big customer win. In our case, it’s truly a “David vs. Goliath” win, a win that demonstrates how the market is embracing open source, underdog disruptors to take the lead.

Just a few short days after writing This post first appeared in Openness Is the True Path of NFV for SDxCentral, we received confirmation that we just closed a strategic deal with a leading telecom carrier, beating all the “Goliath” legacy players in the industry. We beat out a legacy player that was already the carrier’s preferred vendor, a supplier who assumed that continuing the relationship was just a matter of signing on the dotted line. Simple as that.

They quickly learned that it wasn’t that simple.

The legacy vendor offered its monolithic, proprietary, turnkey solution. They thought they were sweetening the pot by throwing in the orchestration layer: “it’s on the house.” But the customer realized that signing their deal meant committing to more lock-in, and they were ready to embrace an open source future in which they had more control over their own destiny.

Winning the deal is great all by itself, but the win validates the strategic importance of taking the open route over the proprietary turnkey approach. Here’s what I think is going on.

This win is a great example of organizational transformation manifesting itself in buyer behavior. This carrier decided to be bold and recognize the “dangers” as I describe them in the SDX Central piece. They realized that by working with any of the monolithic vendors they are basically signing on for yet another term of lock-in, neutering their entire rationale for taking the NFV journey. Proprietary lock-in diminishes the value of NFV, making those using it a provider or rather, a “simplistic” conduit to the legacy vendor’s services and features, limiting their ability to innovate and roll-out services that are unique to their offering.

The most interesting part was that with their decision to take the open, best of breed approach with Cloudify, they knew this decision would require more ownership on their part. They’d have to roll up their sleeves and work, compared to a turnkey solution. However, they also noted that this was actually one of the primary reasons they chose to go open—they were hungry to have better control of their destiny, costs, and ultimately their competitive advantage.

In 2016, we started seeing this coming. We’ve seen accelerating adoption of Cloudify among a growing list of leading carriers and across the NFV more broadly. We see this reflected in recent RFI activity as well. It’s clear to me that buyers are increasingly interested in embracing an NFV technology stack that is open, community supported and interoperable. Legacy vendors are having trouble pulling this off, and Cloudify has already proven itself able to deliver. It’s a good time to be the underdog!

We achieved a major milestone last year as well. A multi-year mega-deal with a North American bank who already was using Cloudify in production for several years decided to expand their Cloudify footprint. This bank that was looking for a way to regain control of their accumulation of “too much technology” by providing a scalable, one-click consumable way to provision heterogeneous “certified” environments, and ultimately manage and monitor them simply. Their experience with Cloudify told them that it was the way to go.

They chose Cloudify to build and expand upon their hybrid cloud—a 5,000+ VM deployment—across OpenStack and VMware infrastructure. Yet the more interesting aspect is that one of the key differentiators with Cloudify (it tipped the decision, in fact) was the convergence of enterprise IT and NFV—where the network orchestration piece has become key—and Cloudify’s ability to orchestrate across all layers.

So What’s Next?

We’re investing more around Azure support, and as a start we completed a case study on how a major insurance company is using Cloudify to manage their risk management application. Organizations are asking, “Azure or AWS?” and every hybrid cloud mix-and-match scenario is now fair game. Many enterprises are debating what to bet on for their cloud strategy.

Cloudify, in its orchestration-first approach, wants to make this a non-binding decision and ensure cloud portability between clouds and even the same cloud, such as Azure’s public and private cloud offerings. Azure is taking many strides to uniquely position itself to respond to the growing needs of enterprises, building a strategy around open source collaboration and enabling a hybrid stack approach. They are demonstrating that freedom of choice will tip the scales in their favor—not lock-in. And partners looking to spread the open gospel, are those that Cloudify always looks to work with.

Cloudify 4.0 and the Next-Gen Service Provider

Throughout our engagement during 2016 we came to the realization that there isn’t much difference among all large-scale multi-national corporations these days—whether a large bank, insurance company, satellite provider, telco or operator. IT engineering, network engineering, DevOps, and developers alike have all become “service providers” to either internal users or end users.

We have come to call these, “Next-Gen Service Providers”. These operators understand that it’s critical to be able to rollout new services rapidly, with little complexity in a repeatable and automated manner, all while controlling the process. The specific service that they deliver to their users can still be fairly different (Network services in the case of Carriers, and more standard web apps in the case of enterprises), but the way they need to deliver it and the cloud infrastructure in which they build upon is fairly similar and would rely on a combination of a hybrid cloud stack and containers as the common substrate.

This is where Cloudify 4.0 comes in. Cloudify release version 4.0 in Q1. It will be packed with features powering the next-gen service provider, and enabling fine-grained multi-tenancy, a simplified high availability architecture, more robust security, a new multi tenant portal designed to address the needs of both the end-users, through a simple one click catalogue, the operator that want a single pane of glass to control the user's activity and the power-user that is looking for full control to customize and tune the way the application is being managed.

Cloudify 4.0 will also include many new reporting and monitoring, SaaS Cloudify Composer, among many other UX improvements. We believe that this shifts Cloudify into a whole new domain, what we have coined as “Orchestration First Cloud Service Management”.

There’s Just One More Thing

All this change and market adoption of Cloudify has led us to move the Cloudify team into its own business unit at GigaSpaces. This way, our engineering, product management, sales, support, and other team members can focus on Cloudify, without the distraction of other products in the GigaSpaces portfolio. I’ll serve as CTO of the Cloudify business unit. It’s a reorganization that benefits our customers, our employees, our partners and the Cloudify open source community.

2017 is off to a great start at Cloudify. We look forward to seeing you and talking about how your organization is embracing agile, open NFV at events around the world.

If you are interested in meeting at Mobile World Congress to speak about multi-VIM, NFV MANO, please send us an email at [email protected].

Openness Is the True Path of NFV

---

This post first appeared in SDxCentral on January 2, 2017.

---

A recent SDxCentral contributed post asked, “Does NFV create vendor lock-in?” In it, author Shehzad Merchant posits that the current trajectory of network functions virtualization (NFV) is headed down a path of tighter vendor lock-in by virtue of “the use of specialized acceleration engines and network interface cards (NICs) for performance improvements within the server plus the use of dedicated, stateful load-balancer appliances to distribute traffic across servers.”

I applaud Merchant for raising the issue, but the important issue here isn’t the one he raises. Rather, the important issue is this: lock-in with NFV derives from proprietary solutions. Openness is the true path of NFV. It’s already happening. Here’s why.

We’re From Cisco, and We’re Here to Help You

First, the lock-in Merchant speaks of results from hardware vendors’ inherent conflicts of interest. They are biased toward promoting their own proprietary hardware extensions under the guise of “openness.” In direct contrast, let’s look at pure-play, open source options. Network operators have choices in orchestration and virtual network functions (VNFs) including (Cloudify, Clearwater, etc.) where openness is core to the model. When you look at the market from these two diametrically opposed views, you can begin to see how the open example promoted by AT&T is one that proprietary vendors like Cisco cannot follow.

Want Portability? Look Up the Stack

Next, we need to reevaluate our understanding of portability. Or, to use a worn-out business phrase, we need to “shift our paradigm.” To achieve portability, we need high-level abstraction—that is, abstraction at the orchestration level rather than the infrastructure level. The open-source Cloudify project offers examples that demonstrate how to achieve portability, not just between different infrastructure providers, but also between different software stacks.

You Say ‘Turnkey,’ I Say ‘Lock-In’

The allure of single-vendor, turnkey solutions is seductive. It’s also the road to lock-in, because you become increasingly dependent on a single vendor to develop, ship, and support every feature (or most of them) in the stack—regardless if the stack is open source or proprietary. Merchant misses this key point, as (paradoxically) do writers who think open source automatically reduces lock-in.

Making Open… Open

The open source alternative to proprietary NFV solutions requires a different engagement model between vendors and operators. Primarily, this means a partnership model that looks more like a joint venture relationship with the vendors that are part of the solution. This means that the carrier (or enterprise operator of a large, distributed network) needs to be part of the solution and not just the one that defines requirements for vendors. This isn’t as hard as you might think: there are growing numbers of open source solutions that can fill in the stack.

To help get you started, here’s a dirt-simple “openness” checklist:

• How simple is it to integrate new stacks/services without involvement from the vendor?
• Can I install or customize the solution for free without vendor involvement?
• Can it work with different clouds/infrastructures?
• Will it integrate with other—potentially competing—products?
• Are the open source projects on which it’s based supported by an active community where decisions are made inclusively via an open governance process?
• Does it support commonly accepted scale-out networking standards like topology and orchestration specification for cloud applications (TOSCA) and YANG?

If vendors pass these tests, you’re off to a great start.

“Turnkey by Default” is the Problem, not Openness

The NFV solutions Merchant is talking about fail to deliver a true open solution. I argue that the reason for this is that customers are voluntarily locking themselves in by asking for turnkey solutions, which lead them to lock in by default. To achieve a true open NFV solution, carriers must first embrace a best-of-breed approach, working with vendors offering business models that don’t conflict with their anti-lock-in needs.

Perhaps the question Merchant raises, “Does NFV create vendor lock-in?” should be modified to “Are carriers really ready to commit to an Open NFV strategy?” Because if they’re ready to change old habits, they can get an open solution that puts them in control, not their vendors.

If you are interested in meeting at Mobile World Congress to speak about multi-VIM, NFV MANO, please send us an email at [email protected].