{{announcement.body}}
{{announcement.title}}

Network Function Softwarization: Microservices and Disaggregation

DZone 's Guide to

Network Function Softwarization: Microservices and Disaggregation

Breaking up the traditional monolith into small microservices and leveraging the container and orchestration capabilities of cloud-native computing.

· Microservices Zone ·
Free Resource

The connected world has put new requirements for agility and elasticity on the development and architecture of applications. Breaking up the traditional monolith into small and nimble microservices and leveraging the container and orchestration capabilities of cloud-native computing, the practices of developing and operating applications went through a real revolution to keep up with the demands of business and users.

Very much at the same time, networking has gone through its major transformations resulting in decoupled control and data planes (SDN), a diversity in Network Operating Systems (NOS), and more flexibility to program the packet processing directly in the silicon. Open software and hardware initiatives driven by major cloud organizations resulted in disruption of the appliance model in favor of a disaggregated hardware and software model, a model which proved its worth in the compute side of the data center. 

Security gear, however, remained largely unaffected by the application and network transformations and the appliance model in gatekeeper or cloud backhauling designs withstood the test of time. And this is about to change. 

While the internet can adapt to higher throughputs for richer data and more connected devices, and applications can scale to handle those massive numbers of connections in hyper-scale datacenters, the one thing the internet and the hyper-scale datacenters cannot adapt to are the new requirements for lower latency.

A World of Connected Devices and Applications

Innovations in the connected world are craving for lower latency and near real-time communications and decision making. Autonomous cars, for example, are becoming aware of their surroundings. A car that knows the speed of the cars in front or when traffic lights are about to turn red can adapt its behavior. 

Not only will this result in fewer traffic accidents, reducing the number of traffic victims and jams, but it will also impact fuel or battery efficiency because of the anticipated coasting and accelerations eventually resulting in greener cities. Autonomous cars can act on their immediate surroundings using predictive algorithms that get input from connected devices in their immediate vicinity providing this information is accurate and timely. 

Traffic information has a limited validity radius in terms of locality. A car in one part of the city does not care about the real-time state of traffic lights in other parts of the city, at least not if they are not on their navigation path. Backhauling communications to a central cloud instance for all connected devices in a larger region has no value and will only but increase the latency of responses and decisions, hence the need for local and decentralized communications and processing. 

There is still interest in central processing for statistics reporting, billing or traffic predictions for navigation systems using big data and deep learning technologies, things that are to resource-consuming for local processing. However, the near real-time decision making and communication of information can be done at the edge of the network.

Data Center Topography

IoT and immersive technologies are driving the processing to the edge, the physical location that connects things and people. In consequence, colocation and smaller data centers are built in regional locations to bring the compute and services closer to the customer. The edge computing is part of a larger distributed computing topology where data is aggregated in big data processing and storage facilities that are centralized in the cloud while local processing and real-time decision making are done in the distributed regional data centers or the edge cloud. 

Very large cloud facilities hosting cloud services are taking advantage of locations that have cheaply available electricity, often harnessed from renewable energy and the presence of cool air outside to build more efficient cooling systems. Facebook, for example, decided 8 years ago to build a large data center 100km south of the Arctic Circle because of its access to renewable energy and the cold climate. 

Smaller data centers are built closer to populated areas to enjoy the proximity of connected devices and people. They enable the edge cloud while being the preferred location for colocation and private cloud deployments as their customers' engineers have easy access to those locations. 

Mobile Edge Compute

Mobile Edge Computing is an ETSI defined network architecture that enables processing close to the edge of the radio network. Traditionally, radio networks used to backhaul all mobile communications to a central point for routing, processing, and security resulting in a predominantly north-south traffic pattern.

More recent architectures such as 5G significantly change this design and allow for east-west communications and edge computing by putting micro-scale data center facilities close to the radio antennas. This architecture provides low latency and near real-time decision making, a hard constraint for the earlier example of making cars aware and act on their surroundings.

Securing Cloud Applications

Organizations are well aware and versed in securing online applications, whether these are hosted on-premise, in their private cloud, in a public cloud or multi-cloud. In each of these use cases, all traffic to the application is routed through a central stack of security functions that provides web applications and API protection, bot management, DDoS protection, etc. 

The nature of many of these online applications is typically not impacted by variations in latency and as such not impacted by backhauling traffic through a central stack of security functions such as cloud-managed security services. To increase scale and offload central instances, applications can leverage Content Delivery Networks to cache and offload requests for static and repeated content, but in general, all query and data related transmissions are still going up to the central application. 

Securing Cloud-Native Applications

Cloud-Native applications leverage the advantages of cloud computing through the use of microservices and containers. These applications can, up to some extent, be protected by gateways or backhauled security services. Gateways will only ensure north-south security inspection while the inherent nature of microservices provides for an increase in east-west activity that can easily undermine the security of the application. 

Netflix's red-team demonstrated this through an Application layer DDoS attack where a limited amount of queries through the API gateway resulted in an avalanche of east-west queries inside the microservice architecture, eventually leading to exhaustion and overload of the microservices in the fabric.

As microservice architectures are moving to encrypted and authenticated API requests between every node in the fabric, conveniently provided by newer Service Mesh architectures, all communications are turning dark and inspection of east-west traffic within the microservice fabric becomes nearly impossible. 

Securing microservices in encrypted service meshes is more effective when the security component is moved down, closer to the application/service itself. Each POD is a Service Mesh that consists of a sidecar proxy that provides, among other things, the routing and encryption of the communications inside the fabric. The sidecar reverses proxies traffic to the microservice running inside the same POD in cleartext.

By consequence, the best placement for inspection of traffic inside a microservice fabric is between the sidecar and the service. Running as an independent proxy process between the sidecar and the service allows access to all cleartext requests and responses, while not enforcing any dependencies on the sidecar or application as would be with sidecar plugins or run-time components that hook in the application.

The nature of microservices is such that independent services are responding to client requests. Depending on the request, not every component is or should be aware of the client's communication. Microservice architectures can scale and dynamically duplicate services to process higher demands such as when the load on a specific service increases. By consequence, a security component on one microservice will not have the full context of the communications between a client and the service mesh. 

To be aware of the full context of a client's interactions with a cloud-native application, all information regarding the client's interactions with every microservice in the fabric needs to be centralized. 

The security components that sit between the sidecars and the services in each POD form the data plane of a cloud-native security solution while the centralized component, which could or should be a cloud-native application in its own right, provides the control plane or the 'brain' of the solution.

Securing the Cloud and Mobile Edge

Securing the edge is not much different than securing cloud-native applications. Cloud-native applications leverage containers and use orchestrators such as Kubernetes to provide dynamic management of container fabrics. Improving security, traceability, and availability of the fabric can be achieved by integrating side-cars with their respective orchestrators such as Envoy and Istio. 

The cloud edge and mobile edge leverage container technology, whether or not controlled by central orchestrators or the added convenience and security of service meshes. The key technology is, however, containers and the key design pattern is distributed. As such, the overall architecture to secure in Cloud and Mobile Edge is one of the distributed container services, which can very well leverage the components and security architectures of cloud-native applications to secure and manage them at scale.

Softwarization and Virtualization

Network Function Virtualization and service chaining can be achieved by virtualization physical appliances with added abstraction layers to provide programmatic configuration and control. A virtual appliance is still very much an appliance in its own right, even if delivered in a software package form factor. The virtual appliance has data and a control plane of its own and on top of the existing control plane interfaces new APIs are added to provide programmatic access to query and change the state and behavior of the appliance's data plane. 

A virtual appliance, while a software version of the physical appliance, is still very much a monolith: some configuration changes require reboots, updates cannot be performed without downtime unless a cluster is introduced. The limitations of physical appliances still very much apply to virtual appliances as they were designed as an appliance in the first place. Applying the same paradigm as with cloud-native applications, a network appliance can be approached as a monolith and exploded in its core data plane functions, exposing dedicated API. 

The control plane can be centralized and call on the APIs of the data plane functions that run as containers distributed in the fabric, whether this fabric is a data center network fabric or a distributed cloud/mobile edge. Moving from virtual appliance to cloud-native functions provides more scale and granularity. The footprint of a container is typically much smaller than the footprint of a virtual appliance. 

Starting a container is as fast as starting a process on the server, typically in the order of milliseconds, while boot a virtual machine and initializing its data and control plane will take orders of magnitude longer. Longer start-up times limit the use cases for dynamically scaling in or out as well as flexibly setting up and destroying service chains on demand. As DevOps is very much accustomed to working with containers, the move from virtual appliances to containers should be easier in terms of integration and acceptance with the DevOps teams. 

The design of a security platform as a cloud-native application allows one to create a central control plane, hosted in a public or private cloud, which controls the distributed data plane which can be protecting public cloud services, private cloud service, cloud or mobile edge services, etc. 

By design, the central control plane will aggregate all data and can provide big data intelligence and processing on the security of all the different applications and services as a whole. It provides full visibility and deep intelligence central while distributing the local processing and decision ensuring the lowest latency and best security.

Network Disaggregation

The hyper-cloud providers such as Facebook, eBay, Twitter, Google, Amazon, etc. have always been accustomed to being in full control of their computing software and hardware, up to building their servers and even design their hardware components (Azure SmartNIC) and custom silicon (AWS Nitro). After compute, the network was next and the router and switching market went through a transformation. 

The typically proprietary, single-vendor, tightly integrated hardware and software boxes, commonly referred to middleboxes, had to make room for open, programmable devices where hardware and software became were decoupled. White- or brite-box hardware and network operating software (NOS) were decoupled and open-source NOS'es,  as well as open-source hardware such as the Open Compute Project (OCP), joined established vendors in a new ecosystem that provide richer and programmable networks. 

For high scale, low latency and high throughput applications, vendors provide SDKs that allow direct access to the silicon and new abstraction interfaces such as the Switch Abstraction Interface (SAI), OpenNSL, OF-DPA, etc. allow north-bound exposure for network functions, controllers and orchestrators. 

Programmable silicon and new programming languages such as Barefoot's P4 and Broadcom's NPL allow third parties to customize even further the packet processing pipelines of the network hardware and perform flexible operations at wire-speed. 

Certain NOS and hardware platforms add host and machine virtualization support and allow third parties to deploy and run containers or VMs on the control plane. Combined with programmatic access to control and data plane functions, 3rd parties can enrich network devices with new wire-speed capabilities that provide scale and throughput with low latency. 

These new capabilities allow cloud-native network functions to run directly on network (hardware) devices and perform wire-speed processing of packets in data centers, cloud, and mobile edges as well as on Universal CPEs (uCPE) in the enterprise premise, effectively extending the cloud-native security platform and moving closer to the data path with additional hardware (servers) to be deployed.

Summary

With new requirements for connected applications come new architectures. Securing these new network architectures will require a transformation from a central to an edge-driven security model, where security decisions are made locally in the edge while decisions are based on centralized intelligence in big data-driven control planes.

Networking and applications have gone through the transformation cycle to adapt for new architectures through microservices, DevOps, decoupling the control and data plane, programmability, and disaggregation. The security world is now facing a very similar transformation and will leverage most of the technologies that enabled the network and application transformation.

Topics:
cloud native computing, container as a service, edge computing, kubernetes architecture, microservices, network functions virtualization, software defined networking

Published at DZone with permission of Pascal Geenens . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}