No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Performance Evaluation of Container Runtimes
... A visualization of the local simulations guide the user to choose an appropriate function configuration to resolve the mentioned trade-off dependent on their requirements. [25,75]. . . . ...
... A corresponding project for building such compliant images is BuildKit 29 which implements the OCI image-spec and is used by client tools like Docker. For starting and running containers, runc is widely used [75]. It is a low level tool for "spawning and running containers on Linux according to the OCI specification" 30 and uses the host kernel's aforementioned features like namespaces etc. to provide secure containers. ...
... It is a low level tool for "spawning and running containers on Linux according to the OCI specification" 30 and uses the host kernel's aforementioned features like namespaces etc. to provide secure containers. runc is the reference implementation of the OCI runtime-spec [75]. It was donated by Docker in 2015 to OCI. ...
Serverless Computing is seen as a game changer in operating large-scale applications. While practitioners and researches often use this term, the concept they actually want to refer to is Function as a Service (FaaS). In this new service model, a user deploys only single functions to cloud platforms where the cloud provider deals with all operational concerns – this creates the notion of server-less computing for the user.
Nonetheless, a few configurations for the cloud function are necessary for most commercial FaaS platforms as they influence the resource assignments like CPU time and memory. Due to these options, there is still an abstracted perception of servers for the FaaS user. The resource assignment and the different strategies to scale resources for public cloud offerings and on-premise hosted open-source platforms determine the runtime characteristics of cloud functions and are in the focus of this work. Compared to cloud offerings like Platform as a Service, two out of the five cloud computing characteristics improved. These two are rapid elasticity and measured service. FaaS is the first computational cloud model to scale functions only on demand. Due to an independent scaling and a strong isolation via virtualized environments, functions can be considered independent of other cloud functions. Therefore, noisy neighbor problems do not occur. The second characteristic, measured service, targets billing. FaaS platforms measure execution time on a millisecond basis and bill users accordingly based on the function configuration. This leads to new performance and cost trade-offs.
Therefore, this thesis proposes a simulation approach to investigate this tradeoff in an early development phase. The alternative would be to deploy functions with varying configurations, analyze the execution data from several FaaS platforms and adjust the configuration. However, this alternative is time-consuming, tedious and costly. To provide a proper simulation, the development and production environment should be as similar as possible. This similarity is also known as dev-prod parity. Based on a new methodology to compare different virtualized environments, users of our simulation framework are able to execute functions on their machines and investigate the runtime characteristics for different function configurations at several cloud platforms without running their functions on the cloud platform at all. A visualization of the local simulations guide the user to choose an appropriate function configuration to resolve the mentioned trade-off dependent on their requirements.
... [18] [5] [19]. • Process Management: Kubernetes manages container lifecycles through the kubelet and container runtime, adding overhead compared to directly running applications on bare metal [20]. • Memory: Containerisation adds additional memory overhead due to container images and runtime environments [20]. ...
... • Process Management: Kubernetes manages container lifecycles through the kubelet and container runtime, adding overhead compared to directly running applications on bare metal [20]. • Memory: Containerisation adds additional memory overhead due to container images and runtime environments [20]. This study quantifies the performance impact of this overhead on 5GC control plane procedures deployed on Kubernetes compared to a bare-metal baseline. ...
This paper investigates the performance difference of critical 5G User Equipment (UE) procedures when deployed on a Kubernetes platform versus a traditional bare-metal deployment. We leverage Open5GS, an open-source implementation of the 5G Core (5GC), to evaluate the impact of containerisation on key performance metrics. The research answers (i) how the performance of critical 5G UE procedures differs when 5GC is deployed on a Kubernetes environment compared to a traditional bare-metal deployment and (ii) provides the measurable cost introduced by Kubernetes in terms of key 5G performance metrics. We evaluated throughput and latency. The paper analyses the observed performance differences against theoretical expectations arising from the Kubernetes architecture overhead and insights from related work. Our study reveals a 7% performance degradation in throughput for UE procedures running on Kubernetes compared to bare-metal when handling more than 300 initiated UE devices.
... B. Best Practices 1) Use Application Load Balancer for advanced routing and microservices support: Application Load Balancer operates at the application layer (Layer 7) of the OSI model, allowing for more sophisticated routing rules based on content of the request. Research by Jindal et al. [10] showed that using Application Load Balancer for microservices-based Java applications resulted in a 30% improvement in request routing efficiency and a 20% reduction in overall latency compared to traditional load balancers. 2) Implement custom CloudWatch metrics for application-specific auto scaling triggers: While default metrics like CPU utilization are useful, custom metrics allow for more precise scaling based on application-specific indicators. ...
... Resource Utilization Efficiency Gain 35% Table 2: Impact of Advanced Load Balancing and Auto Scaling Strategies on Java Application Efficiency [9,10] VI. DATA STORAGE AND MANAGEMENT Choosing the proper data storage solution is essential for scalable Java architectures, considering factors like data structure, access patterns, and consistency requirements. ...
This article explores strategies and best practices for designing scalable Java architectures on Amazon Web Services (AWS). It addresses the growing need for robust, scalable systems due to increasing global internet traffic and the prevalence of AWS in cloud-native applications. The paper examines key architectural approaches, including microservices, serverless computing, and containerization, alongside essential AWS services for load balancing, auto-scaling, data management, and security. It presents research-backed insights on the benefits of these strategies, such as improved performance, cost efficiency, and resource utilization. The article also discusses best practices for implementing these architectures, emphasizing the importance of proper monitoring, optimization, and security measures in creating resilient and high-performing Java applications on AWS.
... Research related to the performance of low-level container runtimes has basically been done. Some of the parameters measured include CPU, memory, and the performance of the I/O block [8]. We extend the scope to include a comparison of VMs with containers [3], [9], incorporating multiple quantifiable parameters. ...
... Kubernetes facilitates the deployment of multiple pods, where each pod supports multiple containers that can utilize associated service [7]. Selecting the appropriate low-level container runtimes becomes crucial in maximizing the effectiveness of a Kubernetes cluster, especially considering resource management in a multi-tenant environment [8]. Additionally, the scalability advantage achieved through auto-scaling demands careful attention, as efficient resource usage significantly impacts cluster performance and associated costs. ...
The advent of container technology has emerged as a pivotal solution for application developers, addressing concerns regarding the seamless execution of developed applications during the deployment process. Various low-level container runtimes, including runC, Kata Container, and gVisor, present themselves as viable options for implementation. The judicious selection of an appropriate low-level container runtime significantly contributes to enhancing the efficiency of Kubernetes cluster utilization. To ascertain the optimal choice, comprehensive testing was conducted, encompassing both performance and security evaluations of the low-level container runtimes. This empirical analysis aids developers in making informed decisions regarding the selection of low-level container runtimes for integration into a Kubernetes cluster. The performance assessments span five key parameters: CPU performance, memory utilization, disk I/O efficiency, network capabilities, and the overall performance when executing an nginx web server. Three distinct tools—sysbench, iperf3, and Apache Benchmark—were employed to conduct these performance tests. The findings of the tests reveal that runC exhibits superior performance across all five parameters evaluated. However, a nuanced consideration of security aspects is imperative. Both Kata Container and gVisor demonstrate commendable host isolation, presenting limited vulnerability to exploitation. In contrast, runC exposes potential vulnerabilities, allowing for exploits against the host (worker node), such as unauthorized directory creation and system reboots. This comprehensive analysis contributes valuable insights for developers, facilitating an informed decision-making process when selecting low-level container runtimes within a Kubernetes environment.
... Ferreira & Sinnott (2019) conducted a performance evaluation of containers running on managed Kubernetes services, providing valuable insights into the trade-offs of using such services. Espe et al. (2020) also focused on the performance of container runtimes, contributing to a deeper understanding of the factors affecting container execution efficiency. ...
... Kubernetes supports several container runtimes, with Docker being the most widely used. Other supported runtimes include containerd and CRI-O, which are compatible with the Kubernetes Container Runtime Interface (CRI) (Espe et al., 2020). ...
Containerization has revolutionized software development and deployment by
accelerating the implementation and adoption of Microservices Architecture through
different technologies such as Docker and Kubernetes. In the core of the practice stands the container, a lightweight, and portable unit that is used to package an application together with all its configurations and libraries, offering consistency and flexibility in a wide set of systems. Containers are the perfect tools for implementing a microservice architecture by providing a framework where services can be isolated, each with their own functionality but at the same time properly coordinated. Docker is the most prominent and straightforward tool for building and running containers, allowing building and testing services without issues across many environments. Kubernetes on the other hand is another complementary technology which orchestrates the containers, abstracting their tedious management and turning them into a scalable cluster. The implementation of these technologies should be carefully accompanied with the adaptation of some practices concentrated mostly on security and optimization. In this
study, I have demonstrated an effective implementation of Kubernetes and microservices by deploying Apache Airflow as a platform for provisioning data workflows. The synergy of Kubernetes with different tools such as Terraform (Infrastructure as Code), Helm Charts (Kubernetes Templates) and ArgoCD (GitOps), in addition to Azure Kubernetes Service (Platform-as-a-Service) resulted in a fully functional Apache Airflow deployment.
... A tool called TouchStone was developed and used by Espe et al. to evaluate the performance of Containerd and CRI-O on runc and gVisor. 15 The tool is pluggable into any Kubernetes-compatible container runtime and can evaluate the performance of running containers, the performance of container runtime operations, scalability, and other aspects of the system. The overall experimental results showed that the CRI-O/runc combination achieved the highest performance in almost all cases, whereas Containerd/runc turned out to excel at I/O-heavy workloads. ...
... In general, the high-level container runtime manages the container images, the network during the container creation process and creates the filesystem bundle from an OCI image. 15,19 According to OCI, high-level container runtimes can download/upload images from/to a remote repository or build an image from a configuration file. Low-level container runtimes run a container according to the specifications of the filesystem bundle produced by the high-level container runtime. ...
Containers emerge as the prevalent virtualization technology in cloud computing. Containers are more light‐weight and agile compared to traditional virtual machines (VMs), since they provide virtualization at the operating system level. There are specific factors driving the container adoption in cloud, however, the main disadvantage of container‐based virtualization technologies is poor isolation. To address isolation and security‐related issues, new container runtimes appeared. In this study we present and evaluate the most common security‐oriented runtimes, Kata, gVisor and Nabla, running with Docker, Containerd, and CRI‐O. We deploy containers for all the aforementioned container solutions, as well as the default Kubernetes runtime runc, on a Kubernetes cluster and additionally on a Docker node. Moreover, in a similar way to containers, we deploy and evaluate unikernels and security‐oriented lightweight Linux‐based VMs running on Kubernetes cluster. To evaluate container runtimes, we take under consideration Firecracker microVM too. To automate the deployment of high isolated containers and VMs on Kubernetes clusters, we have developed our own tool. Finally, we recognize the increasing interest on Function‐as‐a‐Service and other serverless architectures. In the same direction with these emerging cloud computing services, we have extended the Kubeless serverless framework to support security‐oriented container runtimes.
... Containers and unikernels are prominent technologies that provide isolation and streamline deployment on edge devices. Containers like Docker and Podman offer a lightweight alternative to traditional virtual machines, enabling efficient resource sharing and rapid deployment of complex applications [3]. Unikernels, on the other hand, are specialized, single-application kernels that compile only the necessary components required by the application, resulting in minimal overhead and fast boot times. ...
Edge computing is emerging as a key enabler of low-latency, high-efficiency processing for the Internet of Things (IoT) and other real-time applications. To support these demands, containerization has gained traction in edge computing due to its lightweight virtualization and efficient resource management. However, there is currently no established framework to leverage both containers and unikernels on edge devices for optimized IoT deployments. This paper proposes a hybrid edge system design that leverages container and unikernel technologies to optimize resource utilization based on application complexity. Containers are employed for resource-intensive applications, e.g., computer vision, providing faster processing, flexibility, and ease of deployment. In contrast, unikernels are used for lightweight applications, offering enhanced resource performance with minimal overhead. Our system design also incorporates container orchestration to efficiently manage multiple instances across the edge efficiently, ensuring scalability and reliability. We demonstrate our hybrid approach's performance and efficiency advantages through real-world computer vision and data science applications on ARM-powered edge device. Our results demonstrate that this hybrid approach improves resource utilization and reduces latency compared to traditional virtualized solutions. This work provides insights into optimizing edge infrastructures, enabling more efficient and specialized deployment strategies for diverse application workloads.
... Exact overheads vary between different container runtimes like containerd, CRI-O, or runc. In practice, start-up overheads below 1 s are measured [45], which we can also confirm with our own Docker container images built by docker-ros. Note that this overhead scales with the number of containers that are launched simultaneously. ...
In an increasingly automated world - from warehouse robots to self-driving cars - streamlining the development and deployment process and operations of robotic applications becomes ever more important. Automated DevOps processes and microservice architectures have already proven successful in other domains such as large-scale customer-oriented web services (e.g., Netflix). We recommend to employ similar microservice architectures for the deployment of small-to large-scale robotic applications in order to accelerate development cycles, loosen functional dependence, and improve resiliency and elasticity. In order to facilitate involved DevOps processes, we present and release a tooling suite for automating the development of microservices for robotic applications based on the Robot Operating System (ROS). Our tooling suite covers the automated minimal containerization of ROS applications, a collection of useful machine learning-enabled base container images, as well as a CLI tool for simplified interaction with container images during the development phase. Within the scope of this paper, we embed our tooling suite into the overall context of streamlined robotics deployment and compare it to alternative solutions. We release our tools as open-source software at github.com/ika-rwth-aachen/dorotos.
... It is based on CRI gRPC, a cross-language library which uses Protocol Buffer to make remote procedure calls. It is also built around an older version of the Docker architecture which uses graph drivers [19]. ...
The advent of cloud computing, with its Pay-As-You-Go model, has significantly simplified IT maintenance and revolutionized the industry. In the era of Microservices, containerized deployment and Kubernetes orchestration have permeated almost every working domain, drastically reducing the time to market for software releases. Kubernetes utilizes container runtimes to manage Containers, with the Container Runtime Interface (CRI) serving as a communication medium with low-level container runtimes such as runc and kata container. With the deprecation of Dockershim, developers are left to choose between CRI-O and Containerd, two CRI implementations. This study configures a Kubernetes cluster with both Containerd and CRI-O separately and analyzes performance parameters such as throughput, response time, CPU, memory, and network utilization. Additionally, we examine the impact of using runc and kata container runtimes together within the cluster. The study, conducted using a performance script created by JMeter, reveals that different container runtimes cater to distinct business use-cases and can complement each other when used together in a cluster environment. High compute applications are best run using runc, while high-security requirements are fulfilled by kata. The study provides a comprehensive performance comparison between Containerd and CRI-O, shedding light on the depth and versatility of container runtimes.
... In a multi-tenant system like the cloud, co-locating containers on the same host causes major performance issues. When performance requirements are stringent, choosing a container runtime becomes crucial Espe et al. (2020). On a node, container runtime software runs containers and manages container images. ...
... For instance, many studies have conducted a performance evaluation of containerized-based cloud systems. As in earlier research [16], [17], several benchmarking tools were utilized to access the performance overheads of various system resources, such as disc I/O, CPU, RAM, and network. Therefore, a specific approach to evaluating cloud services should have distinguished the various processes in detail. ...
... Kumar et al. [34] compare runc, the default Docker runtime, with Kata, a runtime with increased isolation and security mechanisms. Others compare different combinations of container managers and runtimes [35], [36]. All works find a clear trade-off between performance and increased security. ...
A core selling point of application containers is their fast start times compared to other virtualization approaches like virtual machines. Predictable and fast container start times are crucial for improving and guaranteeing the performance of containerized cloud, serverless, and edge applications. While previous work has investigated container starts, there remains a lack of understanding of how start times may vary across container configurations. We address this shortcoming by presenting and analyzing a dataset of approximately 200,000 open-source Docker Hub images featuring different image configurations (e.g., image size and exposed ports). Leveraging this dataset, we investigate the start times of containers in two environments and identify the most influential features. Our experiments show that container start times can vary between hundreds of milliseconds and tens of seconds in the same environment. Moreover, we conclude that no single dominant configuration feature determines a container's start time, and hardware and software parameters must be considered together for an accurate assessment.
... Researchers also focused on performance evaluation of container runtimes. Espe et al. [52] evaluated two container runtimes: containered and CRI-O. They developed Touchstone to evaluate these runtimes in terms of CPU usage, memory latency and scalability. ...
Container technology is becoming increasingly popular as an alternative to traditional virtual machines because it provides a faster, lighter, and more portable runtime environment for the applications. A container bundles the application and its binary code, libraries, and configuration files together while sharing the host operating system image. Accordingly, containers efficiently share resources and operate small micro-services, software programs, and even more extensive applications with less overhead than virtual machines. There are many container technologies available with Docker being the most popular and many technologies support multiple architectures, including the ARM architecture. Due to its energy efficiency and high-performance, which are crucial parameters in containerization, ARM architecture is becoming prevalent in container technologies. In this paper, we explore various container technologies that support ARM architecture and investigate the pros and cons of each technology. Moreover, we provide a comparative analysis of both container orchestrators and container runtimes that are most prominent competitors of Docker. We also consider security of container technologies with particular focus on the image scanning tools that supports ARM architecture. Our survey reveals that ARM technology is gaining popularity in containerization and almost all recent technologies support ARM architecture.
... Both Espe et al. [39] and our own previously-mentioned evaluation criteria suggest the usage of CRI-O. In combination with crun, 21 https://github.com/opencontainers/runtime-spec/blob/v1.0.2/spec.md ...
... https://orcid.org/0000-0002-2543-2710 c https://orcid.org/0000-0002-1995-7166 d https://orcid.org/0000-0002-3210-5048 infrastructure providers. For instance, approaches such as co-locating suitable serverless functions in the form of establishing a fusion of functions (Elgamal et al., 2018), identifying appropriate cloud resources for computations (Espe. et al., 2020), monitoring the behavior of underneath infrastructures (Chadha et al., 2021), and so forth, have been practiced in the past. ...
In the recent past, characterizing workloads has been attempted to gain a foothold in the emerging serverless cloud market, especially in the large production cloud clusters of Google, AWS, and so forth. While analyzing and characterizing real workloads from a large production cloud cluster benefits cloud providers, researchers, and daily users, analyzing the workload traces of these clusters has been an arduous task due to the heterogeneous nature of data. This article proposes a scalable infrastructure based on Google's dataproc for analyzing the workload traces of cloud environments. We evaluated the functioning of the proposed infrastructure using the workload traces of Google cloud cluster-usage-traces-v3. We perform the workload characterization on this dataset, focusing on the heterogeneity of the workload, the variations in job durations, aspects of resources consumption, and the overall availability of resources provided by the cluster. The findings reported in the paper will be beneficial for cloud infrastructure providers and users while managing the cloud computing resources, especially serverless platforms.
... https://orcid.org/0000-0002-2543-2710 c https://orcid.org/0000-0002-1995-7166 d https://orcid.org/0000-0002-3210-5048 infrastructure providers. For instance, approaches such as co-locating suitable serverless functions in the form of establishing a fusion of functions (Elgamal et al., 2018), identifying appropriate cloud resources for computations (Espe. et al., 2020), monitoring the behavior of underneath infrastructures (Chadha et al., 2021), and so forth, have been practiced in the past. ...
In the recent past, characterizing workloads has been attempted to gain a foothold in the emerging serverless cloud market, especially in the large production cloud clusters of Google, AWS, and so forth. While analyzing and characterizing real workloads from a large production cloud cluster benefits cloud providers, researchers, and daily users, analyzing the workload traces of these clusters has been an arduous task due to the heterogeneous nature of data. This article proposes a scalable infrastructure based on Google's dataproc for analyzing the workload traces of cloud environments. We evaluated the functioning of the proposed infrastructure using the workload traces of Google cloud cluster-usage-traces-v3. We perform the workload characterization on this dataset, focusing on the heterogeneity of the workload, the variations in job durations, aspects of resources consumption, and the overall availability of resources provided by the cluster. The findings reported in the paper will be beneficial for cloud infrastructure providers and users while managing the cloud computing resources, especially serverless platforms.
... The examples above highlight some factors that can affect the performance and the FCs. However, they are many other factors such as cold starts, I/O and network conditions, type of container runtimes, and co-location with other functions affecting the performance and FCs which the users are not aware of [12,30]. Additionally, the dependencies between the functions within a serverless application can also affect the FCs. ...
Serverless computing is a cloud computing paradigm that allows developers to focus exclusively on business logic as cloud service providers manage resource management tasks. Serverless applications follow this model, where the application is decomposed into a set of fine-grained Function-as-a-Service (FaaS) functions. However, the obscurities of the underlying system infrastructure and dependencies between FaaS functions within the application pose a challenge for estimating the performance of FaaS functions. To characterize the performance of a FaaS function that is relevant for the user, we define Function Capacity (FC) as the maximal number of concurrent invocations the function can serve in a time without violating the Service-Level Objective (SLO). The paper addresses the challenge of quantifying the FC individually for each FaaS function within a serverless application. This challenge is addressed by sandboxing a FaaS function and building its performance model. To this end, we develop FnCapacitor - an end-to-end automated Function Capacity estimation tool. We demonstrate the functioning of our tool on Google Cloud Functions (GCF) and AWS Lambda. FnCapacitor estimates the FCs on different deployment configurations (allocated memory & maximum function instances) by conducting time-framed load tests and building various models using statistical: linear, ridge, and polynomial regression, and Deep Neural Network (DNN) methods on the acquired performance data. Our evaluation of different FaaS functions shows relatively accurate predictions, with an accuracy greater than 75% using DNN for both cloud providers.
... Espe et al. evaluated the performance and scalability of containerd and CRI-O runtimes on RunC and gVisor. The evaluation results highlighted CRIO/RunC as the best option almost for any use-case, whereas Containerd/RunC turned out to excel at I/O-heavy workloads [16]. Ethan G et al. conducted a comparative analysis of the runtime performance of RunC and gVisor. ...
Containers are resource-efficient and most IT industries are adopting container-based infrastructure. However, the security and isolation of the container is rather weak. In this work, we aim to conduct an in-depth quantitative analysis of the performance characteristics of containerization technologies that strengthen container isolation and security, and discuss the applicable scenarios of various containerization technologies. We evaluate multiple cloud resource management dimensions of RunC, gVisor, and Kata Containers runtimes, including performance, system call, startup time, density, and isolation. Experimental results show that RunC and Kata Containers have less performance overhead, while gVisor suffers significant performance degradation in I/O and system call, although its isolation is the best. Our work deepens the understanding of the container performance characteristics and may help cloud computing practitioners in making proper decisions on platform selection, system maintenance and/or design.
... Especially, the overhead of Docker is negligible. The analysis in [3] has been deepened in [4], where Docker is compared with other container engines. In [5], Docker-based monolith and microservice approaches to design an NFV-based system are compared and a methodology is proposed to estimate the number of instances required to maximize performance. ...
We introduce an open-source, scalable, and distributed architecture, called Megalos, that supports the implementation of virtual network scenarios consisting of virtual devices (VDs) where each VD may have several Layer 2 interfaces assigned to virtual LANs. We rely on Docker containers to realize vendor-independent VDs and we leverage Kubernetes for the management of the nodes of a distributed cluster. Our architecture does not require platform-specific configurations and supports a seamless interconnection between the virtual environment and the physical one. Also, it guarantees the segregation of each virtual LAN traffic from the traffic of other LANs, from the cluster traffic, and from Internet traffic. Further, a packet is only sent to the cluster node containing the recipient VD. We produce several example applications where we emulate large network scenarios, with thousands of VDs and LANs. Finally, we experimentally show the scalability potential of Megalos by measuring the overhead of the distributed environment and of its signaling protocols.
بررسی آسیب پذیری های امنیتی
Containerization significantly boosts cloud computing efficiency by reducing resource consumption, enhancing scalability, and simplifying orchestration. Yet, these same features introduce notable security vulnerabilities due to the shared Linux kernel and reduced isolation compared to traditional virtual machines (VMs). This architecture, while resource-efficient, increases susceptibility to software vulnerabilities, exposing containers to potential breaches; a single kernel vulnerability could compromise all containers on the same host. Existing academic research on container security is often theoretical and lacks empirical data on the nature of attacks, exploits, and vulnerabilities. Studies that do look at vulnerabilities often focus on specific types. This lack of detailed data and breadth hampers the development of effective mitigation strategies and restricts insights into the inherent weaknesses of containers. To address these gaps, our study introduces a novel taxonomy integrating academic knowledge with industry insights and real-world vulnerabilities, creating a comprehensive and actionable framework for container security. We analyzed over 200 container-related vulnerabilities, categorizing them into 47 exploit types across 11 distinct attack vectors. This taxonomy not only advances theoretical understanding but also facilitates the identification of vulnerabilities and the implementation of effective mitigation strategies in containerized environments. Our approach enhances the resilience of these environments by mapping vulnerabilities to their corresponding exploits and mitigation strategies, especially in complex, multi-tenant cloud settings. By providing actionable insights, our taxonomy helps practitioners enhance container security. Our findings have identified critical areas for further investigation, thereby laying a comprehensive foundation for future research and improving container security in cloud environments.
In the evolving tech landscape, various container technologies coexist and offer compelling advantages in quickly deploying applications and efficiently utilizing resources on edge devices. Despite the potential benefits of containerization in general, limited research has explored how various container technologies perform in specific domains. In response, this paper provides an extensive evaluation of container technologies (e.g., RunC, LXC, Containerd, Docker, Podman, and Singularity) in the context of OpenCV-based computer vision applications on ARM-based edge devices. Experiments verify that the performance of containerized computer vision applications is comparable to that of non-containerized ones. While the performance is roughly equivalent across all container runtimes/engines, Docker consistently demonstrates superior efficiency for computer vision applications on ARM-based edge devices. These insights contribute to bridge the existing gap to the integration of containers in IoT and ARM-based edge computing scenarios.
Machine learning software is fundamentally different from most other software in one important respect: it is tightly linked with data. The behavior of machine learning software is dictated as much by the data we train our models on as it is by our design choices because the information in the data is compiled into the software through the models. In a sense, models program the software automatically: developers do not completely encode its behavior in the code. Combining this idea with modern software development schools such as Agile and DevOps into MLOps has shaped how we develop and run software that incorporates probabilistic models in real‐world applications. In this article, we provide a brief overview of commonly accepted best practices for developing such software, focusing on the unique challenges that require a combination of statistical and software engineering expertise to tackle.
Internet-of-Things (IoT) devices continuously gather data and send the data to the cloud for further processing. However, with the recent trend of increasing number of IoT devices, billions of devices are anticipated to send data to the cloud, eventually impacting performance and cost. To solve this problem, one way is to process data locally inside edge nodes. The edge nodes are closer to the IoT devices and improve the overall performance of the system by distributing cloud tasks in edge devices. Edge devices are generally resource-constrained with limited RAM, CPU, and storage. Container technologies are ideal in edge nodes due to their isolation and being lightweight. A benchmarking scheme for containers on edge devices can help compare container technologies, hardware devices and architectures, and software. However, there is not sufficient research in this direction. So, in this work, we take a step towards developing this benchmark. We explore and evaluate the performance, efficiency, and suitability of different container technologies, including Docker, Podman, and Singularity, in the context of edge computing on ARM-based devices. Our experiments include evaluating computer vision applications that employ Haar Cascades, HOG, CNN with YOLO algorithm, and data science workloads commonly encountered in edge computing scenarios. We devised sets of performance metrics to assess container technology, including waiting time, receiving time, processing time, resource utilization, and throughput. Besides, we investigate how different container technologies optimize resource utilization and compare their efficiency on ARM-based edge devices. Our benchmarking analysis yielded valuable insights into the strengths and limitations of each container technology. Our results reveal that Docker, Podman, and Singularity containers exhibit diverse resource consumption patterns and network efficiency. Docker container has better CPU and RAM utilization for most applications. Docker also boasts the lowest waiting time of approximately 0.9 seconds, comparable to native performance. In terms of processing time, Docker excels in Car detection (0.12 seconds), while Singularity and Podman outperform Docker in Object detection. Notably, native systems exhibit a remarkable improvement over containers (average of 1.2 seconds) in Object detection (0.98 seconds), highlighting the challenges of resource-intensive deep neural network algorithms on edge devices. Based on our findings, we offer practical advice for picking the best container technology for specific use cases in ARM-based edge computing. We also offer a set of benchmarking approaches and metrics that can be used to drive future research on container technologies on ARM platforms.
The scope of the Industrial Internet of Things (IIoT) has stretched beyond manufacturing to include energy, healthcare, transportation and all that tomorrow’s smart cities will entail. The realm of IIoT includes smart sensors, actuators, programmable logic controllers, distributed control systems (DCS), embedded devices, supervisory control and data acquisition systems - all produced by manufacturers for different purposes and with different data structures and formats; designed according to different standards, and made to follow different protocols. In this sea of incompatibility, how can we flexibly acquire these heterogeneous data, and how can we uniformly structure them to suit thousand of different applications? In this article, we survey the four pillars of information science that enable collaborative data access in an IIoT - standardization, data acquisition, data fusion, and scalable architecture - to provide an up-to-date audit of current research in the field. Here, standardization in IIoT relies on standards and technologies to make things communicative; data acquisition attempts to transparently collect data through plug-and-play architectures, reconfigurable schemes, or hardware expansion; data fusion refers to the techniques and strategies for overcoming heterogeneity in data formats and sources; and scalable architecture provides basic techniques to support heterogeneous requirements. The paper also concludes with an overview of the frontier researches and emerging technologies for supporting or challenging data access from the aspects of 5G, machine learning, blockchain, and semantic web.
Nowadays, every company is trying to become a tech company as we have seen that software is consuming the entire world. So, how the company approaches software development and serves their customers show how efficient their employees are or how agile their organization is. Therefore, it is of utmost importance for the companies to make correct decision about the architectural choices early in the software development life cycle. It has been observed that containers are taking place of virtual machines in the IT industry because they do not require to incorporate guest operating system in each instance like virtual machines, and they simply support the property and resources of host OS. This paper presents a survey on containers, and its architecture and how containers are better than virtual machines for software development.KeywordsCloud computingContainersVirtual machinesMicroservice architectureMonolithic architectureContainer orchestration
Virtualization technology plays a vital role in cloud computing. In particular, benefits of virtualization are widely employed in high performance computing (HPC) applications. Recently, virtual machines (VMs) and Docker containers known as two virtualization platforms need to be explored for developing applications efficiently. We target a model for deploying distributed applications on Docker containers, among using well-known benchmarks to evaluate performance between VMs and containers. Based on their architecture, we propose benchmark scenarios to analyze the computing performance and the ability of data access on HPC system. Remarkably, Docker container has more advantages than virtual machine in terms of data intensive application and computing ability, especially the overhead of Docker is trivial. However, Docker architecture has some drawbacks in resource management. Our experiment and evaluation show how to deploy efficiently high performance computing applications on Docker containers and VMs.
Virtualization of operating systems provides a common way to run different services in the cloud. Recently, the lightweight virtualization technologies claim to offer superior performance. In this paper, we present a detailed performance comparison of traditional hypervisor based virtualization and new lightweight solutions. In our measurements, we use several benchmarks tools in order to understand the strengths, weaknesses, and anomalies introduced by these different platforms in terms of processing, storage, memory and network. Our results show that containers achieve generally better performance when compared with traditional virtual machines and other recent solutions. Albeit containers offer clearly more dense deployment of virtual machines, the performance difference with other technologies is in many cases relatively small.
The use of virtualization technologies in high performance computing (HPC) environments has traditionally been avoided due to their inherent performance overhead. However, with the rise of container-based virtualization implementations, such as Linux VServer, OpenVZ and Linux Containers (LXC), it is possible to obtain a very low overhead leading to near-native performance. In this work, we conducted a number of experiments in order to perform an in-depth performance evaluation of container-based virtualization for HPC. We also evaluated the trade-off between performance and isolation in container-based virtualization systems and compared them with Xen, which is a representative of the traditional hypervisor-based virtualization systems used today.
Mobile Edge Computing (MEC) is an emerging network paradigm that provides cloud and IT services at the point of access of the network. Such proximity to the end user translates into ultra-low latency and high bandwidth, while, at the same time, it alleviates traffic congestion in the network core. Due to the need to run servers on edge nodes (e.g., an LTE-A macro eNodeB), a key element of MEC architectures is to ensure server portability and low overhead. A possible tool that can be used for this purpose is Docker, a framework that allows easy, fast deployment of Linux containers. This paper addresses the suitability of Docker in MEC scenarios by quantifying the CPU consumed by Docker when running two different containerized services: multiplayer gaming and video streaming. Our tests, run with varying numbers of clients and servers, yield different results for the two case studies: for the gaming service, the overhead logged by Docker increases only with the number of servers; conversely, for the video streaming case, the overhead is not affected by the number of either clients or servers.
Today, a new technology is going to change the way platforms for the internet of services are designed and managed. This technology is called container (e.g. Docker and LXC). The internet of service industry is adopting the container technology both for internal usage and as commercial offering. The use of container as base technology for largescale systems opens many challenges in the area of resource management at run-time, for example: autoscaling, optimal deployment and monitoring. Speci�cally, monitoring of container based systems is at the ground of any resource management solution, and it is the focus of this work. This paper explores the tools available to measure the performance of Docker from the perspective of the host operating system and of the virtualization environment, and it provides a characterization of the CPU and disk I/O overhead introduced by containers.
Cloud computing allows to utilize servers in efficient and scalable ways through exploitation of virtualization technology. In the Infrastructure-as-a-Server (IaaS) Cloud model, many virtualized servers (instances) can be created on a single physical machine. There are many such Cloud providers that are now in widespread use offering such capabilities. However, Cloud computing has overheads and can constrain the scalability and flexibility, especially when diverse users with different needs wish to use the Cloud resources. To accommodate such communities, an alternative to Cloud computing and virtualization of whole servers that is gaining widespread adoption is micro-hosting services and container-based solutions. Container-based technologies such as Docker allow hosting of micro-services on Cloud infrastructures. These enable bundling of applications and data in a manner that allows their easy deployment and subsequent utilization. Docker is just one of the many such solutions that have been put forward. The purpose of this paper is to compare and contrast a range of existing container-based technologies for the Cloud and evaluate their pros and cons and overall performances. The OpenStack-based Australia-wide National eResearch Collaboration Tools and Resources (NeCTAR) Research Cloud (www.nectar.org.au) was used for this purpose. We describe the design of the experiments and benchmarks that were chosen and relate these to literature review findings.
Analysis of docker security
- T Bui
Bui, T. (2015). Analysis of docker security. arXiv preprint
arXiv:1501.02967.
Introducing container runtime interface in kubernetes
- Y.-J Hong
Hong, Y.-J. (2019). Introducing container runtime interface
in kubernetes.
https://kubernetes.io/blog/
How-Container-Runtime-Matters-in-Kubernetes_-OSS-Kunal-Kushwaha
- K Kushwaha
Kushwaha, K. (2017). How container runtimes matter in
kubernetes? https://events.linuxfoundation.
org/wp-content/uploads/2017/11/How-Container-Runtime-Matters-in-Kubernetes_-OSS-Kunal-Kushwaha.pdf. Accessed on 6.06.2019.
Red hat openshift container platform 4 now defaults to cri-o as underlying container engine
- S Mccarty
McCarty, S. Red hat openshift container platform 4
now defaults to cri-o as underlying container engine.
https://www.redhat.com/en/blog/redhat-openshift-container-platform-4-nowdefaults-cri-o-underlying-containerengine. Accessed on 22.07.2019 16:14.
Demystifying the open container initiative (oci) specifications
- S Walli
Walli, S. Demystifying the open container initiative
(oci) specifications.
https://blog.docker.