Fig 3 - available via license: Creative Commons Attribution 4.0 International
Content may be subject to copyright.
Orchestrator overhead as shown in Pan [3]. The graph shows the processing time of a sample containerized application that is deployed directly, then again with Docker Swarm and Kubernetes orchestration.
Source publication
![Fig. 2: The CloudCAMP workflow, shown in Bhattacharjee [2], describes a...](publication/361324341/figure/fig2/AS:1167473080573954@1655358681136/The-CloudCAMP-workflow-shown-in-Bhattacharjee-2-describes-a-typical-sequence-starting_Q320.jpg)
![Fig. 3: Orchestrator overhead as shown in Pan [3]. The graph shows the...](publication/361324341/figure/fig3/AS:1167473080573955@1655358681251/Orchestrator-overhead-as-shown-in-Pan-3-The-graph-shows-the-processing-time-of-a_Q320.jpg)
Compute infrastructure hosted by a cloud provider allows an application to scale without limit. The application developer no longer needs to worry about the up-front investment in a server farm provisioned for a worst-case load scenario. However, managing cloud deployments requires a sophisticated framework that can autoscale the infrastructure and...
Context in source publication
Context 1
... A Light Detection and Ranging (LiDAR) data processing. The results in Figure 3 show processing times with container images running directly on the node and again orchestrated through Docker Swarm and Kubernetes. The red portion indicates the overhead processing that the orchestrator introduces and shows Kubernetes with the highest overhead. ...
Similar publications
On the Internet, web applications are served from a centralized location i.e., server, for higher maintainability. However, in the centralized architecture, if there is an occurrence of server failure or crash, the web applications cannot be serve to the end-users until the server goes live again. In addition, in the existing centralized architectu...
