Dr. Recep Ozdag (@DrOzdag) is senior director in Ciena's Blue Planet division, and is a regular speaker at industry events on the topic of SDN/NFV.

This is the sixth in a series of posts highlighting Blue Planet’s new architecture and features.  Other posts in the series:

• Ciena Blue Planet unveils the dawn of service orchestration
• TOSCA and YANG? It’s not either/or…it’s both
• Apply BPMN to Enable Network Transformation at the OSS
• Behind the scenes with Ciena's new Blue Planet architecture
• What is the "Right" Approach to Open Source?
  

While the topic of container-based micro-services seems to have become a hot-topic overnight in the networking and telecom space, the concept has actually been around for a while. The micro-services software development approach had its genesis in the IT space, championed by large web 2.0 firms like Netflix who were looking for more flexible mechanisms to change, adapt, test, and scale their cloud applications vs. the legacy monolithic approach.

Fast-forward a couple of years to the present day, and the use of Docker containers as a primary tool for building software applications has become more mainstream. Unfortunately, while this is certainly the case in the cloud software space, it hasn’t been true in networking and telecom. Until now.

As a case in point see AT&T's blog post where they highlight that micro-services will play a major role in their goal to virtualize 75% of their network by the year 2020. This was followed by an announcement from BT several weeks ago that containers will play a key role in NFV. And finally, Ciena also recently announced that our award-winning network virtualization and orchestration software, Blue Planet, had also evolved to a container-based micro-services architecture.

So, what are micro-services, and why is this approach so important in the network virtualization space?

To explain micro-services, let’s first discuss the traditional software development approach used with the development of the first generation of SDN controllers and NFV orchestrators. These were developed as monolithic, non-modular software applications. While this approach enabled suppliers to bring a solution to market, the architecture of these software systems did not provide an easy way to scale up to handle large networks, nor were they designed to provide modularity to support non-disruptive updates. And most importantly, these monolithic platforms didn’t allow for any customization to add new features without completely re-building the software stack.

The limitations of this software approach are becoming more apparent, especially as more applications are being deployed for the cloud. Even small changes and feature enhancements require substantial effort such as re-working code, recompiling, re-running regressions tests and redeploying the software. Furthermore, updating the software may result in interruption of an operator’s service. Because of the risks of interrupting services, as well as the significant effort required to overhaul the entire code, monolithic architectures tend to slow the adoption of new features to a glacial pace. Not a good place to be, especially, as we plan to adopt more IT-based concepts in telecom where agile software and frequent updates and enhancements are crucial to remaining competitive.

Scalability is another challenge facing software applications based on monolithic architectures. When scaling a monolithic application, the entire application must be scaled, rather than only the parts that require more resources. For example; if more servers are added to the overall compute pool that an NFV orchestrator can utilize to deliver services, only the parts of the orchestrator related to infrastructure management would need to scale up to deal with the increase in number of resources. The GUI, the parser, the VNF manager do not need to scale up as they are not related to these changes. However, a monolithic application does not have a separate module that is designed for managing just the infrastructure resources. Therefore, the whole software system would need to be scaled up, resulting in consuming significantly more resources than needed.

What's better about a micro-services based architecture?

A micro-services architecture eliminates the challenges associated with monolithic applications, providing network operators the ability to deploy and benefit from cutting edge web-scale technologies, reduce resource utilization, quickly add new features with no service interruption, and easily integrate 3^rd party solutions. Here’s how.

Micro-services are relatively small, autonomous services that work together. Each service is focused on doing one thing very well and is autonomous – working as a separate entity. One micro-service might be deployed as an isolated service or together with other services. In general, these isolated, containerized services communicate with each other using language-agnostic APIs. For example, one module may just provide a GUI, another module may just provide the ability to talk to a router, and another module may focus on communicating with the OSS and so on. I think you get the point.

A monolithic software application includes and ties all functions tightly together into one set of code. In a micro-service architecture, each service provides a specific functionality and is tied to other services through APIs.

Blue Planet is re-architected to be a container-based, micro-services platform

The recently re-launched Blue Planet platform under Ciena is built around the concept of micro-services, with each micro-service running in its own container. This effort, started over a year ago, was initiated based on customer requests for more programmability, openness and modularity.

As a result, we have essentially opened the hood of Blue Planet so that they can make use of their DevOps-type resources and skills (if desired) to quickly modify the platform, add new micro-services, and program the platform to build differentiated services. For example, a new virtual or physical device can be added to Blue Planet by just adding a micro-service that talks to that particular device without the need to completely change or even reboot the platform. Or, rather than using the analytics and policy engine micro-service that is installed by default with Blue Planet, customers can easily plug-in an alternative application by a third-party vendor. Needless to say, the new architecture also makes it very easy to integrate open source solutions, thereby benefitting from the continuous improvement provided in the open source community.

OK, let’s be specific, what are those four reasons you want to deploy your network virtualization software with a micro-service architecture?

1. Easy Customization and Best of Breed Solutions: Since each service is decoupled through API calls, the network operator or the system integrator can easily customize and tailor the platform by choosing the best software to accomplish a particular task, benefiting from a best of breed solution by utilizing the latest technologies, open source options, or 3^rd party solutions.

2. Resilience: High availability and resiliency are very important. With this type of architecture, if one component of a system happens to fail, the failure doesn’t cascade bringing down the whole platform nor does it affect the service being delivered. Regardless of the root cause, problems are isolated and the rest of the platform carries on operating with no disruption to the overall service being provided.

3. Simplified Scaling: As the demand on the platform increases, rather than scaling all the components, the scaling can be focused on the problematic micro-services that need to grow with more resource allocation. The result is frugal use of existing resources with, thereby lowing expenses and improved return on investment (ROI).

4. Ease of Deployment: Since each service is decoupled, services can be upgraded, new features can be added and deployed independently of the rest of the platform, with no down-time or interruption in the overall business.

Container based micro-services essentially disaggregate the software stack just as SDN and NFV have disaggregated traditional hardware-based network appliances. With this new architecture, Blue Planet provides a truly next-generation network virtualization and orchestration platform that delivers previously unachievable level of service programmability, agility and modularity.