Microsoft has introduced a new container service, (ACI), that is intended to provide a more lightweight and granular way to run containerized applications than its Azure Container Service (ACS).
ACI runs individual containers that you can configure with specific amounts of virtual CPU and memory, and that are billed by the second. Containers can be pulled from various sources – Docker Hub, the Azure Container Registry, or a private repository – and deployed from the CLI or by way of an Azure template.
Microsoft is emphasizing how ACI is complementary to ACS, rather than a replacement for it. ACI is meant for smaller, more burst-able workloads, or as a way to temporarily satisfy a surge in demand, rather than as a way to deploy complex, long-running applications with many interdependencies between containers.
One key difference between ACI and ACS: ACI supports only one orchestrator, Kubernetes, and only by way of . In other words, it’s possible but not required to use Kubernetes as an orchestrator for ACI workloads. You can also draw on for building Kubernetes apps.
ACI appears to provide a different level of infrastructure abstraction for developers than Azure Functions. Functions is for little more than code snippets, typically used for fulfilling API requests or other simple jobs. ACI launches whole containers, with Azure’s role-based access controls and billing tags associated with them.
Right now ACI is only available for Linux as a technology preview, although Microsoft plans to offer support for Microsoft Windows containers on ACI in fairly short order. Microsoft is planning to publish the ACI API as a Swagger specification, which could in theory allow other vendors to implement similar, API-compatible offerings on their own services.
The jury is out right now regarding how deeply ACI will be integrated with other Microsoft Azure offerings, such as Azure Service Fabric. Microsoft is waiting to glean feedback during the preview period before deciding on next steps.