Nati Shalom's Blog

The Amazon Effect on Open Source

This post first appeared in The New Stack on November 27th, 2018.

 

 

Cloud computing and open source are two big movements that are reshaping and continually disrupting the way we think about the relationship between vendors and consumers. It opened up the entire thinking behind even the most basic questions such as: What is the right business model? What is considered a product with value that is worth paying for? How much are we willing to accept vendor lock-in?

Cloud computing brought a completely new and agile way of thinking about the vendor/consumer business model with the pay-as-you-grow model and SaaS. This model forced vendors to become more efficient and accurate with respect to how they deliver their software and think about the value behind their product.

The world where the consumer was willing to pay for “shelfware” is long gone, as cloud has also empowered the consumer to be more sophisticated with the way they measure the value behind a product and make data-driven decisions.

With open source, the picture is a bit more complex. Linux and many of the first open source projects started as a commoditization strategy i.e. providing a free or “cheap” alternative to what used to be expensive software. Today, many of the open source projects are the drivers of new innovation and often rely on substantial funding to keep them going. While many of these products come with a free edition, they use an open core strategy in which the cost for the software is in many cases as costly as any other non-open source products.

So, what is the value of being an open source product if the cost is no longer the key driving force?

That’s actually a great question. I was surprised myself to see that many of the investors that I have met over the course of the past year have been challenging me with that question and have raised lots of skepticism about whether there is even a viable business model behind open source (Red Hat is considered a unicorn on this respect).

They had good reasons for that as they have been “burned” by investing in promising open source projects (OpenStack is one of the recent examples that came up frequently as a reference on this regard).

Obviously, this got me thinking about this question quite deeply, and I came to a pretty simple realization.

Open source changes the relationship between the vendor and the consumer from a relationship of mistrust and that of a passive consumer of a veritable “black box,” to a relationship of trust and partnership. Open source makes it possible for consumers to know exactly what they are getting before they buy the product, along with more ways to control the way they will consume a given product or shape it through code contribution, feature requests, etc. With non-open source technology, a consumer is dependent entirely on the vendor every step of the way.

The “free” part in open source also allows consumers to choose when to pay for a given product based on their adoption stage, and value that they are getting from the product. Many open source companies will allow you to use their products completely free with the assumption that as you grow and get more substantial value from the product, you’ll need support and specific hardening, and this is where they will see monetization. So, in a nutshell, open source allows consumers to pay for products only when they feel that they are getting enough value from them or want to grow with the value.

This post, however, is neither about open source principles nor cloud business models — but rather that nexus where they both meet and have changed and disrupted the entire way technology is now adopted as well as consumed.

The Amazon Effect on Proprietary/Closed Source Companies

2018 has been the year in which the key closed source companies have recognized that open source is not just a technology choice but plays a key role from a business value perspective:  scale.

Successful open source companies tend to scale much faster than closed source alternatives.

The trust relationship that open source companies often have with their consumer also creates a higher degree of loyalty, and thus stickiness, which is one of the key factors that leads to that difference in scale when compared with non-open source alternatives.

Non-open source companies have to battle for every deal and customer even within their existing customer base. With open source that process is quite different as, in many cases, the monetization process starts after the customer is already convinced and has been using the product for a while. Therefore, they would be much more receptive to moving forward quickly.

How is that related to the topic of this post?

Well, cloud is all about scale. Companies like Microsoft, and now IBM, have realized that we’re now in a land-grabbing war. If they can’t build a fast-growing, scalable engine they will lose the battle to AWS. When you think about it in those terms it now makes perfect sense why Microsoft and IBM were willing to pay such substantial amounts for the Github and Red Hat deals.

The cost of losing the war to AWS is far higher than the cost of those deals.

What’s interesting in the Salesforce acquisition of Mulesoft is that it shows that this realization applies also to companies that were “born in the cloud” and not just legacy vendors.

The Amazon Effect on Open Source Companies

The Amazon effect on open source companies is actually quite interesting as it is indicative of the mutual effect that cloud, and open source have on each other.

In the opening of this post, I described the key assumption behind the business model of open source. The key assumption is that the monetization often takes place when you make serious use of the product.

When Amazon started to provide managed offering of specific open source products, they were breaking right into the middle of this assumption. In other words, by offering a managed service for a product they didn’t develop, Amazon “steals” the fruit of monetization without having to carry the cost and investment of the actual development of the product.

That broke the entire “trust system” that stood behind many of the open source models. Open source companies such as MongoDB and Redis had to respond by taking a defensive move that eventually make their product less open. That defensive move damaged the most sensitive aspect, trust, between consumers and open source providers creating a negative effect on the industry as a whole.

Cloud Native Open Source to the Rescue

So, the question comes back to, what should the right relationship between open source and cloud providers look like?

As I was working on my keynote session for our first Cloud Native Days Tel Avivconference, the picture became clearer.

While cloud providers like Amazon are abusing open source products to their benefit, even at the cost of harming the open source community, other cloud vendors are seeing that as a weakness and therefore look at open source as an opportunity to break the current AWS monopoly and win more cloud business by demonstrating a “non lock-in” strategy with open source.

Google was the first to realize this with the launch of Kubernetes as an open source project. Kubernetes shows how a cloud provider (Google in this case) can take an active role in driving and contributing to open source projects, even at the risk of cannibalizing itself, by allowing other providers to offer the same offering and compete on the same stack.

That raises the question — what’s in it for Google?

The answer is actually pretty straightforward and is as true in a pre-cloud world as in a post-cloud world. It’s the same strategy that helped Google beat Apple in the smartphone business — launching Android as an open alternative to iOS.

Taking the open source route is an effective strategy to win the hearts and minds of developers. Kubernetes is a great success, and part of the reason for its success is because it’s not bound to a particular cloud provider. With that move, Google is winning the hearts and minds of developers, by not locking them into its platform. Google is creating a trust system with the developer community by making Kubernetes a great place to be, and part of the reason it’s such a great place is that they are invested heavily in contributing back to the platform.

What’s interesting to note about the cloud native ecosystem is that it helps balance the relationship between cloud providers and the consumer. Rather than competing on delivering a proprietary stack for each cloud provider, cloud providers compete for whoever has a better “home” to host this cloud native stack.

Coming back to the Android analogy, the Android community was also quite effective in driving the iOS roadmap and features, which were indirectly influenced by the competition with Android, and probably had a much stronger impact than any alternative. Similarly, I believe that the Kubernetes ecosystem will shape, directly and indirectly, how AWS will deliver its own services.

The Microsoft acquisition of Github and recent IBM acquisition of Redhat, as well as the smaller VMware acquisition of Heptio, follow a similar line of thought. Unlike Google, they took a shortcut of buying their way to the developers through a set of acquisitions. It remains to be seen whether this will lead to similar success. A large part of that depends on how much the big players understand the delicate trust system behind open source and how much they will maintain this trust system in their entire operation.

The size of the investments, specifically from Microsoft and IBM, is an indication that open source is a strategic move, so I tend to believe that they will work hard to make it a success.

Final Notes

Over the years there has been an ongoing debate whether or not open source has an important role in the cloud era, where software is often delivered as a service.

The business model behind open source was also challenged due to the high failure rate of many companies as well as the monetization threat on strategy by Amazon.

To me, 2018 will be remembered as open source’s breakthrough year. It is the year in which open source companies were able to prove their business valuebeyond a shadow of a doubt. It is the year in which open source companies went public and were valued substantially higher than other non-open source equivalents.

It is the year where major non-open source companies like Microsoft, IBM, and VMware, who have always had an ambiguous relationship with open source, joined the open source camp in full force. It is the year where the biggest software acquisition deal was made for a company whose entire business model is built around open source.

It is also the year in which open source is forcing all major cloud providers to finally agree on a common platform for delivering and managing applications, which is clearly backed by real numbers as can be seen in the recent Linux Foundation survey.

Which of the following data center types does your company/organization use? (CNCF Survey)

It is the year in which we’ve seen that production usage of Cloud Native Computing Foundation projects has grown more than 200 percent, meaning cloud native technologies, according to the survey.

So, is there a viable business model behind open source (in the post-cloud era)? Hell yeah!

Watch the talk in the video below:

What is edge computing?

This article originally appeared in Opensource.com

Edge computing is poised to boost the next generation of IoT technology into the mainstream. Here's how it works with the cloud to benefit business operations in all industries

Cloud computing has dominated IT discussions for the last two decades, particularly since Amazon popularized the term in 2006 with the release of its Elastic Compute Cloud. In its simplest form, cloud computing is the centralization of computing services to take advantage of a shared data center infrastructure and the economy of scale to reduce costs. However, latency, influenced by the number of router hops, packet delays introduced by virtualization, or server placement within a data center, has always been a key issue of cloud migration. Edge computing has also been a driver of innovation within OpenStack, the open source cloud computing project.

This is where edge computing comes in. Edge computing is essentially the process of decentralizing computer services and moving them closer to the source of data. This can have a significant impact on latency, as it can drastically reduce the volume of data moved and the distance it travels.

The term “edge computing” covers a wide range of technologies, including peer-to-peer, grid/mesh computing, fog computing, blockchain, and content delivery network. It’s been popular within the mobile sector and is now branching off into almost every industry.

The relationship between edge and cloud

There is much speculation about edge replacing cloud, and in some cases, it may do so. However, in many situations, the two have a symbiotic relationship. For instance, services such as web hosting and IoT benefit greatly from edge computing when it comes to performance and initial processing of data. These services, however, still require a robust cloud backend for things like centralized storage and data analysis.

Edge computing: a brief history

Edge computing can be traced back to the 1990s, when Akamai launched its content delivery network (CDN), which introduced nodes at locations geographically closer to the end user. These nodes store cached static content such as images and videos. Edge computing takes this concept further by allowing nodes to perform basic computational tasks. In 1997, computer scientist Brian Noble demonstrated how mobile technology could use edge computing for speech recognition. Two years later, this method was also used to extend the battery life of mobile phones. At the time, this process was termed “cyber foraging,” which is basically how both Apple’s Siri and Google’s speech recognition services work.

1999 saw the arrival of peer-to-peer computing. In 2006, cloud computing emerged with the release of Amazon’s EC2 service, and companies have adopted it in huge numbers since then. In 2009, “The Case for VM-Based Cloudlets in Mobile Computing” was published, detailing the end-to-end relationship between latency and cloud computing. The article advocated for a “two-level architecture: the first level is today’s unmodified cloud infrastructure” and the second consisted of dispersed elements called cloudlets with state cached from the first level.” This is the theoretical basis for many aspects of modern edge computing, and in 2012 Cisco introduced the term “fog computing” for dispersed cloud infrastructure designed to promote IoT scalability.

This brings us to current edge solutions, of which there are many. Whether purely distributed systems such as blockchain and peer-to-peer or mixed systems such as AWS’s Lambda@Edge, Greengrass, and Microsoft Azure IoT Edge, edge computing has become a key factor driving the adoption of technologies such as IoT.

Why proximity matters

Proximity, or low latency, is extremely important in business because data loses value as it ages. This is true for all industries, from financial to health and safety, shipping, and others. For instance, the medical industry used IoT when real-time monitoring and processing is critical to ensure that patients receive the care they require exactly when they need it. Another good example is e-commerce. In 2009, Akamai published a research report titled “Akamai Reveals 2 Seconds as the New Threshold of Acceptability for eCommerce Web Page Response Times”, which details the relationship between website performance and online shopper behavior. It found that 40 percent of consumers will not wait longer than three seconds for a page to load before leaving, as they become distracted or find alternatives. This research underscores the extreme importance of the speed at which you transfer, process, and return data to the customer, device, or internal user. Edge computing was designed specifically with this “need for speed” in mind.

Scalable and resilient

The distributed nature of edge computing means that along with reducing latency, it also improves resiliency, reduces networking load, and is easier to scale. Processing of data starts at its source. Once initial processing is completed, only the data that needs further analysis or requires other services needs to be sent. This reduces networking requirements and the potential for bottlenecks at any centralized services. Furthermore, with other nearby edge locations, or the potential of caching data on the device, you can mask outages and improve your system’s resiliency. This reduces the need to scale your centralized services since they are handling less traffic. The results can also reduce costs, architecture complexity, and management.

The future

Where will edge computing go from here? Over the next few years, we will see an explosion in this technology as more and more end-user devices use it to improve performance, functionality, and battery life. Where once edge devices were limited to smartphones, tablets, laptops, PCs, and game consoles, we are now seeing it employed in virtual reality headsets, autonomous vehicles, drones, wearable tech, augmented reality devices, and more.

The prevalence of IoT devices is skyrocketing, and this expansion seems set to continue for some time as industries such as healthcare, mining, logistics, and smart homes are just starting to incorporate IoT technologies into their business models.

Regarding the technology behind edge computing, we will see a decoupling of many existing cloud technologies from their centralized roots. Services such as AWS Lambda may be overhauled to run functions at the edge location nearest to the request’s origination point rather than being region-locked. We have already seen the first signs of this with AWS Lambda@Edge.

We will also see the maturing of emerging edge technologies such as blockchain and fog computing. There is a lot of excitement about blockchain’s potential, as its decentralized system and complex algorithms have applications far beyond Bitcoin. Potential uses include both logistics and voting, where it could help with security and fraud prevention.

Edge computing could potentially eclipse cloud computing in terms of scale and market cap. But it will not likely replace cloud, or even reduce its market cap. Rather, as edge matures, cloud computing will grow along with it, but at a slower pace, thereby providing many back-end and support functions for edge computing and business operations.

 

 

The Cloud Native VNF Explosion at MWC18

VNF Onboarding is known to be one of the biggest challenges in the transformation to NFV transformation as noted in one of the recent SDxCentral report: VNF Migration challenges.

Arguably the biggest challenge organizations will face when it comes time to operationalize VNFs is a lack of processes. Many IT organizations are in the throes of managing complex transitions to modern DevOps processes. The typical network service team has no operational processes in place for deploying and managing VNFs. On top of that, add the need to secure those VNFs and make sure they meet compliance mandates and it could be several years into the next decade before VNFs are commonplace.

Current Approaches to VNF Automation -  Challenges and Limitations

To date, the primary approaches to addressing this challenge have only had various degrees of success, these include:

• Homogenizing all VNFs through a common information model:

ETSI and other standardization bodies have tried to “homogenize” all VNFs through a common information model represented by a VNF descriptor. The main challenge with this approach is that it requires a lowest common denominator approach for VNFs which prevents them from showcasing their unique capabilities - and when you start adding unique features to a VNF descriptor the whole idea of normalization just renders itself as not valid anymore. As a result, vendors are not eager to adopt a common information model, as it increases the cost, while not providing much of benefits in return.

• Generic VNFM delegates integration effort to the end user

The other approach (also supported by ETSI) has been to define a generic VNFM for all VNFs, which basically moves the challenge of automating the management of VNFs from the vendor to the end user.  The basic premise behind this approach is  the assumption that you can leverage common information model in the form of a VNF descriptor.  Many customers have tried to deal with this challenge by creating complex on-boarding and certification processes, however these processes still leave the heavy-lifting of automating a huge complexity in the hands of the customer, making the entire on-boarding process still very costly and slow.

• The Cloud Native VNF Approach

The move to a cloud native operational model is expected to disrupt this entire thinking.

The Cloud Native VNF approach places the responsibility of simplifying the operational model of a VNF to the VNF vendors themselves to define an opinionated architecture on what’s required to deliver a cloud native service that supports dynamic services like auto-scaling, healing, upgrades as built-in features.

Many of the new generation network services such as SD-WAN and vCPE were built with this architecture in mind.

The challenge with this over-the-top approach is that these next generation network service providers also took the entire operational challenge of delivering those services through SaaS models, and in many aspects make carriers fairly redundant.

The other challenge is the transformation challenge. Many of the existing VNFs were not built for cloud native environments, and therefore need to undergo a fairly large transformation to fit into the cloud native world, and this has proven challenging.

A Pragmatic Approach to Making Cloud Native Network Functions Possible

Over the past few years we've gone through the experience of trying all of the approaches mentioned above, and realized that none of them have really solved the VNF automation challenge alone.

Another key finding is that the model of taking a VNF which was set to be a standalone virtual appliance and turn it into a cloud native service, with full automation of the entire operational model, cannot be easily achieved without a strong commitment by the VNF vendors.

The attempt to force such a commitment from the end user isn’t good enough, as every end user - whether carriers or enterprises, have its own way to define the rules for certification. The thought that this level of automation can be fulfilled as part of the carrier’s domain is also broken as it will break with every new release of the VNF. That made us realize the right path would be to make sure that VNF are set to be self-managed before they even get to the end user, and that should be the responsibility of the VNF vendor.

That is how we developed a more practical and pragmatic approach to enable the transition to Cloud Native VNF, which is basically a combination of all three approaches that I outlined above - let me explain:

1. Embedded VNFM   - provide a lightweight, open-source software orchestration package that can be embedded and white labeled as part of a VNF vendor’s software package, taking care of all the generic aspects of the transformation to cloud native architecture, such as full automation of the deployment and configuration process, as well as automation of day-2 operation such as upgrades, healing, scaling and any other dynamic services required by cloud native environments.
2. Simplify the transformation to Cloud Native - The approach that we took was to support pure cloud native architecture through extensive support for Kubernetes, while at the same time also supporting virtual appliances, thus allowing a mix of virtual appliances alongside microservices managed within the same automation framework. This significantly reduces the transformation challenges as it doesn’t force a complete rewrite, and allows a more gradual transition to pure cloud native architecture while at the same time providing closed loop automation of the entire hybrid stack.  
3. Just enough standards - Focus on interoperability and integration between existing VNF information models rather than forcing a common information model. This is done through a specific universal configuration management of VNFs. The universal configuration management makes it possible to manage the configuration of a large variety of VNFs through a combination of a simple configuration data structure based on TOSCA. This takes care of the configuration properties that need to be set as part of the automation process, and does not require that this serve as the entire data model of each VNF.  In addition, another important aspect is being able to push updates through integration with existing protocols and formats that are already supported by the VNF, including YANG, XML, REST, JSON, Ansible over Netconf, Telnet.
4. Collaboration with carriers to deliver an open network management platform (namely though ONAP) - In order to make this entire process fully operational we are working on one end with many VNF vendors directly to provide cloud native functionality, while at the same time contributing the same principles and even software as part the ONAP project’s Service Orchestrator and Operational Management components.
5. Multi-cloud support - Most of the end users run on their own VMware or OpenStack data center and are now starting to expand into public clouds. VNF vendors require multi-cloud support for different reasons. Multi-cloud allows VNF vendors to fit naturally into their customer’s environment, and thus expand their target market. Having the infrastructure abstracted from the VNF service provides a greater degree of flexibility.

All this combined makes the transformation of  VNFs themselves to cloud native more practical. It also makes the entire end-to-end automation of the operator network services more consistent and cloud native.

Cloud Native VNF Explosion at MWC18

I first started to experiment with the idea of Cloud Native VNFs during a meetup in late 2016. This work was largely inspired by extensive work with VNF vendors such as Metaswitch, Athonet, Versa and Brocade. We then launched a Cloud Native VNF partner program and have also partnered with VMware and Intel to deliver the first VNF on boarding hackathon during MWC17 and this is where it became clear to me that we were onto something that could finally solve the VNF automation challenge.

Around the same time we joined ONAP which ended up adopting both TOSCA and Kubernetes as part of its cloud native strategy which brought even stronger support and validation to this approach.

Having said that, nothing prepared me for what we’re experiencing in MWC18. Over the past few weeks we’ve been notified by our VNF, infrastructure and technology integrator partners that they will be demonstrating their integration with Cloudify during the event.

This is a good opportunity to list where you can see Cloudify in action at the very noisy MWC event:

• Fortinet - Cloudify and Fortinet have been partnering closely through the Fortinet Fabric Ready partner program.  Cloudify has built a solution with Fortinet to deliver TOSCA-based security orchestration for their best of breed security appliances.  Cloudify makes it possible to deliver dynamic services for all Fortinet VNFs across any cloud environment.  
  • Visit the Fortinet booth - Hall 7 Stand N91 - at MWC to catch Cloudify in action delivering presentations daily on The Benefits TOSCA-Based Security Orchestration
  • Watch the recent webinar with Fortinet
  • Read the Solution Brief
• 6Wind - You can visit the 6Wind booth - Hall 5 Booth 5B85 - to see a demo of Cloudify Manager serving as the VNF Manager and NFV Orchestrator functions for the 6WIND vRouter. 6WIND's virtual appliances are instantiated on OpenStack, and OSPF routing and IPsec VPN tunnels are configured, deployed and orchestrated by Cloudify with TOSCA based templates. The solution is then monitored by Grafana out of the box or any other pluggable monitoring platform of choice.
• NetNumber - NetNumber recently announced the integration of their TITAN platform with Cloudify to orchestrate the deployment as well as on-boarding, service chaining, and management of its various VNFs and specifically their signaling systems. With Cloudify as the VNF Manager (VNFM), the TITAN Master is deployed onto OpenStack and then automatically on-boards the TITAN Edge nodes and connects them to the Master. Cloudify then also automates scaling or healing of the nodes as needed based on metrics with policy management.  This demo will also be available at the Netnumber booth - Hall 7 Stand 7D81.
• Metaswitch and Cloudify have been partnering on a community level for a number of years, and have recently moved to a business engagement where Metaswitch has selected Cloudify and will OEM Cloudify’s virtual network functions management (VNFM) capabilities in delivery of its own VoLTE TAS, vSBC and vIMS VNFs.
• ASOCS - Using Cloudify’s open source automation manager, Cyrus will be fully automated and orchestrated in accordance with ONAP.  Using Cloudify’s open source automation manager, Cyrus will be fully automated and orchestrated in accordance with ONAP. Cloudify Manager detects a policy in the blueprint that meets the condition, and automatically triggers a healing workflow. If Cloudify Manager detects an overload of resources, then it automatically triggers a scaling workflow and adds more capacity. Meet ASOCS at Hall 2 Stand 2E50 and see the demo here.

We are also starting to see VNF vendors using the integration with Cloudify not just as a means to transform their VNFs to fit into virtual and cloud environments, but as a means to extend their offering to their customers by turning their VNFs into a full-blown cloud native service that combines multiple network services as a solution, such as we have seen with MetaSwitch and Fortinet.

Other VNF vendors such as F5, Athonet, Cataleya IMS, Mavenir vEPC, Versa, Affirmed already support or are in the process of adding support for Cloudify as part of their VNF offering.

This also adds to other VNF support that was led by our customers which include Cisco CSR, Juniper CPE and Palo Alto firewall.

Cloudify & VMware

In this demo VMware will be showcasing a Distributed VoLTE Core Deployment with Kubernetes scenario demonstrating full deployment of a VoLTE core using Cloudify to deploy Metaswitch IMS + Affirmed EPC + Ixia test + Hawkeye monitoring in multiple instances for MVNO topologies.

In addition to that, VMware & Intel will be hosting an open VNF on-boarding hands-on technical session. Cloudify will participate in this session on Tuesday, February 27th, at 2:00 PM (CET) in the Dell/VMware booth in Hall 3, Stand 3K10.

Cloudify Solution Partners

Other solution partners have chosen Cloudify as the open platform to be able to build upon to deliver turnkey solutions to their customers. Such partners include our partners in Asia - Aptira, NTT Data, and in Europe such as Kapsch and Amartus  As well as global partners such as Tech Mahindra and ATOS.

• Tech Mahindra will be demonstrating ONAP running on Kubernetes using Cloudify.  Visit them at: Hall 2.1 Stand 2.1C19Ex, Hall 2.1 Stand 2.1C14Ex, Hall 2.1 Stand 2.1C23Ex, Hall 2.1 Stand 2.1C21Ex
• HCL will demo an orchestrated deployment of multi-slice core network (vEPC) on a distributed NFV Telco Cloud scenario using Cloudify. The Mobile terminals (UE) will be able to connect to different network slices based on required service capabilities making use of two different clouds (VIMs) with following characteristics: Main cloud: OpenStack Liberty based (OPNFV Brahmaputra), and Edge cloud: Openstack Ocata based (Openstack Kolla project tag 4.0.3).  Find them at Hall 2 Stand 2H40.
• Kapsch & Advantech will be leveraging Cloudify to supply the orchestration of both CPE-based and cloud-based central management for the CarrierCom and uCPE use case on white boxes.
• We have also been seeing exciting projects made possible through excellent partnerships in APAC including our co-members of the LFN & OpenStack communities, Aptira, as well as Lumina, who have been working with us to deliver carrier-grade orchestration projects with some of the largest service providers. Find us at any of our partners' booths to see this integration in action.

Final Notes

For me, the most exciting part of this is that most of this development occurred organically and was driven by the VNF vendors or customers themselves which demonstrates the power of open source.

The fact that Cloudify is open, and built to be lightweight and embeddable, both from a footprint perspective (Cloudify fits into a single container or VM) as well as through the support of a white label user interface, makes the integration effort with existing VNFs fairly simple and has proven to be a strong differentiator for Cloudify versus other orchestrators in the space.

In addition, being the leading TOSCA orchestration platform that is already integrated with ONAP and Kubernetes, on top of the support of a wide variety of cloud providers such as VMware, OpenStack, AWS, Azure, GCP allows VNF vendors to check mark all these features into their product through the embedded VNF integration.

Over the past year we also added extensive support to simplify the configuration of a large variety of VNFs out of the box, and without the need to write custom integration code through a generic configuration plugin. This makes the effort of VNF on boarding and even complex service chaining of multiple VNFs pretty close to a “lego play”, where you can easily create a composition of VNFs through a reusable blueprint configuration.

This shows the difference between taking the pragmatic approach to just enough standards to the attempt to harmonize all the VNFs through a common information model.

By focusing on enabling automation through interoperability with existing VNFs, and at the same time making a smoother transformation to the cloud native world possible we achieve a faster transformation to NFV and at a significantly lower cost.

Indeed we've seen major success with this approach with service providers such as Proximus selecting Cloudify as their key orchestration. Two other service providers won the Layer 123 award for integration work Cloudify is proud to be a part of:  Telstra for Culture and Diversity and  Partner for Best vCPE/uCPE, and we expect to see others joining this success shortly.

SD-Core

Is networking becoming cool again?

About 20 years ago there was a big wave of networking innovation, spurred by the Internet age. It gave birth to huge networking companies like Cisco, Juniper, and Ericsson. Then, the pace of innovation just kind of stagnated. However, the recent acquisition of Viptela by Cisco at $610M and even more recent acquisition of VeloCloud by VMware at an estimated (whopping) value of $1.4B have changed the game, and they definitely suggest that virtualisation is setting the networking market on fire again.

During the time when data centres were undergoing the revolutionary transformation to cloud, the networking industry basically skipped this entire evolution.

Which begs the question, why?

From the internet age to the cloud

Starting in approximately 2011, the second wave of major transformation began to present itself in the networking industry, starting with major acquisitions like Cisco with Tail-f, and VMware’s acquisition of Nicira—leading to a world where the service and configuration model started to take centre stage.

Networking, unlike compute or storage which are mapped into a single box, is much more complex and is comprised of many services (AKA functions), which can begin with the IP-tables, Wi-Fi and network cards in your operating system, and continue into corporate services such as firewalls, load balancers, routers, DPIs, VPNs and many more.

So virtualisation of the network essentially requires a virtualisation of all of those functions, making the task of virtualising the network significantly more complex, and slower to happen.

On top of these complexities, network services are extremely sensitive to performance. Time was needed for virtualisation technologies and networking hardware to evolve and deliver acceptable performance through specific hardware acceleration such as CPU pinning, SR-IOV, and such. This kind of acceleration also had to be supported by cloud providers and their cloud platforms, which took still more time.

So... what’s changed?

As with many transformations there are many factors that must converge to move the industry through a major evolution. In this case, the following factors accelerated network virtualisation:

• Competition from web-scale companies—Google, Facebook and Amazon Web Services built their own networking infrastructure based on commodity infrastructure and software-driven networking. This was a critical catalyst proving that network virtualisation can be delivered at massive scale while still delivering the necessary performance through software-driven network services and commodity hardware. Proof of that can be seen by the project and case studies presented at the Networking @Scale 2017 event, which showcased many of the open networking projects developed by web-scale companies.

• Cost pressure on carriers—It's no secret that carriers are facing huge cost pressure. While they have an increasing demand to expand their network bandwidth, they have no way to monetise on this investment. Therefore, they are forced to reduce their cost of operations as an immediate mitigation plan.

• Business disruption—Netflix, WhatsApp, and Skype provide over-the-top network services at a fraction of the cost and disrupt the core of carriers’ former revenue sources.

• Technology maturity—Virtualisation technologies, coupled with hardware accelerators, now make it possible to run network services with high performance and predictable latency, just as one would with dedicated hardware.

• Market demand—Manual network management worked on a centralised and relatively static network environment. The move to cloud and multi-data centres leads to a more dynamic network environment. Therefore, manual practices are becoming unmanageable and costly.

• Emerging startups—New entrants have played an important role in this transformation. Unlike incumbents like Cisco and Juniper, startups play the disruption game, bringing new, software-only approaches built for the post-cloud era.

The network virtualisation and orchestration market

Different reports show that the network virtualisation marketis expected to reach the hockey-stick in 2020 with $12.4B in NFV software, while edge computing is expected to drive faster and bigger growth and reach to $19.4B by 2023.

The Orchestration market is expected to grow at an even a faster rate according to the Cloud Orchestration Forecast and Multi-Cloud Management Forecast by Market and Markets:

“The cloud orchestration market is estimated to grow from $4,950.5 million in 2016 to $14,172.5 million by 2021, at a CAGR of 23.4 per cent. The key forces driving the cloud orchestration market include growing demand for optimum resources utilisation, increasing the need for self-service provisioning, and flexibility, agility, and cost-efficiency.

The multi-cloud management market size is expected to grow from $1,169.5 million in 2017 to $4,492.7 million by 2022, at a CAGR of 30.9 per cent.”

It’s also interesting to see the strong correlation between the multi-cloud market and the telecommunication business, which is expected to be the biggest vertical in that segment:

“Telecommunications and ITES is one of the most significant verticals in the multi-cloud management market. Multi-cloud services and solutions are used in this vertical for various on-demand services, depending on the Call Detail Records (CDRs).”

 

 

The worlds of DevOps and network virtualisation are converging. The same concepts that brought about the DevOps transformation in the enterprise are now changing the networking industry. The same forces are at work here: the need for more lean and agile rollout of services, automation and orchestration at the core, software-defined everything, self-service, open source, and provisioning of on-demand and dynamic services. This is the new networking reality. The stars are aligning to bring new DevOps concepts into the world of networking, at scale and more openly.

The network virtualisation future

 

Yes, the network is now becoming cool again, being at the centre of the transformation of an entire industry moving towards agility, self-service, automation and web-scale. On top of this, all these transitions are largely based on concepts of open source, that had the power to change entire industries—from the operating system, through the mobile market, now all the way down to the networking layer.

All this didn’t happen overnight, and there was a gradual transition to make this transformation a reality.

As 2018 dawns, it’s a good time to see how the network virtualisation world is evolving.  This, to me, can be broken down into three “generations” as I see them:

First generation: Network virtualisation

The first stage was led by ETSI and defined the general architecture for enabling network virtualisation. The architecture was adopted by many carriers and played a key role in setting the market, creating a common taxonomy of the key layers.

This ETSI definition introduced the concept of orchestration as a key component in the network virtualisation architecture, as outlined by ETSI MANO which is separated from the infrastructure (VIM) and OSS/BSS.

ETSI - MANO Architecture

The challenge with first-generation virtualisation is that it forced a fairly big change on how carriers operate. This was a big undertaking not just technically but also culturally.

 

That made the adoption of NFV extremely slow, especially by second- and third-tier carriers who couldn’t afford the investment required to make the transition.

 

A bigger challenge was the fact that all the standardisation efforts behind ETSI NFV were for the most part led by the same vendors who didn’t really have an incentive to drive such a big transformation, which ultimately would result in major cannibalisation of their own core business.

The result was that many of the NFV players ended up using the ETSI model mostly as a way to sell the same thing but dressed up in modern technology, but the actual product—and more importantly, the business model—didn’t change much to fit into the cloud world.

Second generation: The move from network appliance to a network service

 

Second generation network virtualisation is led mostly by new startups such as Meraki, Viptela, VeloCloud and Versa. These startups brought a more narrowly scoped solution for specific and common use cases such as SD-WAN and vCPE, repackaging formerly complex problems into new and exciting products that deliver an excellent user experience and are easier to consume.

The key to their success was that rather than changing the entire networking backbone as a first step, these services were offered as new, over-the-top services.

vCPE and SD-WAN solutions first target moving from manual setup and configuration of the WAN network to self-service network management of all the network configurations.

SD-WAN Self Service Management of branch office network management

The key challenge with this approach is that we're trading one closed source solution for another. Most of these solutions are still fairly proprietary, and come with their own set of network functions, their own flavour of protocols, and management systems.

 

The move of network services to a software-driven model makes it accessible to applications and developers. It is expected that the control of network infrastructure will follow a similar shift to be more application controlled, similar to how this happened with compute and storage infrastructure.

Current SD-WAN/vCPE solutions were not designed for DevOps processes. Rather, they were targeted mostly to network operators. Today we are looking towards more ecosystem partners that will drive these processes and provide dynamic management layers to enable best-of-breed networking stacks.

Third generation: Cloud native and the move from Software-Defined Networking (SDN) to Application-Defined Networking (ADN)

 

The move to cloud-native networking will commoditise network devices including CPE devices, and we're already seeing open CPE alternatives as covered by Nikos Andrikogiannopoulos on the x86 based CPE devices such as pfSense. In addition, the Open Compute Initiative (OCI) is driving a proposal for an Open uCPE, which a list of network vendors already agreed to support.

 

Other network services such as Quagga, and Calico as well as Metaswitch Project Clearwater are another example of new, mostly open-source and cloud-native network services.

 

In this cloud native world, the control plane moves from the device to the cloud, thus transferring some of the heavy lifting from the device to the cloud, further reducing the cost of the device itself.

 

This moves the shift of value from the network device into the control plane, itself as pointed out by Andrikogiannopoulos:

 

“By transferring control plane functionality in the cloud one can lower CPU/RAM requirements and do the heavy lifting on the cloud side. This SDN/NFV approach will allow faster delivery of new functionality/services at lower cost. Services like NAS storage, parental control, VPN/cloud gateways, CDN functionality, etc. Firmware upgrades can become as easy as iPhone upgrades.”

 

In addition to commoditisation of the network devices and the move of the centre of gravity to the cloud, I expect that networking will be driven by the application, and not just by network operators.

 

This move has already happened with compute and storage infrastructure, and it is fair to say that today most of these resources are software driven.

 

I see a number of reasons why the network should follow a similar path, like:

 

·         The fact that networks should be managed as part of the lifecycle of the application. Today, when networks are managed separately from the application, we see lots of firewall, ports, load balancer rules that are left open even when the application that needed them doesn’t exist anymore or has changed. This needs to change.

·         Likewise, the move to multi-cloud and edge computing is forcing a more dynamic and ad-hoc network environment where it isn’t even always possible to know which network needs to be created beforehand.

The security case for application defined networking

 

Network security is applied today mostly as an afterthought. Many of the network security products were designed to identify malicious behaviour by tracking packet flows. In addition, a central firewall can’t be the sole gatekeeper especially when we're moving to multi-cloud or even more distributed environments such as edge computing.

Instead, what is needed is the ability to create micro-firewalls that will be created per application and ensure that only the right set of services will be exposed to the outside world. Such definitions will follow the application as it moves from one environment to the other or be deleted when they are not needed anymore.

Application Defined Networking

I expect the move to Application Defined Networking to have a similarly disruptive effect on network operations as we've seen previously with the effect of DevOps on data centre management. This shift will also include a shift in power from the network operation to the application owner.

The move to open networking

These three phases in network virtualisation have created an industry ripe and ready to embrace more open solutions that have industry-wide adoption, creating a more standardised method of operation and best practices that will enable carriers to remain relevant and adopt new technologies more quickly.

The open networking promise is more real than ever, and the industry is converging around new and exciting projects to help deliver real world implementations that are applicable at the scale and distribution required today from multi-cloud to the edge.

Why Do I Need * If I’m Using Kubernetes?

I’m just returning from the Kubecon Austin event and I must admit that the vibe, and the amount of innovation, around Kubernetes reminded me of the good old OpenStack events. Now that Docker Swarm seems to be dropping behind, it definitely feels like Google and Kubernetes are killing it.

 

During the event we announced our latest Cloudify release with a spotlight on the new Go-based Kubernetes provider that gives Cloudify the ability to be used as a Kubernetes infrastructure provider and cements our position as a first-class citizen in the community.

 

The event gave us ample time to meet many friends and customers and hear their take on all this. A common thread I noticed in all of these community events is the general feeling that once a platform reaches peak momentum we all feel that there is nothing else in the world but that platform.

 

This general sentiment - that kubernetes is killing it - was followed by a question that I kept hearing: “Why do I need ‘*’ if I use Kubernetes? Where you could replace ‘*’ with a long list of technologies starting from Virtual Machines, Networking, Configuration etc. Interestingly enough, we can now add Docker Swarm to that list!

 

In this post, I want to address this question specifically, and hopefully give some much needed perspective. I’ll start with a quick historical recap to refresh our memories.

I know I’ve heard this before

I remember when Java came into the world it also felt that the world would run on Java only, and the other technologies would be hung out to dry.

 

Technologies that changed the landscape

 

I heard the exact same thing when AWS, OpenStack with Heat, and CloudFoundry came out - and the list goes on. In retrospect, it’s clear that, while each of those new technologies changed the technology landscape, none was ever the platform to rule them all. I found it surprising that, over and over again, we seem to keep coming back to the assumption that the next big technology will be the only platform you will ever need and replace everything else. To answer that question let’s examine the most recent event with Docker and its Kubernetes alternative, Docker Swarm.

Remember Docker Swarm?

Until very recently Docker and Docker Swarm have been the darlings of the cloud-native world. Docker gained huge adoption in record time, and at the time it seemed that they would rule the world - and that essentially, VMware, Redhat, etc would wilt away. Docker’s challenge, however, was that it was too successful for its size. When the company tried to take too much ownership over its technology the industry responded with Kubernetes which united all the rest of the world around the platform, and basically marginalized Docker into a small container niche. That entire move, from being at the top of the heap, to now moving to the bottom of the stack in roughly two years is a lesson that we should all learn from.

 

So, what is this lesson exactly? The only constant is change!

Some things never change - the Disruption Cycle returns

The speed of innovation has accelerated significantly over the past century and reached the point of singularity. The speed of adoption, however, has remained fairly constant due to the fact that the adoption cycle hasn’t changed much over the years.

The speed of innovation exceeds the speed of adoption which leads to companies building a hybrid stack comprised of the old stack, current stack, and “must-have” stack.

This inevitably leads to organizations adopting new technologies without leaving sufficient time to transition from their legacy businesses. Over time, this means lots of silos are created per technology such as programming languages (i.e. Java, Python, Ruby, Go), Cloud Infrastructures (i.e. VMware, OpenStack, AWS, Azure, Google), and Application Platforms (i.e. Docker, Kubernetes).

Our recent 2017: State of Enterprise Multi-Cloud Report provides many interesting insights that highlight this issue as can be seen in the infographics below:

 

How fast do organizations adopt new technologies?

 

 

This difference between “speed of innovation” and “speed of adoption” leads to what I called, in one of my previous posts from 2015, the Disruption Cycle. Back then the trigger was the Dell/EMC merger - does anyone still remember that? Unlike what most people tend to think, the disruption cycle doesn’t distinguish between legacy companies and new startups; it can, and will, hit companies of all sizes and ages.

 

The Disruption Lifecycle (circa 2015)

Moving everything to a single (new) platform is not a strategy!

If one of your architects tells you the best strategy is to move everything into a new and promising single platform, with the argument that the world will be cupcakes and rainbows and all your problems will go away - fire them!

This was true for Docker Swarm and CloudFoundry, and there is no reason it wouldn't also be true for Kubernetes as we are already starting to see the next wave of disruption on the horizon with Serverless etc.

Instead of trying to continually jump on the bandwagon of the next big platform, a more robust, thoughtful strategy would be to assume that the world will always change, and it will be comprised of multi-site, multi-cloud, multi-stack environments. We need to design our strategy with that assumption in mind. This is true for Kubernetes just as it was true for other platforms.

Kubernetes in the hybrid stack and multi-cloud world

Automation-first approach

Generic orchestration platforms such as Cloudify, Terraform, and others provide automation frameworks that can integrate with all these different platforms and thus supply an end-to-end service automation approach by calling the right platform at the right time without the need to move everything to the new platform as the first step.

 

Cloudify orchestration enables automation of multi-stack, multi-cloud, on multi-site

 

 

Interestingly enough, this approach also helps to indirectly smoothen the migration process into the new platform as it allows the organization to move each service, one at a time, making the transition more gradual and less risky. At the same time, there will always be cases where it wouldn’t make sense to move certain services - some will simply retire over time - so the effort of transitioning them doesn’t always makes sense which again leaves us with a hybrid stack situation that will remain hybrid for a long while.

Summary - Benefits of Orchestration First

In summary, the key takeaway I am trying to make is that we need to assume that change is inevitable and we have to plan our strategy with that assumption in mind. Automating first allows us to integrate the new platform with the existing environment rather than replace or migrate everything, at least as a first step.

The automation- / orchestration-first approach comes with the following benefits:

• Faster time to value - don’t migrate first; automate first, then migrate!
• Gradual and less risky transition to the new platform - one service at a time.
• Faster adoption of new technologies - The ability to integrate and add any new technology without breaking what’s already working allows significantly faster adoption of new technologies.

Cloudify Momentum Accelerates, Exceeding Second Quarter Projections

Last quarter we launched Cloudify 4, a major milestone transforming Cloudify from a DevOps tool to a complete Application and Network Management Platform. This is highlighted by the addition of an enhanced customizable portal, based on React, with an emphasis on multi-tenancy and security in addition to our continued support for container orchestration through integrations with the Kubernetes, Docker Swarm and Mesos platforms.

Version 4 was part of a more significant move to introduce a whole new thinking of how next generation cloud application management should be built. As part of that play, we also launched a new website (cloudify.co) and branding which reflects this change.

Cloudify 4 played a big part in both the previous and current quarters’ wins, the current exceeding even last quarter’s results and target revenue by 60%.

In addition, there was a GlobalData report which puts Cloudify as the leading open MANO orchestration framework with the largest number of deployments amongst 13 vendors who were evaluated in this report. This comes on top of other mentions in this Light Reading report as well as an OPNFV eBook covering their vCPE and vIMS (Clearwater) use case powered by Cloudify orchestration, which puts Cloudify as the leading reference implementation for open NFV orchestration.

In this post, I wanted to highlight the key achievements from Cloudify second quarter results of 2017 and how they fit into our overall strategy.

Key Achievements

Open vCPE Wins

Last quarter we launched a new Open vCPE solution which introduced an orchestration-first approach to NFV. The orchestration-first approach aims to address one of the biggest challenges for providers with the current infrastructure-first approach to NFV - namely, the ability to integrate with existing networks. According to a recent IHS survey this has been a concern of 52% of the carriers.

Since we launched this innovative solution, Partner Communications (previously Orange Israel) went to production and launched their new V-NET product using Cloudify as orchestrator and VMware as the NFVI.

SD-WAN Screenshot from Partner Communication’s new VNet offering

More details on this specific use case can be found in this post: How Cloudify Enabled a Telco to Create a Fully Automated, Managed CPE Service - A Use Case

This quarter we added another major European carrier into this program, a major win over both established providers and other open source alternatives. This deal also included a partnership with one of the leading system integrators who are responsible for the end-to-end delivery of the solution.

The combination of Cloudify as the Open vCPE framework and system integrator, responsible for the end-to-end solution, is a winning combination that could help carriers get the best of both worlds. On one hand this solution could be easily tailored to the carrier’s infrastructure and needs, and on the other the carrier receives a full turnkey-like solution similar to others, such as Cisco, but without the lock-in and significantly more economical.

Cloud Native VNF Win

One of the challenges that carriers face today when launching a new NFV project is that the VNFs (switches, routers, firewalls, etc) were not designed to run on a virtual network.

In December of last year, we launched a new Cloud Native VNF program followed by a new business model offering targeted specifically for VNF providers.

I’m happy to say that this year we signed an OEM partnership agreement with MetaSwitch, one of the first movers in the Cloud-Native VNF space and established partners of ours for the last couple of years. Metaswitch was also selected by Swisscom as their PoC winner in the NFV/SDN “Call For Innovation” for their new product Cloud Native Network Evolution in December 2016.

A great example of this partnership can be seen in this MetaSwitch demo.

Cloud Native ClearWater IMS using Cloudify

DevOps Automation / Multi-Cloud Win

During a joint event with Atos and Société Générale in Paris, the two companies presented their journey toward a DevOps and Multi-Cloud strategy and why they chose to base their strategy on TOSCA, using Alien4Cloud and Cloudify.

I think the following slides from the event speak for themselves.

Why Atos chose Cloudify

How Cloudify fits with Atos Aliend4Cloud

This win adds to other enterprises that are using Cloudify for multi-cloud orchestration.

More about the event can be found in this post.

Edge Computing Win

One of the most promising opportunities that we closed this quarter happens to be in the area of Edge Computing. Edge computing is the movement from the central clouds we all work with today, to a highly distributed cloud in which airplanes, ships, or cars and virtually any other IoT device becomes a moving data center of its own.

Edge computing pushes cloud management as we know it to the limit with requirements such as low footprint, dealing with unreliable networks, and extreme scale in a highly distributed network environment. In this specific use case, Cloudify is utilized as a central manager as well as on the edge where the customer is running Kubernetes on bare-metal and controlled by Cloudify.

I’m super excited about this use case as it fits perfectly with the flexibility of Cloudify to allow nested and distributed management all while simultaneously leveraging low-footprint orchestration through the use of ARIA on the edge device.

This allows a federated management model where we can take advantage of the power at the edge to have more autonomous management capabilities.

NFV Lab Win

We launched the first NFV Lab last year, and since then, many participants have joined the lab.

In this quarter we extended the lab to a full on-demand PoC environment and it is currently being successfully utilized by one of the Top 5 global carriers.

This was a great example showing how we could take a complex use case such as NFV IMS and turn it into a simple user experience by allowing access to a fully operational lab in a matter of minutes.

It was also a great example of how an open, bottom up strategy could become applicable in a fairly conservative industry. The move to a more open approach is also changing the way carriers adopt new technologies. Developers are becoming more influential in the decision-making process and they are influenced mostly by adoption patterns in the open source community.

This is not just a technology shift, but a huge cultural shift, as I outlined in an earlier post called “What Developers Want From Their Technology (But Mostly Cloud).”

We’re now working on a new version of our lab offering to allow an even simpler experience by turning it into a complete self-service experience.

ONAP Wins

Traditionally new technology adoption takes years to succeed, and requires close collaboration among those producing network technology and those consuming it. In the past, standards development organizations (SDOs) have played a critical role in offering a forum for discussion and debate, and well-established processes for systematically standardizing and verifying new technologies.

In a software driven world, innovation can’t wait for SDOs to deliver hard requirements that can’t fit an ever changing reality. As a result, industry has been increasingly turning to open source communities for implementation expertise and feedback.

ONAP brings together Open ECOMP and Open-O projects as a comprehensive platform for real-time, policy-driven orchestration and automation of physical and virtual network functions that will enable software, network, IT and cloud providers and developers to rapidly create new services. By consolidating member resources, ONAP will deliver a unified architecture and implementation, with an open standards focus, faster than any one project could on its own.

On June 8th ONAP announced that Accenture, CertusNet, Coriant, Juniper Networks, Mavenir, Mirantis, PCCW Global, Red Hat, VEON and Windstream joined as new members to contribute to the open source framework for network automation. These are added to the current members, which include a broad mix of major vendors, service providers, system integrators and consultancies: Amdocs, ARM, AT&T, Bell Canada, BOCO Inter-Telecom, Canonical, China Mobile, China Telecom, China Unicom, Ciena, Cisco, Cloudbase Solutions, Ericsson, Huawei, IBM, Intel, Metaswitch, Microsoft, H3C Technologies, Nokia, Open Networking Foundation, Orange, Raisecom, Reliance Jio, Tech Mahindra, VMware, Wind River and ZTE.

Cloudify is a founding member of OPEN-O, and ARIA is the common TOSCA parser in OPEN-O. In addition there are several models within ECOMP which are using the community version of Cloudify. Cloudify is a platinum founding member of ONAP, committed to open-source and continuing our work on networks powered by open code, standards and orchestration.

ONAP is committed to model-driven orchestration based on TOSCA that crosses industry borders - vendors and service provides. When ONAP wins, the industry WINS and Cloudify WINS!

Our participation in ONAP and our continues and consistent commitment to open-source and open-standard has played a major factor in winning the large carriers deals. Cloudify also organized an ONAP Launch Event at the Open Networking Summit in April 2017.

The industry shift towards open models such as ONAP is becoming more evident and recent RFx are starting to indicate that the ETSI MANO Standards and Specs for Service Orchestration is not considered as a viable way forward, It was also indicated the vendors in this space are encouraged to look at alternative approaches such as ONAP, OSM or Open-O that overcome the ETSI MANO shortcoming.

Final Notes

One of my biggest frustrations with NFV is that, while it was clear that Openness Is the True Path of NFV, most of the big carriers got cold feet as soon as they had to make a final and risky decision regarding their NFV solution and often went back to their comfort zone, of working with traditional vendors. Not surprisingly many of those projects failed, sometimes in a big way. One of the more notable example of this is how Telefónica Ditched HPE as Virtualization Lead.

What makes me happy now is to see that more carriers are starting to realize that the path to openness is through partnering with players who have it already in their DNA, throughout the products they build, and business strategy they execute. The win with Partner Communications and the fact that they were able to build a vCPE and SD-WAN solution that is not just open, but far more innovative than most of the regular NFV projects at a fraction of the time and cost, has paved the way for others to follow. I’m now starting see the beginnings of a trend in which more of those players start to adopt true openness as part of their NFV strategy.

I’m also starting to see that, with the growing maturity of network virtualization, there are more use cases and demand in other areas such as Open vCPE, Cloud-Native VNFs, and network virtualization, in which that plays a key role, as I outlined in a new whitepaper on the subject.

As more enterprises adopt a multi-cloud strategy, it becomes clear that network virtualization is going to play a key role in how we manage and secure our multi-cloud networking in enterprises as well, not just in Telcos. This will be realized as part of the regular DevOps process which means that we'll see a more application-driven networking patterns similar to the way other infrastructure resources are being managed.

The key drivers and use cases for edge computing

Application-driven networking also has the potential of completely changing the way we think about network security. Rather than having static VPC connections or firewall rules, we can turn them on only when they are needed and remove them when the application no longer needs them. We can also think of taking proactive measures such as closing the network for a specific tier of the application or even moving the entire application to a completely different datacenter when it’s under attack.

Edge computing definitely stretches this vision out in multidimensional paths as we turn every edge into a network of many miniature clouds that need to be coordinated to deliver a specific service. Edge computing also has the potential to bring the cloud strategies of enterprises and carriers much closer together both in the architecture and in the kind of application and services that would run on that environment. So, while this is still very early days for edge computing, I feel that the move to the edge will happen faster than anything else that we have experienced so far.

Building Large-Scale Services with Micro-Services and TOSCA

A decade ago, large-scale services were an edge-case scenario, often designed as one-off systems.

Then, in the mid 2000s, the financial services industry began using algorithmic trading and automated trading systems, which required scalability under extreme low-latency in a stateful transactional system. It quickly became clear that the classic tier-based architecture which was popular at the time was insufficient for this use case. That led me in 2007 to write about one of the first alternative architecture patterns for building large-scale systems, also known as Space-Based Architecture (SBA).

Today, applications like social networks, networking services and IoT have made large-scale systems the norm rather than the exception. As a consequence, we need a more systematic model for designing and implementing large-scale, SBA-type systems. Microservices architecture, in conjunction with the TOSCA modeling language, offers an excellent solution.

Let’s explore how this solution works.

Model-driven microservices

The key concept behind a microservices architecture is to break large systems into a set of loosely coupled autonomous services. The TOSCA language lets us describe the domain model behind each individual service, whether it is based on containerized or non-containerized components.

Model-driven design is an architectural concept in which the application or service domain model is defined first, and the rest of the interaction with the service is driven from that domain model. Take a look at this graphical illustration:

The building blocks provided by TOSCA to model this service include...

Node: Analogous to class in other object-oriented languages, a node can define specific interfaces and inherit others. TOSCA comes with a set of built-in nodes, and open source orchestration tools (i.e., Cloudify and ARIA) add a set of built-in node libraries that cover popular cloud resources like AWS, OpenStack, VMware, GCP and Azure.

Relationship: This defines the relationships among nodes.

Group: This feature packages nodes in “pods” and is used to manage the lifecycle of the group as a single unit.

Adding Custom Resources as Node Types: This capability adds custom nodes through imports of other libraries, as is done with similar languages.

Remote Execution Through Workflow: Workflow defines business logic, and TOSCA defines implicit and explicit workflows. Implicit workflows (i.e., install) execute the nodes’ lifecycle operations according to their dependencies. Explicit workflows provide a way to interact with the service nodes in an abstracted manner (i.e., upgrade).

Discovery Through Relationship: Relationships let one node discover other, related nodes.

Service composition pattern

So far we discussed how we can use the TOSCA language to describe the domain model of a particular microservice. Open source orchestration platforms that use TOSCA introduce a new pattern known as the service-proxy in which we can describe a service as a single node type to the other related service. The service-proxy pattern uses the service input/output as a generic way in which a service interfaces with the outside world.

The example below defines a composite service comprising a set of node types with two special service-proxy node types. The service-proxy node type is responsible for representing the output properties of external services as local properties of that specific node type. It is also responsible for either discovering or launching the related services (Microservice 1 and Microservice 2):

This lets us leverage existing TOSCA features for modeling the internal components of a specific service and also the relationship with external services.

Deployment-update is a feature in the open source orchestration approaches noted above that lets us update a service topology after it has been deployed. We can update existing services after deployment with new nodes, and we can change existing nodes.

In the example below, we use the service-proxy pattern in conjunction with deployment-update to add a new service to an existing composite service. We use deployment-update to add a new service-proxy node and point it to the new microservice.

Container support with cluster management options

TOSCA can be extended to support integrations with popular cluster management tools like Docker Swarm, Docker Compose, Kubernetes and Apache Mesos. TOSCA can manage container infrastructure and orchestrate services running on container platforms.

The need for generic service orchestration

Most large-scale systems never fit into a single platform and quite often come as a set of composite services that are linked together. To automate the processes of managing and delivering those applications, we need a generic service orchestration that is not bound to any of the underlying platforms but instead can integrate with many of them in order to fulfill cross-domain automation tasks.

This generic services orchestration doesn’t have to be an alternative to the more purpose-built orchestration (a.k.a. domain orchestration). It could actually use the domain-specific orchestration as an abstraction layer that hides the complexity of managing a particular service on a given target platform. The built-in neutrality and openness of TOSCA makes it an ideal service orchestration modeling language.

In summary

The explosive growth of IoT and distributed networks—and the degree to which they are now woven into the fabric of our lives—has created a dire need for large-scale computing systems that can scale, offer low-latency and high-availability, and are highly automated and manageable. A microservices architecture built with TOSCA is an excellent way to meet these objectives. This approach not only offers all the benefits afforded by microservices (scalability, fault isolation, flexibility, etc.) but also enables integrations with cluster management tools, container platforms and popular cloud resources like AWS, OpenStack, VMware, GCP and Azure. Best of all, the capability to build large-scale systems with microservices and TOSCA is readily available through the open source orchestration tools.

The End of Cloud Management As We Know It - Part 2

In the first part of this series, we looked at the issue of cloud management silos created by multiple cloud environments and management platforms designed to serve different needs in the software delivery process, proposing a next-generation CMP as the means to deliver a common management toolset to serve the needs of developers in the business units and central IT.

In this post, we’ll examine what is needed to deliver a next-generation CMP.

Creating a Next-Generation CMP

The next-generation cloud management platform that we discussed in part 1 must serve both the business unit and central IT. To understand what that means specifically we need to map the needs of each one of them.

Mapping the Business Unit and IT Needs

First, it’s useful to map business unit needs into two distinct user profiles. The first is the end-user that wants a simple click through experience to get the needed service without worrying about how to manage it. The power-user, by contrast, is the application owner and is responsible for ensuring the performance and configuration of the application. This power-user needs greater control of the infrastructure.

The Central IT (operations) is essentially the cloud service provider in the organization, responsible for managing the common environment and ensuring that the business unit can operate and deliver its applications. It is also responsible for providing a common set of services that are not tied to a specific application such as database services, analytics services, automation and monitoring. Operations is also responsible for addressing cross cutting concerns such as security, regulation and cost.

—Three personas in enterprise IT—

Key tenets of a next-generation CMP

Mapping the business unit and centralized IT needs allows us to identify the key tenets that the next-generation CMP need to support:

• Empower the business unit—The business unit has the responsibility not just to deliver the application but also the specification on how to run and manage it on the target environment. The specification often comes in the form of a YAML template (TOSCA is good example for a standard definition of that spec) and can be considered as part of the application source code and packaging. This allows the business unit to have higher degree of flexibility in the choice of cloud, infrastructure resources and even application frameworks and thus create better collaboration and shared responsibility between the business unit and central IT. The fact that the specification on how to run and manage the application is now delivered as code allows to expand the contribution and collaboration practices that were traditionally used between the development teams also as a means to manage collaboration with central IT operations.
• Cloud Native—Cloud native applications are built as a set of microservices and not as a monolithic application. This requires that each application service would be able to have a means to discover and interact with services in a generic way and not be managed in a silo. The new CMP should have native containers support which is the common package and delivery mean for microservices.
• Integration approach at the core—Traditional cloud management had to develop new monitoring, billing, logging systems. We now have many open source products that do a pretty good job covering a specific function of the application management stack such as monitoring, logging, configuration management, and container management. This shifts the management challenge from implementing each of those functions to integrating the best of breed solutions through a plug and play experience. The second challenge is how to provide a holistic experience across those best of breed management stacks through a single pane of glass as if they were part of a single platform.
• Allow simple and fast adoption of new frameworks and applications—The new CMP must remove the complexity of managing applications through managed services, for example database as a service, reporting as a service, and application server as a service.
• Everything self service—Common tooling must be provided through a self-service mode allowing central IT to deliver needed services quickly.
• Application driven KPI and built-in activity monitoring—Monitoring focus should shift from infrastructure resources such as CPU and memory to application-driven monitoring and activity monitoring such as number of applications deployed, number of instances per cloud,the size of each deployment, and the state of each deployment.
• Closed loop—Monitoring system data was traditionally targeted for central IT. In the new CMP, it should be easily accessible to the application users in the business unit through an API. This will allow application owners to handle self remediation by automation for things like failover and auto-scaling.
• Actionable Insights—Rather than providing raw monitoring data which is rarely useful, the monitoring system of the new CMP needs to provide meaningful insights and recommendations. These can include cost-related and utilization insights and can become actionable in the case of failover, scaling, or shutting down unused resources.
• Putting Network and application management together—Network configuration such as firewall rules, VPN connectivity, load-balancer have been absent from traditional CMPs. In a hybrid cloud environment, network management becomes key, and it needs to be tightly integrated within the next-generation CMP. Network virtualization allows more than configuration management of the network; it permits full automation of network element instantiation as part of the application life cycle. This opens the door for application-driven network management in which the network follows the application, configured and controlled not just by the network operator but by the application owner.

Model driven, orchestration-first approach to cloud management

The key enabler for achieving the above requirements is taking a model-driven, orchestration-first approach to cloud management rather than an infrastructure-first approach as with traditional cloud management. The orchestration-first approach drives a holistic integration of the resources that serves the application through its lifecycle. Orchestration-first focuses on automation and provides a generic model for automating application lifecycle by providing a generic framework for turning applications into self-managed services.

—Orchestration provides a generic automation engine—

Developers can define the application description and the specific target stack including the way it should be managed through model driven templates, and the orchestrator is responsible for mapping those templates into an automated execution plan that interface with the underlying resources.

Central IT, as the service provider of the shared multi-cloud environment, uses the orchestrator to control which resources should be exposed to application developers and how.

—Model-Driven Orchestration provides an interface between the business unit and central IT.—

Serving the business unit and Central IT

Now that we’ve identified the key tenets behind of the next-generation CMP and the central role of the orchestrator in that environment, let’s see how those tenants map into specific features and how each of those features addresses the needs personas in the business unit and central IT.

Application Developer

In my post What Developers Want From Their Technology (But Mostly Cloud), I talked about what a developer needs from a cloud system. Mostly they want to be able to select the stack and environment that they want. From there, they want to focus on application development for that environment without worrying too much about management. The following set of features is a good example of how a next-generation CMP can address this:

• Catalog—Provide an easy way for developers to select and activate the target environment through self-managed services.
• Built-in integration and support for popular cloud environments—The idea is to deliver support without exposing a “least common denominator”. This includes container frameworks such as Docker and Kubernetes as well as services like DBaaS.
• Simple CLI experience—Allow developers to run applications from a local desktop environment for development and testing through a CLI.

Power User (a.k.a the “DevOps guru”)

Power-users are responsible for automating the development and deployment lifecycle. They are also responsible for ensuring that the application meets performance, security, availability and cost targets. To meet those responsibilities, the power user needs greater control of the environment and its resources. The following set of features provide a good example of how a next-generation CMP can address these needs:

• Model-driven blueprints—Provide the interface for automating key workflows needed to manage the application and interface with underlying resources via a blueprint that’s often based in a YAML file. To simplify the development processes it is also common to have a “composer” which is basically an IDE for blueprint development.
• Model -driven design—Provides Restful API access to the resources exposed in the CMP, starting from the infrastructure resources to the monitoring system.
• Extension through plug-Ins—Plug-Ins provide an interface to extend the CMP to support any resources or API endpoint that needs to be part of the application life cycle.
• CLI interface—A popular choice for integration with the build system.

Central IT Operations

The operation group is responsible for managing the shared infrastructure which often includes multi-cloud resources and a mix of private and public resources. It is also responsible for governance and assuring that the business unit follows standards on how to run and manage their applications. The features below should be included in a next-generation CMP to address their needs:

• Multi-tenant self service portal—The portal provides a central interface to control access and resource allocation.
• Application/Service Reporting and insights—A monitoring capability to track key KPIs per application.
• Activity monitoring—A feature to allow monitoring of activity per user per application over time.

Towards better collaboration

The main difference between traditional cloud management and next-generation cloud management is that the role of the business unit is vastly larger. Developers are taking an active role in application management and the choice of cloud stacks needed to serve those applications. Collaboration between the business unit and central IT must become smoother, placing greater emphasis on how central IT empowers the business unit rather than controls it.

Central IT, as the service provider, can provide a common multi-cloud environment and a structured model for interacting with it. At the same time, it should embrace ideas and input from the business unit that can enable more rapid evolution of the shared environment and keep it up to date with the needs of the business units. The goal for all involved is to avoid turning the shared environment into the next IT bottleneck.

Final Notes: Developer Freedom. Your success

Enterprise technology spending in 2017 is set to rise 3%, with $3.5 trillion expected to be invested on technology, according to Gartner Research. Within this environment, operations will need to pivot from being seen as a cost center that risks being cut each year to one that helps build the business and is in step with its goals.

The key is to understand that Central IT serves the business and regains its central position in the organization is by supporting and empowering developers in the business units, turning them into active partners rather than passive consumers. The next-generation CMP is a means to enable this sort of interaction by offering a common platform and a set of self-managed services give developers a life at least as easy as when they were working directly with public cloud. The next-generation CMP also supports extensibility of the system by the business units.

By delivering these improvements, next-generation CMP creates a higher degree of developer freedom which is key to regaining their trust and driving success for the business.

The End of Cloud Management As We Know It - Part 1

We’ve all read the reports about IT and business units becoming more tightly coupled as DevOps gains momentum. Puppet Labs’ State of DevOps report is one of the better ones, and it tells us that high-performing IT organizations deploy 200 times more frequently than low performers, with a stunning 2,555 times faster lead time to deployment.

The numbers speak for themselves, and the conclusion is unavoidable: the tools we’ve used to manage cloud in the early stages of its growth are no longer sufficient for an agile, responsive world in which business unit developers and central IT are moving faster and covering larger and more complex application portfolios than ever before.

In this two-part post, we’ll explore what’s happening in this rapidly changing environment and how we can prepare for the end of cloud management as we know it.

Reality Setting in

Reports like the one linked above show that business units and central IT are tightly coupled in terms of the time to market and strategic business goals. At the same time, the tools and processes being used to manage (or, “un-manage?”) applications and IT environments are indicating an opposite trend. The introduction of on-demand cloud resources has suddenly shifted control of IT resources. Today, control is dispersed and access is freely available to anyone at the click of button, posing a major disruption to how corporate IT formerly provisioned infrastructure.

This enabled speed for developers by enabling the onboarding of green-field apps quickly to their environment of choice. They can now quickly roll up their sleeves and get to work instead of waiting on the bottleneck of Central IT. As a result, typical large-scale enterprises are facing a major disruption of what can only be likened to a “wild west” and hodge-podge of infrastructure, tools, stacks and more, leading to silos of application stacks and management tooling across business units.

—The shift of power to business units has led to a “wild West” cloud application management tools.—

New Challenges to Address

From our experience with some of the largest banks, insurance, satellite, and analytics companies, that are all facing this same reality of different management silos, and the distribution of power and control in IT has opened the door to many pain points:

• Lack of consistent methodologies on how to manage applications in a cloud environment
• Low reusability and lots of custom work required to build and administer the automation and management of each application
• No continuity and integration with existing systems
• Slow pace of adoption of new technologies, mainly due to a steep learning curve, lack of skill set and tooling required to handle each new cloud or infrastructure stack.

—Each environment has its own tooling, processes and platforms, leading to silos—

Another major challenge is the risks stemming from a lack of common tooling and governance. This risk is seen in greater exposure to security issues and potential breaches that can result from a lack of adherence to corporate security policies and practices. On top of this, higher costs are often incurred due to the lack of ability to maximize the utilization of existing resources or prevent waste due to misuse of cloud resources. Exposure to these security and cost risks ultimately hinders the transition to cloud.

Survey Says…

According to the last State of Cloud report from RightScale, we’re seeing a strong shift toward centralization, with more central IT teams taking a broader view of their role in cloud.

While central IT perceive themselves at the primary selector of public clouds and private clouds (more than 60%), as a subject matter expert of deciding which applications to move to the cloud (63%), there is clearly a significant gap between how the business units actually perceive corporate IT’s role in the organization, with more than 55% of those surveyed responding to the contrary.

This gap between what Enterprise IT wants and the way Business unit see them imposes a new class of challenges:

• There’s a general mistrust between the business unit and the central IT resist the move to DevOps and Cloud.
• In addition to that there's an inherent conflict between the need for better control by the central IT which often led to a choice of tools that often focused on infrastructure management and monitoring and the need of the business unit for automating the development processes from build to production which led to application centric and automation centric set of tools.

This perception gap imposes a new class of challenges, first and foremost there’s a general mistrust between the business unit with central IT largely resisting the move to DevOps and cloud. All while there's an inherent conflict between the need for better control by corporate IT, often times leading to a choice of tools focused on infrastructure management and monitoring as well as the needs of business units to automate the development processes from build to production which led to application-centric and automation-centric tools.

The End of Cloud Management as we Know It

We’ve all heard the “break down the silos” mantra. The reality is that the promise of DevOps can’t be delivered when the organization can’t use a common set of tooling to manage applications. Common tooling and more centralized management would serve both the business unit and centralized IT, while providing better governance.

In one of my earlier posts, Cloud Management Roundup - Orchestration vs PaaS vs CMP, I compared the different alternative approaches for cloud application management. This comparison led me to the realization that the existing cloud management frameworks such as Redhat CloudForms and RIghtScale were built with an infrastructure-centric mindset. They are, by definition, better at serving central IT than the business units.

Similarly, PaaS frameworks provide a set of tools that were set to empower the developers of the business unit. Unfortunately, and quite often, they limit the choice of applications that can be delivered by the platform and at the same time doesn’t address the needs of central IT to have full visibility and control over the application and infrastructure.

A third approach, orchestration frameworks, tends to focus on automation but are often lacking the ability to provide a central system view needed by central IT. Orchestration tools also tend to be too sophisticated and low-level for the average developer in the business unit.

In summary, the existing set of management tools and approaches cater to either IT ( CMP) or Business Units (PaaS) or DevOps (orchestration). None of them serve both business unit developers (both the PaaS developers and the “power users”) without significant compromises.

This calls for new thinking: a next-generation cloud management platform.

ONAP is Driving Much-Needed Standards in NFV

This article first appeared in Wireless Week on March 13, 2017

Last month, the Linux Foundation announced the fusion of its two flagship open networking projects. Open-O (launched a year ago at Mobile World Congress by China Mobile and Huawei) will join with open source ECOMP (Enhanced Control, Orchestration, Management and Policy, led by AT&T) to form the ONAP (Open Network Automation Platform) project. Here’s why ONAP is a game changer not just for NFV, but also for the next iteration of hyperscale cloud.

NFV is Too Big to Go It Alone

The biggest “a-ha” moment in the ONAP announcement is the reality that NFV is such a major undertaking—technically and operationally—that even powerhouses like AT&T and China Mobile understand they can’t go it alone. Working together also means that open source is the collaboration platform for the future, as it’s the only way to drive standardization in fragmented industries.

Users and Vendors, Working Together

A major lesson we learned from the OpenStack community is the importance of users—in this case, carriers—that are committed to deploying the technology hand in hand with vendors, all working together in the same community. It took OpenStack a while to reach maturity, and bringing the operational view into the community has really sped up the roadmap process. Put another way, when big consumers of the technology started working side by side with developers in the community, large strides toward operational maturity followed.

Standardization Comes to MANO

In 2016, as NFV was taking flight, a diversity of MANO (management and organization) initiatives was hindering the climb to altitude. Fragmentation from semi-competitive projects like OSM (Open Source MANO), OPEN-O, OpenBaton, and OPNFV (Open Platform for NFV) was a source of risk for carriers. With the formation of ONAP, one community now represents more than 30 percent of subscribers worldwide. This center of gravity will drive standardization toward ONAP.

Similar to the way that OpenStack forced a consolidation among open cloud initiatives (CloudStack and Eucalyptus), I expect the same thing to happen with other open source initiatives around NFV. ONAP will force consolidation, and smaller initiatives will see value in collaborating with a standard-setting project.

TOSCA (Topology and Orchestration Specification for Cloud Applications) has been used in Open-O and will likely become the standard for ONAP as well, alongside the acceptance that TOSCA/YANG (Yet Another Next Generation) should be integrated as complementary technologies and not as competing standards. This may become the biggest step toward a common modeling language.

Simplified VNF Onboarding

VNF onboarding remains a top priority for our Cloudify open source project, and it’s a major reason Gigaspaces was founding member of ONAP. No platform is ever complete without a thriving marketplace of cloud-native applications that can easily be onboarded to the orchestration platform. Without an ecosystem and marketplace, such initiatives will struggle for relevancy.

What ONAP Can Learn From OpenStack

OpenStack’s early progress was stymied by consensus-led decision-making, which slows everything down. Of course, the market keeps moving, and so the community—and the software—get left behind.

The OpenStack community saw this issue and has largely addressed it, but the lesson teaches us something important that can be applied at ONAP: agreeing on a common modeling language is going to be key to moving forward faster. Similarly, creating a looser governance structure in the model of OpenStack’s Big Tent model will drive competition and innovation. Importantly, it will force contributors to be measured by adoption, not by control over a certain piece of the stack. “Game of Thrones” tactics have no place in open source.

Allowing room for competition will keep ONAP from becoming yet another “Linux” that needs to have a single implementation for every piece in the stack. Competition reduces the risks of land grabs in which everyone tries to influence the project by owning a piece of it. This leads to the creation of unnecessary projects simply to justify the desire to contribute and be part of the game. This in turn leads to greater complexity, and eventually lack of adoption.

A community driven by big players risks losing the developer's voice. As we've seen in OpenStack, the developers are the key to driving simplicity and alignment with DevOps processes and tools. A challenge for the ONAP community is to create a structure that includes developer voices in architectural decision making by reducing barriers to external contribution and enabling a simple way for other open source projects to integrate and support ONAP without forcing them to become part of ONAP. These could include monitoring frameworks, policy engines, container integration, and cloud-native VNFs.

OpenStack has taught us that allowing competition will drive faster innovation and encourage contribution through competition, building better implementations of the same core components rather than spreading the effort thinly across many different projects.

ONAP: It’s the Code, Stupid

NFV standardization simply has to be driven from the code. Having an open community with companies focused on innovating—churning out code together—and taking these practices back to the standard bodies like TOSCA and ETSI/NFV to build a unified NFV model and architecture is the means we’ll use to drive NFV adoption and network innovation, to the benefit of everyone who uses global networks to solve problems and drive commerce.

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].

What Developers Want From Their Technology (But Mostly Cloud)

---

This post was originally published on InfoQ.com in February 2016.

---

 

The brave new world of plentiful tooling, and especially open source tooling, has driven home the realization that developers are the new decision-makers, not the man in the high castle that just dictates the technology and stack. A minute before I was about to publish this piece, John Vrionis of Lightspeed Ventures wrote a piece, It’s actually open source software that’s eating the world, that perfectly segues into this one, you should read it if you haven’t yet.

I wrote about similar concepts, in my recent post the Disruption Cycle where I note the trend that by the time the latest and greatest tooling has started to get a foothold in the market, another newer and hotter technology lands. These days, the differences in tooling are becoming mostly minor and superficial, and largely a matter of personal preference, and the focus is no longer on the core functionality and the deeply intelligent backend, but more on the first impression and experience the developer encounters. And as a result, the way developers adopt tooling isn’t that different from the way any new trendy gizmo or fashion is adopted. And today’s companies need to learn a thing or two from none other than the fashion or consumer industry.

Image credit: Venturebeat, It’s actually open source software that’s eating the world

While many companies believe they know how to target developers, and what developers want, the execution and ultimately the numbers in adoption will often times speak to the contrary.

The language we’ve been speaking to developers to date of features and functionality is becoming passe - as it doesn’t speak to the way they actually adopt tooling - it speaks to the way we THINK they adopt tooling. The mobile app adoption rate speaks to the same issue.

 

An excellent testament to this is in the early days of NoSQL databases where MongoDB and Cassandra were the leading players - both on paper excellent databases, where in terms of features and functionality the scales should have actually been tipped in Cassandra’s favor with better scaling and clustering capabilities...but Mongo took the lead, and has dominated since. Cassandra never really managed to catch up in numbers. If we examine how that happened it was a result of the really simple API Mongo provided to enable developers to just roll up their sleeves and get to work. The Cassandra interface and API was a lot more clunky and complex...despite the more robust feature set.

And it’s almost a snowball effect, because once the buzz and the hype begins to build around a new tool or technology, everyone wants to play with the new and awesome toy. So many times, the way a tool reaches the developer is based on its popularity, trendiness, word of mouth and a developer’s personal preference, not necessarily based on what’s under the hood.

Give Me Liberty...Wait, What do I Want?

The funny thing is that I’m not certain that if you asked the average developer they would know how to articulate that a better API is what they want - they likely would say it’s the feature set. This classic Ted Talk from 2004 by Malcolm Gladwell, writer of Blink and The Tipping Point, remains timeless, and still hits home. The most important take away is this:

[Offering diverse choices of spaghetti sauce - ~NS]...fundamentally changed the way the food industry thinks about making you happy. Assumption number one in the food industry used to be that the way to find out what people want to eat, what will make people happy, is to ask them.And for years and years...would have focus groups, and they would say, "What do you want in a spaghetti sauce?” And for all those years -- 20, 30 years -- through all those focus group sessions, no one ever said they wanted extra-chunky. Even though at least a third of them, deep in their hearts, actually did.

When I was a kid I only had Levis or Lee jeans to choose from and pretty much one style. Likewise, when I was a fledgling developer the same held true for my tooling and stack. The Oracles and IBMs were pretty much ubiquitous. Enterprises who built their whole market strategy around lock-in, where they would even provide “shelfware” in their six-figure contracts, that for them even served as their “contingency plan” for when additional tools were needed. There was no choice and diversity - and so there was little need to cater to developer’s needs, as it wasn’t a business factor. But the tables have turned.

While we like to believe that all developers are basically the same and driven by the same motives - just let me code, the truth is, that this means very different things to the different kinds of developers. Depending on the type of development front end, back end, big data and the beloved buzzwords fullstack & DevOps - each has a different framework and stack they like to work with - and many times, these don’t communicate well.

What’s more, developers too are also equally influenced by peers and trendiness, and the sexiness of the user experience and API, and sometimes even the prettiness of the GUI when it comes to adopting the latest tooling (remember a world before Docker?!). However, from a developer’s perspective the API is the key interaction point, and is largely the UI equivalent of an average user for judging the user experience of a new tool. This new world order dictates that if before the focus in product releases has been on core functionality and UIs, at the expense of the API’s usability - a major transgression by many software companies, that today the API is likely the most important element that will be the measure of your product’s adoption.

I Want it Now

So, the new challenge has evolved into how to get as many frameworks and tools to the developers, without a black box experience. In the past the thinking was that a developer wants a hassle-less experience, so this brought about the trend of very limited and opinionated frameworks that the former generation of PaaS suffered from. But this didn’t hold water, since while developers want to be spared the hassle, they need some semblance of control even more, and the option at the very least to tweak the framework when they want, and you can see a huge trend of abandonment of PaaS frameworks for more flexible options - often times leveraging a number of tools for this purpose.

So AWS took the exact opposite approach, continuously rolling out new services as they become popular, and deserve to be looked up to in this respect. They have managed to continually be ahead of the curve, or at least very slightly behind the curve with an unrivaled and rapid time to market to cater to the diverse whims of developers these days.

And the numbers speak for themselves the very far second Microsoft Azure, that took a more holistic and platform-like approach has been lagging behind in adoption, suffering from a slow rollout of new services. So while AWS can be perceived as the “Woolworth’s” of cloud marketplaces cluttered with a disorganized hodgepodge of services for every need, the more organized specialty shop that is Microsoft Azure that took the time to holistically think about how to integrate each service to the platform as a whole, has suffered in adoption as a result.

This clearly indicates that the speed of innovation is directly related to the speed of adoption. The standard has now become how fast can you launch new services into your cloud as they become popular, as the benchmark for what is going to win the developers’ mindshare.

And while the AWS model is impressive and agile and comprehensive...it’s not very future proof nor scalable or sustainable to develop all these services and frameworks in-house.

One Size Fits All

Which means that the approach to making this possible would need to be one that is so generic that it can fit the diversity and variety of frameworks that exist today, enabling you to mix and match and do whatever you want. A one size fits all sort of model.

So the idea would be to make it possible to be able to quickly take the latest fashionable framework - deploy it with a completely agnostic platform that can abstract it entirely and take it to any underlying infrastructure. Without knowing what that platform is or even will be in say August 2037.

And this is where that buzzword orchestration comes in.

It provides exactly that kind of generic automation and management for a large variety of frameworks and applications, which is why it’s not surprising that we’re seeing the rise in orchestration popularity over the past few years.

There are multiple kinds of orchestrations, here’s a partial roundup of the most popular orchestration tools, which are different in their goals and approach. There are those that are infrastructure-centric i.e. automate things on top of their specific infrastructure, to container-centric, or pure-play orchestration frameworks which are more of an integration platform that glue together the the infrastructure of choice with your DevOps toolchain.

Choosing the right tool for the job

Clearly the scope of the problem is fairly large, and there isn’t any one solution that can actually automate the deployment process of all the different kinds of workloads, on every kind of infrastructure. To really achieve this we would need to stack a few orchestration tools together.

So with such complex stacks and the diversity of infrastructure and workloads - that all need to be managed with different tooling....where new and innovative tooling is continually being developed (is your head spinning yet?!)...there has to be a way to unify everything, without even knowing what that everything is.

Choice + Speed + Simplicity = Adoption

So the software industry has quite a bit to learn from the fashion industry or any highly-competitive consumer-based industry that has an abundance of choice where the differences between products and are almost negligible, yet clear patterns of choice are still identifiable. These choices are based less and less upon rationale and more on intuition and even peers’ word of mouth.

In order to stay relevant in this world of diversity of software options, we all need to learn how to play in this new game. It’s no longer about the deep features and functionality it’s about diversity and choice. It’s about how quickly we can introduce these new toys into our window, all while keeping it simple.

This means:

• More tooling and services vs. complex and holistic platforms
• Sexy APIs, even more so than GUIs - as the API has become the “front end” for developers.

Generally speaking catering to the developer’s UX and simplifying how they work with your framework.

Because at the end of the day we all want our companies and teams to be considered technologically fashionable - based on what the moment dictates. Whether it's because we need to be an attractive enough business to appeal to developers looking to integrate our technologies, or even the need to be able to recruit excellent developers...who only really want to work with the latest and greatest tooling.

Of course, this is easier said than done, and in the real world actually takes a lot of experimentation and iterations, because even that is a constantly moving and changing target. So your speed of innovation will ultimately decide what remains a timeless fashion or a passing trend.

Cloud Management Roundup - Orchestration vs PaaS vs CMP

 

There are basically three main approaches to managing applications in a cloud environment: Orchestration, PaaS (Platform as a Service) and CMP (Cloud Management Platform). The end goal of all three is fairly similar - have a fully managed application on the cloud. It is therefore not surprising that users have a hard time choosing which of the approaches best suits their needs.

In this post, I wanted to make a simple distinction between these three options and offer some guidance on when you should consider each of the approaches.

 

We will use the following categories as the basis for the comparison of the three different cloud management approaches:

Application Workloads

In this category we compare the three approaches based on the kind of application workload that best fits each platform, for example: web applications, stateful applications, big-data, legacy, etc.

Support for Advanced IaaS Services

In this category we compare the three approaches based on the depth of IaaS support, for example: how much each platform can utilize advances IaaS services such as DBaaS, LBaaS, EMR, etc.

Support for DevOps Processes

DevOps processes such as continuous deployment tend to be application specific as they touch not just the application itself, but also other services that are external to the application such as - support system, build-system etc. A typical DevOps process involves creating new environments for QA, Production, etc. or updating existing deployments. There are different techniques such as Canary, Blue/Green, or Immutable that are often used to handle those processes. In this category we compare the three approaches based on the degree of support for those DevOps patterns.

Support for Containers and Cloud Native Stack

Containers can be viewed as lightweight VMs or application packages. The use of containers removes a large part of the application configuration management and packaging complexity. In this category, we compare the three approaches based on the degree of support for that container technology e.g. Docker, Swarm, Kubernetes, Mesos, Fleet.

Support for Bare Metal

Bare Metal machines are often used to allow maximum performance and utilization of the HW resources by bypassing the virtualization layer overhead. Bare metal is becoming a popular target for application deployment with the introduction of new bare metal cloud as well as containers that provide a cost effective way to use bare metal resources. In this category we compare the three approaches based on their support for a bare metal environment.

Support for Network Orchestration

Many enterprises and clouds support virtual networking through SDN. In this category we compare the three approaches based on the degree of support for network orchestration.

Target Users

This category will compare the different approach fits well with Developers in a DevOps role as well as Operations.

Let’s take a deep dive into the different cloud management options.

Orchestration Defined

Definition

Cloud Orchestration is basically a method for automating manual IT processes such as provisioning, installation, configuration management, remediation, maintenance, monitoring, scaling, etc.

 

• Application Workloads:
  The automation approach is fairly un-opinionated and therefore can address any use case that can be mapped into distinct manual steps. Because of this, it can be applied to a large variety of workloads starting from simple web applications to Big Data and analytics, or even legacy applications.

   

• Support for Advanced IaaS Services:
  Orchestration/automation doesn’t limit you from the use of any IaaS services as it doesn’t impose a layer of abstraction to manage a hybrid cloud environment.

• Support for DevOps Processes:
  Orchestration models the application into blueprints which makes it easy to create new instances of the same blueprint for Dev/Test or Production in a consistent way (a blueprint represents an environment meta-model). Orchestration also provides a way to interact with the existing deployments through workflows. Workflows are used to implement the DevOps processes. Since workflows are basically an execution script, they can easily interact with any external system such as build system or support system as part of the continuous deploymentprocess.

• Support for Containers and Cloud Native Stack:
  Most of the container based platforms (Docker, CoreOS) come with built-in orchestration. There’s also other types of container-centric orchestration such as Kubernetes which provides a more complete solution for managing applications.

  Other “pure play” orchestration tools such as Cloudify and Terraform provide support for setting up a container-based infrastructure and also integrate a hybrid stack of multiple containers technologies such as Kubernetes and Mesos, alongside non-container stack technologies such as databases, Big Data and legacy apps.

• Support for Bare Metal:
  Orchestrators are basically automation tools and can orchestrate applications on a cloud-based environment or bare metal. Some of the orchestration uses a resource pool mechanism to allow dynamic allocation of the application resources on a pool of bare metal machines.

• Support for Network Orchestration:
  Network orchestration is considered a core piece in NFV. There are two modeling languages that are commonly used for network orchestration: TOSCA, a standard for application topology definition, and YANG, a standard modeling language for configuration of network devices. The two modeling languages can also be combined todeploy network-centric services.

•  

  Target Users:
  The automation approach fits well for Developers in a DevOps role as well as Operations engineers.

   

Additional Reference: Orchestration Tool Roundup - Docker Swarm vs. Kubernetes, TerraForm vs. TOSCA/Cloudify vs. Heat

PaaS Defined

Definition

PaaS takes a more a developer-centric approach. It was built as an abstraction layer that is aimed to help the developers focus on writing code by abstracting all the infrastructure and operational aspects. To achieve this goal, most of the PaaS platforms come with a fairly opinionated approach on how applications should be running on those platforms (Cloud Foundry refers to this as the 12 factors).

• Application Workloads:

PaaS products are mostly suited for greenfield applications that fit the 12 factors definition. They are also suited mostly to web application and not so much to Big Data or legacy applications.

• Support for Advance IaaS Services:

The abstraction approach provided by most PaaS products aims to “hide” the complexity of the infrastructure from the developers through a relatively “thick” layer of abstraction. One of the side effects that comes with that abstraction approach is it limits the use of the infrastructure to a basic compute and storage pool of resources where in reality many of the modern cloud infrastructures today provide much more advanced services such as DBaaS, LBaaS, EMR etc. This also causes lots of duplication of logic for handling things like user management, billing, and quota, that are already provided by the infrastructure.

In addition, a PaaS often comes with its own set of logging, monitoring and development tools. DevOps users on the other hand tend to build their own tool chain, and the set of tools they use tend to vary between users, and over time, quite rapidly.

• Support for DevOps Processes:

Most PaaS products provide built-in implementations of some of the continuous deployment processes, e.g. Canary,  Blue/Green. However, those implementations tend to be tied to the platform with only a fairly limited degree of customization as the user is not expected to have access to the internals of the platform such as the load-balancer.

• Support for Containers and Cloud Native Stack:

Both OpenShift and Cloud Foundry are built on top of containers. OpenShift, specifically, is built on top of Kubernetes. Having said that, PaaS doesn’t provide direct control over the underlying container orchestration and therefore limits the use of container orchestration within the PaaS platform.

On top of that, PaaS rely on a specific container technology, therefore users don’t have the flexibility to use their container orchestration of choice such as Core-OS Fleet, Docker Swarm, Mesos.

• Support for Bare Metal:

Most of the PaaS solutions were designed to run on top of a virtualized cloud-based environment and were not built to run on bare metal.

• Support for Network Orchestration:

PaaS doesn’t expose most of the aspects of the network configuration to the end user and therefore comes with their own, opinionated, network configuration architecture.

• Target Users:

Developers

Additional Reference: PaaS vs Orchestration - PaaS vs Docker

CMP Defined

Definition

CMP stands for Cloud Management Platform. CMPs take an infrastructure-centric approach where the main focus is monitoring and managing of infrastructure resources such as virtual machines, storage, network etc. It can be used indirectly to manage applications by combining some orchestration capabilities as part of the platform.

• Application Workloads:

Similar to automation, CMPs come less opinionated and can therefore address a wide range of applications. Having said that, many CMPs were designed to provide infrastructure management and control the virtual machine that hosts the application, but not the application itself. CMPs don’t come with strong application management and automation capabilities to handle certain aspects such as dependency management, discovery, configuration management, application management, etc.

Automating the full lifecycle of a given application, including configuration management and automation of post deployment aspects such as fail-over and scaling, would require more integration work with third party tools in order to fill this gap.

• Support for Advanced IaaS Services:

The main value of Multi-Cloud CMPs is that they often provide a “single pane of glass” for controlling and monitoring cloud infrastructure across different cloud providers. To achieve this goal, many of the CMPs have to force some degree of “least common denominator” abstraction where they view the cloud infrastructure as a simple pool of compute and storage resources. By doing so, they limit the use of more advanced services provided by most of the modern cloud infrastructures today, as mentioned above.

• Support for DevOps Processes:

Most of the CMP products focus on managing infrastructure resources. Continuous deployment processes tend to be application-centric by definition. Handling DevOps processes through a CMP is often non-trivial and requires integration with third party tools to handle this task, but quite often, the level of interaction needed between the two systems requires tight integration.

In addition to that CMPs often come with a fairly monolithic architecture that includes their own Monitoring, Logging, Billing, etc and therefore doesn’t fit well in a DevOps environment. DevOps users tend to build their own tool chain and the set of tools that they would use tend to vary between users, and over time, quite rapidly.

• Support for Containers and Cloud Native Stack:

Most CMP can run containers on top of VMs.

• Support for Bare Metal:

Most of the CMP solutions were designed to manage virtualized, cloud-based environments and were not built to manage bare metal resources. 

• Support for Network Orchestration:

Most of the multi-cloud CMP solutions provide a limited set of network configuration mostly related to configuration of security groups and the load balancer. Advanced networking configuration, such as creating private network per apps, micro-segmentation, routers, firewall, and WAN gateways, are often not supported.

• Target Users:

Operations

Additional Reference: DevOps is not a Feature

Application Delivery

The purpose of this comparison was to demonstrate the differences between the three approaches for managing applications on a cloud-based environment. All of these approaches are a means to an end, and one of the most common use cases for these management frameworks is to allow faster delivery of applications.

To allow faster delivery of applications we need to provide the developers with the right tools for the job. Every developer may have different needs and, therefore, tools needed to serve his application as I pointed out in one of my previous posts entitled “What Developers Want”.

Based on the above analysis, we can measure each of the approaches under the following criteria:

The Key Benchmarks

• How fast you can serve the tools that developers need to become productive?

The open-source world offers plenty of new frameworks and tools which are being announced almost on a daily basis. Developers want to have access to them all, as, in many cases, those tools will allow them to gain better productivity and thus speed up the development process. What developers care less about is the process of managing and configuring those tools.

• Choosing a specific tool, such as a specific PaaS, is not a strategy.

Don’t build a strategy based on a specific tool, as by the time you are ready to support it, a new platform will emerge. Instead, be ready to support multiple platforms and tools even if they overlap to allow maximum flexibility for developers to then choose the right tool for the job rather that forcing them to fit into a specific platform stack.

As we can see in the following OpenStack surveys from 2015 and 2016, the popularity of the various platforms tends to change rapidly. In this specific case, we can see that Kubernetes grew almost 30% at the expense of Cloud Foundry. Cloudify grew 20% in use with OpenStack in production, according to users.

So, what we can understand from this analysis is that in order to serve those developers well the challenges are:

1. How fast you can introduce a new framework into your cloud?
2. How capable are you at managing many different types of frameworks?

It becomes clear now that in order to achieve this goal we need to have a generic way that will allow us to take any application and framework and offer it as a managed service, as shown in the diagram below:

Conclusion

In my personal opinion, the ability to introduce new frameworks fast is directly related to the flexibility of the management platform. Orchestration frameworks are more targeted to this approach because they are built to automate manual processes - in this case, installation, configuration, etc – directly, not indirectly as in PaaS or CMP options.

Having said that, the three options may not always be mutually exclusive, and it is also common to see a combination of some of the tools. For example, a generic Orchestration tool can be used to configure and setup a PaaS like Cloud Foundry or Kubernetes. A CMP can have an Orchestration framework as an add-on service that runs through the CMP thereby providing both the application and infrastructure view combined.

Building Your Application for Cloud Portability - An Alternative Approach to Hybrid Cloud

In my previous post, I discussed the differences between hybrid cloud and cloud portability, as well as how to achieve true hybrid cloud deployments without compromising on infrastructure API abstraction, by providing several use cases for cloud portability.

Cloud Portability Defined (again)

For the sake of clarity, I thought it would be a good idea to include my definition of cloud portability again here: “Cloud portability is the ability to run the same application on multiple cloud infrastructures, private or public. This is basically what makes hybrid cloud possible.”

Clearly, the common infrastructure API abstraction approach forces too many restrictions on the user which makes it fairly useless for many of the cloud portability use cases.

In this post, I would like to propose another method for making cloud portability, and therefore true hybrid cloud, a reality.

An Alternative Approach

One of the use cases I previously mentioned for allowing application deployment portability to an environment, that doesn’t conform to the same set of features and APIs, is iOS and Android. With operating systems, we see that software providers are able to successfully solve the portability aspect without forcing a common abstraction.

What can we learn about cloud portability from the iOS/Android use case?

Treat portability differently between the application consumer and the application owner - One of the main observation from the iOS/Android case is that, while the consumer is often completely abstracted from the differences between the two platforms, the application developer is not abstracted and often needs to treat each platform differently and sometimes even duplicate certain aspects of the application’s components and logic to suit the underlying environment. The application owner, therefore, has the incentive to support and even invest in portability as this increases the application’s overall market reach.

Minimizing the differences, not eliminating them - While the application owner has more incentive to support each platform natively, it is important to use cloud portability as a framework that will allow for minimizing but not eliminating the differences to allow simpler development and maintenance.

The main lesson from this use case is that, to achieve a similar degree of cloud portability, we need to make a distinction between the application consumer and the application owner. For cloud portability, in order to ensure a native experience for the application consumer, we need to assume that the application owner will be required to duplicate their integration effort per target cloud.

This is the same approach we should take with cloud application portability!

So, how does one go about doing that?

Achieving Cloud Portability with ARIA - A Simple Multi-Cloud Orchestration Framework

In this section, I will refer to this specific project as a means by which to illustrate the principles that I mentioned above in more concrete terms.

Project ARIA is a new Apache-licensed project that provide simple, zero footprint multi-cloud orchestration based on TOSCA. It was built originally as the core orchestration for Cloudify and is now an independent project.

The diagram below provides an inside look at the ARIA architecture.

There are three pillars, upon which ARIA is built, that are needed to manage the entire stack and lifecycle of an application:

1) An infrastructure-neutral, easily extensible templating language

2) Cloud plugins

3) Workflows

TOSCA Templating Language vs. API Abstraction

ARIA utilizes the TOSCA templating language in its application blueprints which provides a means for deploying and orchestrating a single application on multiple infrastructures through individual plugins, thereby circumventing the need for a single abstraction layer.

Templating languages, such as TOSCA, provide far greater flexibility for abstraction than API abstraction as it allows easy extensibility and customization without the need to develop or change the underlying implementation code. This is done by mapping the underlying cloud API into types and allowing the user to define the way it accesses and uses those types through scripts.

With Cloudify, we chose to use TOSCA as the templating language because of its inherent infrastructure-neutral design as well as being designed as a DSL which has lots of the characteristics of a language that utilizes the support of inheritance, interfaces and a strong typing system.

Cloud Plugins

Built-in plugins for a wide range of cloud services provide out of the box integration points with the most common of these services, but unlike the least common denominator approach (i.e. a single API abstraction layer), they can be easily extended to support any cloud service.

Workflows

Workflows enable interaction with the deployment graph and provide another way to abstract common cloud operational tasks such as upgrades, snapshots, scaling, etc.

Putting It All Together

By combining the three aforementioned elements, the user is given a set of building blocks for managing the entire application stack and its lifecycle. It also provides a richer degree of flexibility that allows users to define their own degree of abstraction per use case or application.

In this manner, cloud portability is achievable without the need to change your underlying code, and, in doing so, you enable true hybrid cloud.

See the hybrid cloud orchestration demo below

Achieving Hybrid Cloud Without Compromising On The Least Common Denominator

Survey says, that hybrid cloud, what once was perceived as virtually mission impossible, is becoming pretty much mainstream. According to this survey, and this survey, some users are currently running on as many as 6 clouds simultaneously on average per organization, with an even split between private and public clouds, both for real deployments as well as for experimentation, and 74% of enterprises are currently leveraging two or more cloud infrastructure vendors; making the need for robust cloud portability mission critical, not just nice to have.

From my experience though, when people refer to hybrid cloud, they often times don’t necessarily mean the same thing.  With the diversity of use cases for hybrid cloud, where each one of them drives a different strategy or approach, it is difficult to lump hybrid cloud into one simplistic category.

On top of this, most of the discussion, and even the tooling built for this purpose, is focused on bridging specific aspects of the infrastructure, e.g. compute and networking as an example, and quite often caters to a wider market, forcing a “least common denominator” approach which inherently limits the use of the underlying cloud (I will get into this more below).

In addition, many of the existing tools are missing the key part in such deployment models; the actual application itself. Running an application in a hybrid cloud environment requires the handling of the entire application stack in which the infrastructure is really only one component. This includes the configuration management, containers, monitoring, logging, and policies as well as maintenance of the application itself through its entire lifecycle.

I find myself writing a post on just this subject every couple of months, since the landscape changes so rapidly (see my disruption cycle post if you want more on that). That said, recent developments have gotten me thinking again, and I wanted to revisit the different hybrid cloud use cases and suggest a different approach to hybrid cloud that doesn’t force a least common denominator and handles the entire application lifecycle and stack.

So just to set the stage, and make sure we’re all on the same page, let’s start with the obvious - the definition of hybrid cloud and identifying the diversity of use cases.

Few know what hybrid cloud actually means

What the experts say:

In layman’s terms:

Hybrid cloud is, in simple terms, the use of multiple clouds simultaneously, where cloud portability is the enabler of this deployment model.

Where Cloud Portability Comes In

Cloud portability is the ability to run the same application on multiple cloud infrastructures, private or public. This is basically what makes hybrid cloud possible.

The distinction between the two is important, as in the case of hybrid cloud we’re talking about  multiple clouds attempting to act as one unified infrastructure, and with the second, we’re  basically talking about the option to run on multiple clouds, but not necessarily at the same time.

This post will dive into use cases for both.

Cloud portability use cases

We often tend to associate cloud portability with cloud bursting, and many times it’s even used erroneously interchangeably with hybrid cloud, but these only represent a couple of use cases, and, truthfully, not even the most common ones. In fact, the need for cloud portability spans across a vastly wider number of use cases that are much more common, but at the same time less known, ironically. Let me explain with the following:

• Future proofing - With the uncertainty around VMware or OpenStack and the emergence of a new class of cloud native infrastructure it has become abundantly clear that we're going to continue to experience more disruption on the infrastructure level. In order for the strategy to “future proof” your application from those changes and keep your options open to benefit from new developments as they happen, it is important to decouple the application from the underlying infrastructure by designing the application for cloud portability.

• Application deployment portability - Many software vendors that develop software applications need to allow application portability to give their customers a simple way to provision and deploy their software products on their cloud of choice. In this context, cloud portability can be analogous to operating system portability between Windows, Linux and Mac or even mobile app portability across iOS and Android. Cloud represents a market and by designing for portability you maximize the reach of your products to those markets.

• Same application across multiple clouds - The previous use case describes a situation in which we allow portability at deployment time, i.e. users are able to choose the target environment for deploying their application, but once they have completed the moving process from that environment, it would be considered a completely separate deployment.

There are a number of cases in which the same application would need to span its resources and services across multiple clouds at the same time. Here are a few:

• Cloud Bursting - Probably the most common use case for spanning application resources across clouds is known as cloud bursting. This use case is aimed to handle the need for on-demand access capacity and optimize the cost of those resources by allowing to run on a fixed pool of resources during the steady state periods and span to on-demand cloud resources during peak loads.

• Migration - Another lesser known use case for cloud portability is cloud migration. A common example would be an organization that is migrating from their VMware environment into OpenStack or from private cloud into public cloud. In this case, portability allows you to smooth out the process and reduce risk by providing a common management layer across the two environments, thus allowing the organization to selectively transition the application between the two environments while at the same time manage them as one.

• Portability between the same cloud versions - Another lesser known, but probably the most common, cloud portability use case is the move between versions of the same infrastructure. One of the common strategies to allow upgrade of the infrastructure is to create new instances (cloud sites) of a newer version, and then gradually transition apps onto this new version. Cloud portability make that process simpler as it decouples the application from the infrastructure, and in this way from the changes between versions.

The least common denominator approach

The number of use cases that would benefit from cloud portability could be fairly vast. As noted above, though, the reality is that many of the existing solutions for cloud portability are fairly limited and are not well suited to fit into all of those use cases.

One of the main reasons for this is that most solutions take a least common denominator approach in which they rely on a common layer of API abstraction (mostly around the compute API and to a lesser degree storage and networking) across all clouds and by doing so force limited use of the underlying cloud infrastructure.

 

Cloud is much more than Compute, Storage, Network

The common API abstraction already limits itself to Compute, Storage and Network and even at that layer the abstraction tends to be fairly simplistic and quite often doesn't expose many of the more advanced features of the underlying infrastructure, and there are many exciting features constantly being rolled out in the cloudsphere.

In addition to features, cloud infrastructure today provides a rich set of services such as  database services, analytics services, LBaaS, you name it...the list goes on, that just cannot be easily abstracted.

The result is that relying on this layer of abstraction comes with a high toll of compromising on the least common denominator, one size fits all model, and thus losing many of the benefits that modern clouds provide today.  And we are rarely one size fits all.

In my next post, I’ll dive into how to achieve true cloud portability without forgoing all of the benefits hybrid cloud deployments actually make possible.

Making TOSCA Truly Portable

Over the past few months I’ve been involved in various forums and discussion on what the right approach should be for achieving a common orchestration modeling language.

I felt that while there’s a growing consensus that TOSCA is currently best positioned to fit the bill, most notably in theNFV space, there are still different views on what should be the right approach to implement the standard. Some view TOSCA simply as an abstraction layer able to wrap any orchestration framework and by that provide a standard modeling on top of proprietary modeling languages.

Some view TOSCA as more than a language or abstraction layer, that represents a whole new set of philosophies on how to truly build portable orchestration.

Regardless of the approach, I think that most people would agree that the main promise of TOSCA is in its portability.

In this post, I wanted to examine more closely which of the approaches is best suited to enable true portability.

The state of TOSCA & the promise of portability

TOSCA is at the center of many of the new open NFV focused orchestration projects such as Cloudify, Tacker, Open-O, OSM just to name a few, and is quickly becoming the clear winner of common orchestration modeling languages in the Telecom NFV domain.

For those choosing TOSCA, one of the primary highlights is its promise of portability through its inherent technology agnosticism, by providing a common modeling language that can be ported across different clouds, and even orchestration frameworks. This much-coveted portability proclamation, at least theoretically, will allow users to define their application once and then run it anywhere. That said, the reality is that most of the orchestration tools that claim to support TOSCA are not really fully compatible with the specification yet.

More importantly the true value of portability isn’t just achieved by reducing lock-in, but also by enabling a greater degree of collaboration - let me explain:

Portability - The big picture

To fully understand the value of having a common standard and a portable deployment model, I would like to use what I believe to be a useful analogy from the manufacturing industry.

Computer Aided Design (CAD) provided a common modeling language to describe the manufacturing of parts. Having a common modeling language enabled much more advanced collaboration in the globalization era. It enabled different companies to define a product design in one part of the globe, and then simply and cost efficiently manufacture it on the other side of the world - exactly as originally designed. This sort of collaboration was the enabler of a revolution in design, and made it possible to manufacture much larger and complex systems such asBoeing Dreamliner  787 at scale.

 

“The 787 program has more than 50 Tier 1 partners located around the world, including in the United States, Australia, Canada, France, Germany, Italy, Japan, Russia and the United Kingdom. There are suppliers to the 787 program in 38 U.S. states, including significant contributions from California, Kansas, Ohio, Oklahoma, South Carolina and Washington. In all, suppliers to the 787 program are located in 19 countries and were selected based on their ability to do the work with high quality, affordability and reliability.”

The IT industry is now undergoing a similar industrial revolution to the one the manufacturing industry underwent couple of decades ago already.  As with the manufacturing industry the lack of a common modeling language was a major inhibitor that limited the scale and speed at which the IT or NFV industries are able to collaborate, and consequently innovate.

When we think of portability in this context, it becomes clear that not having true portability is simply not a  viable option.

Comparing portability approaches - TOSCA abstraction vs. Common Language Runtime  (CLR)

There are two main approaches for handling TOSCA portability that can be classified as follows:

• TOSCA Abstraction - In this option we rely on TOSCA as a spec and let each provider implement the spec in their own way.
• Common Runtime - The other approach is having a common language runtime in which we use not just a common spec but also a common runtime that implements the TOSCA spec.

To compare which of the two approaches is best suited to deliver the portability promise I would start by looking at how other languages handles the portability challenge.

Lessons from the past on language portability - (C++ vs. Java)

Common language specification - different runtime

C++ is a good example for the first approach. We have a common spec and different providers implemented their own compiler that follows that spec. The result of that experiment is that C++ never really achieved true portability. Only when GCC became the common compiler, did we ultimately get much closer to true portability in Linux. 

 

Common runtime and spec

 

Java on the other hand was born on the promise of portability - “write once run anywhere”. The reason why Java was much more successful than C++ in this regard is the use of a common runtime (JVM), which provided a common substrate for executing the Java bytecode format and the Java language. On top of this, the ability to define a clear separation between the Java language and the common runtime made the Java runtime a great platform for supporting multiple languages in addition  to Java, at a later stage.

 

What can we learn from C++ and Java ?

 

TOSCA is a DSL and comes with many characteristics of a true language such as interfaces, inheritance etc.  The lessons from the C++ and Java experience is therefore a useful lesson when we look for the right option for achieving true portability with TOSCA.

Based on this analogy, I would argue that if we want to achieve true portability we shouldn’t solely rely on a common spec, but rather allow each provider to implement the spec all while relying on a common runtime that implements the spec. By doing so we ensure that there's going to be one common way to interpret the spec, especially in areas where the spec is vague (and theres are still many of those areas). It is also important though to provide a useful platform to feed the spec with new features, this however should only be after they have been tested and validated. Without a common runtime it’s going to be much harder to experiment with new features before they become part of the spec.

Using a common runtime with other orchestration engines and data models

The challenge with having a common orchestration runtime is that while a common runtime may provide a common way to interpret the spec it may be limited by its ability to support other orchestration platforms. In the complex world of IT we cannot assume that there will forever be a single orchestration engine that will rule them all, and we need to have a way to integrate with other orchestration platforms.  Some examples are network orchestration (ODL), data modeling languages such as (YANG) or container orchestration such as Kubernetes.

There are multiple ways in which this can ultimately be achieved.

Using TOSCA as an abstraction layer

In this way, we use can the TOSCA DSL (without the common runtime) and integrate it as an abstraction layer on top of other orchestration API.

The challenge with this approach is that by doing so we can only achieve limited portability as this leaves a high degree of freedom for interpreting the spec which ultimately results in different ways of actually applying portability in the real world. In addition, the complexity of adding TOSCA support for systems that were not designed to support TOSCA adds a fairly high barrier of complexity for integrating those systems.  That is because, with this approach such platforms need to implement ALL of the TOSCA features, and not just the relevant subset that maps natively into their platforms.

Extending the common runtime through plugins

The other option would be to open the common orchestration runtime to support other orchestration platforms and data models through a set of plugins.

In this specific case plugins should provide a simple way to map other orchestration platforms as yet another TOSCA type library - a good example to that is the work we at Cloudify have done around integrating Kubernetes into TOSCA, as well as integrating other data models, for example TOSCA/YANG integration.

Mapping the current options for TOSCA Runtime

OpenStack TOSCA parser projects

• The OpenStack TOSCA Parser - This OpenStack project maps TOSCA into the Heat orchestration project. In this context, Heat serves as the execution platform. The main limitation of this approach is that Heat itself was designed to be OpenStack-specific orchestration and by tying TOSCA tightly to OpenStack through Heat, we are unable to leverage the TOSCA portability promise. We also inherit other limitations of Heat, which unlike TOSCA wasn’t designed to support the full application lifecycle management.

• Project ARIA - which was announced during Mobile World Congress 2016, is a new, open source project that aims to provide a reference implementation of TOSCA and make it easier for both network providers and carriers to embrace the standard through a simple Python library.

Final notes

The IT industry is going through an industrial revolution similar to the  manufacturing industry a few decades ago. Without a portable and standard CAD model in the manufacturing industry we wouldn’t have been able to build complex systems such as the Boeing 787 in a way that is economically possible.

Having a similar standard and portable modeling language is as critical to the IT and Telco industry to enable full automation of complex systems, and to open the door for more intelligent self-managed systems, and provide better cost efficiency.

TOSCA provides a standard modeling language that is a front runner in this regard, however to realize true portability we need to learn from the lessons of other languages such as C++ and Java on what should be the best approach to enable this truly achievable. Having a common spec is often not enough as we’ve experienced with C++, and the addition of common language runtime (CLR) as in the case of Java proved to be significantly more successful model.

Standards bodies such as OASIS, ETSI, MEF as well project Open-O and open-MANO (OSM) provides a great platform for bringing vendors and customers together to agree on this, and other supporting standards to make this a true collaborative effort.

I hope that with this post will help to advance this discussion toward a final conclusion.

CloudFoundry and Docker Swarm Losing the Battle of OpenStack Container Management; Cloudify up 20% According to OpenStack User Survey

The latest OpenStack user survey on application platforms reveals an interesting trend when comparing this year’s survey with last year’s. See below.

2015	2016
https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf	http://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

 

Here are some things you might have noticed:

1. Kubernetes gained popularity 30% up (from 21% to 27%) over CloudFoundry which is down by 30% (from 23% to 16%) in terms of popularity! And Mesos which is down by 25% (from 16% to 11%) which put Kubernetes the leading platform for container management in OpenStack
2. Docker Swarm went down in popularity by 80% from 16% to 2%! Cloudify popularity increased by 20%!

Outside the tent

What’s interesting about this list is that none of the application frameworks listed on this survey are specific to OpenStack or even developed under OpenStack's Big Tent.

There are some interesting lessons to be learned in this regard:

1. Developers tend to choose an application platform that is not tied to a specific infrastructure.
2. The fact that OpenStack is open source makes it possible to provide native integration to OpenStack by external projects without being part of OpenStack thanks to the rich set of OpenStack APIs as described in this session:How to Develop for OpenStack APIs

The main question that comes from all this is: Should the OpenStack community continue to invest in building application framework projects or simply focus on making the integration of external projects with OpenStack simpler?

Interestingly enough, during the summit, Thomas Morin, Network Architect from Orange Labs, provided great insightinto why they tend to select open source tools from the broader ecosystem rather than limiting themselves to OpenStack projects during a panel discussion on Open Source NFV Lessons Learned from End Users which also included members from ATT, NTT and China Mobile. I think that Thomas' view is a good representation of how most OpenStack developers think when they make their choice of application platforms and tools.

This was also echoed by Mark Shuttleworth, founder of Canonical, in his comment about the future of Big Tent:

“If you look at OpenStack it has this frame big tent, well the truth is the tent will collapse and that's going to be traumatic for everybody,” said Shuttleworth.

This is not to say that the whole of OpenStack will fail, as he believes that open source will continue to grow stronger as an Infrastructure as a Service. The core of network and compute will remain while all of the complexity on top with the as-a-Service components will disappear. (Source)

Cloudify updates from the summit

 

Anyway, the Austin summit was probably the best event yet for the Cloudify team with more than 6 talks, 12 people on the ground, a book signing, back to back meetings and lots of new stuff - here is a short summary for those who missed the party.

Cloudify was noted as one of the top 5 application and container frameworks according to the OpenStack survey!

 

 

The following sessions from the summit provide a good overview about how Cloudify works with OpenStack:

• Cloudify integration with Kubernetes - Demonstrates how you can use Cloudify to install Kubernetes on OpenStack and other clouds, manage kubernetes micro-services composition and dependencies as well as manage a hybrid deployment of micro-services and non micro-services applications. We also announced the availability of new Cloudify/Kubernetes as a service
• Project ARIA - Simple TOSCA based NFV Orchestration- demonstrating how you can deploy NFV application and service-chaining through a simple python library. See also the ARIA session from the summit here
• Cloudify Play List from the summit - We've put together all the Cloudify related talks from the summit on youtube playlist

This week we also announced the NFV Lab on demand which shows how you can get your own private OpenStack environment with Cloudify pre-integrated on-demand and experiment with orchestrating their first NFV service.

I would like to close by thanking the members of the community for their support.

I really enjoied being in Austin again and were now fully energised to continue the OpenStack  momentum as a co-organisers of the OpenStack Day Israel event and the first OpenStack Days East in NYC!

 

Where AT&T Leads, Cisco Cannot Follow

Preface

The Innovator’s Dilemma faced by vendors of proprietary networking stacks is well documented. The blogsphere and the trade media have well documented the disruptive, one-two punch of open source NFV and white box hardware that threatens to undermine their business models.

But just this week, at OpenStack Summit in Austin, we saw Sorabh Saxena, Senior Vice President of Software Development & Engineering at AT&T showcase on a keynote stage before more than 7,500 people (plus the online audience) just how mature this disruption is. His company, faced with multiplying demand for networking capacity over the next four years, has embraced NFV and white box hardware not so much as an inoculation against vendor lock in (though this is part of it), but as a necessary tool for agility and speed.

And yet, the existential threat to companies like Cisco is present, real and almost certainly the end of an era. In this post, I’ll explain what is happening and what we all should do.

But first, a bit of background.

Open Source has been at the center of some major disruptions in the high-tech industry. Linux changed the entire operating system landscape. Hadoop, MongoDB, Cassandra and now Spark lead the disruption in the way we manage data. Android changed the entire mobile world to name a few.

The networking world has been very late to join this open source disruption and was kept for a long time behind a walled garden. It didn’t take long for the wall around this garden to come down.

We are now facing a time in which open source disruption is hitting the networking world and making big waves in the form of NFV and SDN, and, like other similar disruptions, the first to be hit by that disruption are the incumbents like Cisco.

As in other, similar disruptions, the first reaction by those incumbents is denial which is later followed by other tactics such as camouflage (if you can’t beat them, join them). But, at the root of many of those disruptions sits the big elephant in the room. Those publicly traded companies have an inherent conflict of interest with this open movement that is rooted in their business and revenue model. A conflict that can’t be bridged easily just by sponsoring or even contributing to open source projects.

As with previous disruptions, this revolution will spawn a completely new generation of companies that was born to lead this disruption.

For the past three years, I’ve been actively involved in this movement and I’m still seeing lots of confusion that mostly comes out as fear of change by some carriers who want to join the movement but don’t know how.

So, for this post, I wanted to share my perspective on how carriers should respond to this change and avoid the risk of moving too late to a technology that is already fundamentally transforming telecom.

I’ve chosen Cisco as the representative of the incumbents, although their use case can be applied to the stories of other vendors of proprietary networking stacks.

Open Source NFV Initiatives Gets Real

The NFV open source movement has gained serious momentum over the past two years, with OpenStack being the main driving force behind this, by providing an open source substrate to sustain the NFV movement.

This has led to an influx of projects with a more specific NFV focus that have emerged over the past year, such asOSM which is led by ETSI, as well as OPNFV and Open-O which are under the auspices of The Linux Foundation.

Other projects such as Tacker (a Brocade-led NFV orchestration for OpenStack, project) and ARIA (reference implementation for TOSCA) have also been created to support those initiatives. The fact that open solutions for complex, full-fledged NFV environments are even available on-demand, demonstrates the speed at which the NFV revolution is moving.

Open Source Reshapes the Way Standards are Being Defined

What’s interesting is that standards bodies such as ETSI and MEF, which traditionally used to work in long cycles and in fairly closed discussion groups, are now redefining themselves to fit into the open  source paradigm, and are embracing open source technology as a means to drive new standards.

The MEF, for example, will even be running an open Hackathon around a new flagship initiative, LSO (Lifecycle Service Orchestration), as a way to define their new API. Clearly, this is a big change in the way standards are defined in the telecom world.

AT&T Leads the Open NFV Agenda, a Tectonic Shift

AT&T recently announced their Enhanced Control, Orchestration, Management and Policy project (ECOMP) during the the Open Networking Summit. The project proves that open source can actually support the core backbone for one of the biggest carriers.

At the OpenStack Summit yesterday, AT&T won the OpenStack SuperUser Award for their contribution - the announcement includes fascinating statistics that show the scale at which AT&T invested in adopting an open source based stack, which includes 70+ OpenStack deployments with plans for 90% growth. They also trained more than 100 of their employee to learn how to work and contribute to OpenStack.

This, on top of the Orange Labs functional testing of OPNFV (although much smaller in scale) - another great use case that was presented on OPNFV last year - highlights another big shift that is happening as a result of this open source movement. The Orange Labs example illustrates how open source enables telecoms to build their own infrastructure without being dependent on the “high touch” vendor dependency of yesteryear.

Open Standards for NFV Orchestration and Modeling Gets Wider Acceptance

TOSCA is at the center of many of the new open orchestration projects and is becoming the clear winner of common orchestration modeling languages. Project ARIA, which was announced during Mobile World Congress 2016, is a new, open source project that aims to provide a reference implementation of TOSCA and make it easier for both network providers and carriers to embrace the standard through a simple library.

YANG is also known to be a popular modeling language for defining networking devices widely embraced by the networking community. Until recently, there was a big debate in the telecom world whether YANG should also become the standard modeling language for orchestration.  The ability to combine TOSCA and YANG integration is gaining wider acceptance now, as this approach seems to provide the best of both standards - where TOSCA is responsible the service lifecycle and YANG controls the network configuration of the VNFs.

The Open Source Disruption in NFV and Cisco’s Built-in Conflict

Cisco is one of leading network providers and it is no surprise that NFV needs to fit into the center of its strategy. Cisco is also making fairly big investments in aligning itself with the open source movement,  specifically around OpenStack, but there's one issue with this that stands out.

The Elephant in the Room

A quick look at Cisco’s revenue model for 2015, outlined here, reveals an internal conflict with their joining the open source movement (the 2016 reports shows a similar breakdown).

We can clearly see that Cisco’s primary streams of revenue come from selling network devices, and therefore moving to a software defined networking model would come at the expense of their current physical device business model.

Selling open source based solutions drives a completely different business and revenue model, and, despite all the effort that Cisco has invested in open source, these will never serve as a new growth engine at the levels that Cisco used to sell before.

Another point that is important to note in this regard, is that open source often comes with a demand for an open ecosystem by the users, i.e. carriers, in this case.

Cisco, on the other hand, was used to “playing solo” when it comes to networking, and their solution was built as a full Cisco stack. Cisco even went as far as buying companies that led new standards such as tail-F that led the YANG model & support.

Obviously, this model doesn’t fit well with the the open movement, in which carriers are looking for flexibility to choose their own stack, and not being dependent on a single vendor.

This puts Cisco in serious conflict between where the market is heading and its current business model. For publicly traded companies that are measured by their quarterly bottom line, it is hard to see how Cisco could make a shift into this new world without a complete shakeup similar to the one we've seen recently with Dell & EMC.

Cisco is Not Alone

While I chose Cisco as a means to demonstrate the dissonance faced by leading networking vendors in the wake of an open source revolution, they obviously are not the only player that will suffer a big hit by this disruption at the heart of its core business. Other players such as Ericsson, Nokia, and Amdocs, similar to Cisco, in being used to selling proprietary stacks and turnkey solutions, are also exposed by this disruption.

Maturity is Not Enough

The only advantage that Cisco and the other “high touch” players have is the maturity of their stack and brand.

Indeed one of the leading current deficiencies with choosing the open source route right now is the maturity of the stack, as many of the open source players are still fairly new and there is no such thing as a  “fast forward” on maturity.

Open source solutions are also often times built out of many moving parts, which requires a completely different skillset and organizational structure for adopting and embracing an open source strategy.

Having said that, it is clear that if we follow the maturity argument on any of the examples that I mentioned before, we would have chosen Oracle over Hadoop or MongoDB, or Blackberry over Android we now know clearly that those who have taken that route have lost the game completely.

In addition, maturity can be a fairly tricky thing as many of the “mature” solutions are, by definition, built out of old architecture and concepts. So, by choosing those solutions you're basically betting on building your future stack on technology of the past. That’s not going to work - sorry.

AT&T serves as a great example of how telecom organizations can overcome this limitation, by building an infrastructure and an organizational structure that fits with this open movement.

Final Notes - The Blackberry vs Android Dilemma in NFV

Many of the carriers are now evaluating their first steps toward NFV. For many of them this journey looks scary, as they have gotten accustomed to being “hugged” by the big vendors, and all of a sudden need to take ownership of their own stack.

At the same time, starting a new NFV initiative using old habits is worthless, as it will probably cost even more than the current system.

Instead, carriers should learn a lesson from previous disruption, follow in AT&T’s footsteps, and be careful not be tempted to buy into the “big hug” from their old partners who now find themselves in a conflicting position with their business goals.

Let me explain what I mean by lessons from previous disruption:

• Learn to work with new vendors - Carriers should be ready to work with new players that come with open source DNA and open source business model. While many of these players may be new to the market, and less mature by the old-world standard, they have much stronger alignment with the carrier's business goals and could play better as a “change agent”.
• Partnership with multiple vendors vs turnkey solution by a single vendor - Carriers should adopt a partnership strategy with their vendors and less of the old customer/vendor relationship, in which the expectation was to find a single vendor that will deliver a turnkey solution for all their needs. To do that, carriers need to adopt an integration strategy to allow faster adoption of new technologies by different vendors as well as simplify and shorten the business engagement process, and with that, reduce the barrier for new vendors thus increasing the competition and reducing their costs.
• Control your stack and cost - In this world, carriers need to also have that development skillset in order to have much stronger ownership of their stack and therefore cost.
• Embrace webscale best practices - The shift toward cloud-based infrastructure requires a shift toward a cloud-native strategy. Rather than reinventing the wheel it’s best to learn from the best practices of other industries that have made the shift toward cloud, such as Netflix, and embrace webscale best practices such as continuous development, automate everything, containers etc.

A Path Forward—What We Do Next Matters

The bottom line of all this is that carriers that want to survive this disruption have to learn how to control their stack as this is the only way in which they could control their costs and speed of innovation. Without it, they stand no chance of winning at this game.

Unfortunately, there's no shortcut and this move is going to be painful—but we could still make it smoother by introducing new ideas to shorten the learning curve such as the new NFV lab and making the product simpler to use as well by better aligning and collaborating with others who face similar challenges, even if they are competitors, because the challenge is far greater than one organization can solve.

Major consumers of networking stacks have shown us a path forward. Forged in the hackathons of open source projects, and powered by the silicon of white box ODMs, NFV is no longer an idea with a few, isolated test cases. As AT&T showed yesterday before an audience of thousands, the technology is mature enough to deploy globally in dozens of data centers, forming the framework of networking plant that will manage network traffic for, arguably, the world’s most trusted brand in network performance.

So, what should we do? We should do all we can to join hands with telecom operators worldwide to advance these open source technologies. Incumbent vendors have nearly zero incentive to do so. If we want to be a part of the revolution that will redefine networking, we need to help the side with the most to gain from success.

Let’s not set ourselves up for a similar destiny to that of Blackberry, or Nokia for that matter.