lighty.io, at its core, manages network devices in a virtualized network. It is therefore crucial, that it works as a robust, and at the same time, stable tool. When deployed in modern networks, lighty.io itself can not guarantee stability and an error-free network.

PANTHEON.tech engineers have managed to extend OpenDayligh/lighty.io capabilities with Akka Cluster. This fulfills requirements for dynamic, horizontal scaling of lighty.io applications.

Welcome, lighty.io, to the world of cloud-native & micro-services.

lighty.io & containers

Thanks to lighty.io removing Karaf and using Java SE as its run-time, we have made it one of the most lightweight SDN controllers in the world. This makes not only lighty.io‘s but OpenDaylight’s components usable in the world of containers & micro-services.

We have further managed to include horizontal scaling in lighty.io and are proud to announce, that auto-scaling, up & down functionality in lighty.io Akka Cluster is available.

Akka

Akka is a set of open-source libraries, which allow for designing scalable, resilient systems and micro-services. Its strongest points are:

Multi-threaded behavior
Transparency: in regards to communication between components and systems using them
Clustered architecture: for designing a scalable, on-demand and reactive system

This means, that Akka addresses common situations in any virtualized architecture – components failing without responding, messages getting lost in transit and fluctuating network latency. The key to fully utilizing Akka is combining devices into clusters.

Cluster

As we mentioned earlier, networks can experience down-time. This may be due to the collapse of one machine, and this breaking the entire chain of events. Running applications as clusters, instead of single instances, avoid this situation.

Imagine, grouping objects with a similar purpose together as Clustering. If one of the cluster members fails, another member can come to the rescue and continue in its function. This happens in an instance – the end-user doesn’t even notice that anything happened.

Requests are evenly distributed across the cluster members, thanks to load-balancing. One device won’t be overloaded with requests, as these are shared within the cluster.

If the amount of connected devices is low, the cluster will decrease in size and use fewer resources. The cluster adapts to the needs of the network and can increase or decrease in size. Due to this balance, hardware efficiency is guaranteed.

Clusters can, in some cases, fail, but potentially do not require manual intervention. If used with tools like Kubernetes, potential outages in the cluster are automatically healed. This can be a lifesaver in critical situations.