Shared storage or local storage based macOS Cloud for iOS CI

It’s obvious that mobile development is very mainstream now and as a result, the size and number of mobile development projects continues to grow. However, as projects and teams scale, and the number of dependencies increase, ensuring a consistent and stable build for all developers while ensuring code and test quality is a much bigger challenge.



Mobile CI Infrastructure Requirements



For a mobile CI system to scale, it needs to enable management of project dependencies, build and test environment dependencies and faster build times. While strategies for scaling build systems vary widely across use cases, most implementations focus on ephemeral approaches to managing the mobile job environment. This means the use of self-contained, immutable build environments to ensure proper versioning and verified stability. For many of these environments, typically virtual machines or docker containers, parity of performance becomes the chief concern. Management of these VMs and containers can prove challenging, however, and requires scalable architecture and a reduction in the number of system dependencies.



Container and Container registry for iOS CI Cloud?



In the container world, there are ample resources for building, scheduling, and deploying stateless applications and batch processes. As you know, containers cannot be used for the typical macOS CI use case, but there are examples to take from this highly scalable technology. These include projects like Mesos, Kubernetes, and others, which enable the ease of container management across very large environments on-premise or in public clouds like AWS or GCP. An additional hallmark of the container technology space is the use of registries to host base and additional container layers to add continued scalability using incremental approaches to infrastructure and application development.

When scaling out infrastructure, registries can be used to download a container as an artifact, enabling workloads to be executed using local system resources, no matter the resource need. Further, the layering and artifacting of images allow this scale to expand across massive pools of resources, executing computations and compiles in more distributed fashion when required. Typically, containers downloaded by servers for running distributed compute, applications, or compile can perform moderately to extremely well using local CPU, memory, and especially storage. By using local storage to perform I/O operations within the container, directly on disk, the performance of these containers remains lightweight and easily scalable. Anka registry architecture is purpose-built around these concepts, and particularly well-suited for mobile CI systems. In contrast to this topology, the virtual machine world holds many different challenges.



Storage setup for iOS CI Cloud



Virtual machines often used to manage large stateful applications, can be a bit more daunting to manage. Contrasted with containers, their on-disk size is typically far greater, often exceeding 20Gb or more for a simple base operating system layer. In the macOS world, these images are often more difficult to manage because of limitations or requirements of the Apple ecosystem. Add to those additional dependencies, security tools, or large projects required to be included, these images can exceed 30Gb and can even grow beyond this when leaving room for a job or test execution, results exports, or caches to make the build faster. With a higher storage footprint, VMs become difficult to update and distribute at scale and typically have significantly higher I/O for compile jobs and other tasks. In traditional virtual machine architectures, stateful applications running inside of VMs are managed across a shared storage array, connected to the compute pool running virtual machines through various high-speed network connections. These storage arrays can be comprised of any number of technologies, including traditional spinning disks, flash storage types, or a combination of both with the in-memory cache as well.

For the majority of use cases (like providing high availability and virtual machine migration when underlying hardware fails) this networked storage array can perform adequately to workloads exhibited. However, in build and CI environments, the I/O patterns of project compile and some test tasks can constrain these platforms and harm build performance. Because CI system scalability is achieved by a large number of ephemeral instances to execute build and test environments, the compile workloads in addition to VM distribution can add considerable load to the shared storage layer regardless of technology. This is because communication with the filesystem takes place both on the filesystem and over the network, adding latency and slowing throughput compared to local disk.



Anka Registry allows for the download and distribution of VM images across a large number of underlying hosts. These hosts can be easily updated and can launch additional instances from local caches without requiring that the image is downloaded again. This architecture removes dependencies of network and storage during compiles run by virtual machines hosted on shared arrays and allows mobile build systems to more easily scale and perform faster. If you want the simplicity and the performance of running your iOS CI environment atop local SSDs, Anka is the platform for you.