Multicore CPU and Functional Programming

Software-defined orchestration is not limited to network applications. As those who, like my own company, focus on Functional languages know only too well, good software orchestration can be delivered on a globally distributed scale, or on an atomic scale within a single CPU's applications.

As chipsets are produced with more and more cores, the complexity when running many processes at the same time (concurrency) increases. While it is possible to manage this complexity in an object-orientated programming language (OOP), the code to handle every exception and task also grows. This takes time to engineer, and can increase the number of bugs that have to be addressed. In a Functional programming paradigm the composition of the task leads to extremely small tight code, even for massively concurrent process deployment. This in turn reduces the time to engineer and reduces the number of bugs that have to be addressed.

While the paradigms of SDN and VNF orchestration are evolving fast across networks, a similar - potentially continuous - strategy also applies within local clusters and, as core's increase in density, it also increasingly applied within the single computer.

In my own company our adoption of Functional programming (using Erlang) has positioned us some way ahead of many companies that are considerably larger and better known. We are able to orchestrate individual processes within a single compute unit in an almost identical that way we can provision entire global networks. In contrast to OOP languages which have to anticipate potential failure and design/architect for those conditions, Functional programming embraces failure and naturally recovers from such failures by design, seeking to kill and replace the failed workflow instantly. This model ensures that Functional platforms achieve extremely high availability even at scale.

To content delivery network architects, who typically deal with large volumes of concurrent processes ranging from transformation of a video asset within a specific single origin, through to huge volumes of video being delivered via expansive distributed computer networks to ever-increasing audiences, the adoption of Functional programming is a simple fundamental decision that will greatly improve every aspect of their service operations and implementation.

Functional Programming and Containers

There is an additional benefit to the use of Functional programming languages too. Because there is no shared memory state in Functional programming, there is complete isolation between processes. This means that the isolation that containers are used for when deploying multi-tenant applications within shared infrastructure comes baked into the Functional language. While containers continue to be useful for shrink-wrapping large OOP routines

(ensuring that when they are removed the underlying infrastructure returns to a clean state) and while Functional programs can, of course, be deployed in containers, it is usual that Functional programs do not need the isolation that containers offer.

A language such as Erlang can orchestrate, achieve isolation, and scale extremely well, with natural resilience and recovery built in. So in a pure Erlang environment we do not need to use containers, and this further simplifies our architectures.

< Prev   CONTENTS   Source   Next >