Biblio

Network slicing qualitatively transforms network infrastructures such that they have maximum flexibility in the context of ever-changing service requirements. While the agility of cloud native network functions (CNFs) demonstrates significant promise, virtualization and softwarization severely degrade the performance of such network functions. Considerable efforts were expended to improve the performance of virtualized systems, and at this stage 10 Gbps throughput is a real target even for container/VM-based applications. Nonetheless, the current performance of CNFs with state-of-the-art enhancements does not meet the performance requirements of next-generation 6G networks that aim for terabit-class throughput. The present pace of performance enhancements in hardware indicates that straightforward optimization of existing system components has limited possibility of filling the performance gap. As it would be reasonable to expect a single silver-bullet technology to dramatically enhance the ability of CNFs, an organic integration of various data-plane technologies with a comprehensive vision is a potential approach. In this paper, we show a future vision of system architecture for terabit-class CNFs based on effective harmonization of the technologies within the wide-range of network systems consisting of commodity hardware devices. We focus not only on the performance aspect of CNFs but also other pragmatic aspects such as interoperability with the current environment (not clean slate). We also highlight the remaining missing-link technologies revealed by the goal-oriented approach.

Cloud Native, the emerging computing infrastructure has become a new trend for cloud computing, especially after the development of containerization technology such as docker and LXD, and the orchestration system for them like Kubernetes and Swarm. With the growing popularity of Cloud Native, the following problems have been raised: (i) most Cloud Native applications were designed for making full use of the cloud platform, but their file storage has not been completely optimized for adapting it. (ii) the traditional file system is designed as a utility for storing and retrieving files, usually built into the kernel of the operating systems. But when placing it to a large-scale condition, like a network storage server shared by thousands of computing instances, and stores millions of files, it will be slow and even unstable. (iii) most storage solutions use metadata for faster tracking of files, but the metadata itself will take up a lot of space, and the capacity of it is usually limited. If the file system store metadata directly into hard disk without caching, the tracking of massive small files will be a lot slower. (iv) The traditional object storage solution can't provide enough features to make itself more practical on the cloud such as caching and auto replication. This paper proposes a new storage engine based on the well-known Haystack storage engine, optimized in terms of service discovery and Automated fault tolerance, make it more suitable for Cloud Native infrastructure, deployment and applications. We use the object storage model to solve the large and high-frequency file storage needs, offering a simple and unified set of APIs for application to access. We also take advantage of Kubernetes' sophisticated and automated toolchains to make cloud storage easier to deploy, more flexible to scale, and more stable to run.

While the IT industry is embracing the cloud-native technologies, migrating from monolithic architecture to service-oriented architecture is not a trivial process. It involves a lot of dissection and abstraction. The layer of abstraction designed for simplifying the development quickly becomes the barrier of visibility and the source of misconfigurations. The complexity may give microservices a larger attack surface compared to monolithic applications. This talk presents a microservices threat modeling that uncovers the attack vectors hidden in each abstraction layer. Scenarios of security breaches in microservices platforms are discussed, followed by the countermeasures to close these attack vectors. Finally, a decision-making process for architecting secure microservices is presented.