Multiple container orchestration technologies for ease of consumption
DuploCloud abstracts the complexity of container orchestration technologies, allowing you to focus on the deployment, updating, and debugging of your containerized application.
Among the technologies supported are:
Azure Kubernetes Service [AKS]: The DuploCloud platform uses AKS, providing you with a user-friendly interface that conceals the complexities of Kubernetes (K8s). Using the UI, you can add K8S configurations around Pods, Containers, Secrets, and so on.
Built-in (DuploCloud): DuploCloud platform's built-in container management has the same interface as the docker run
command, except that it can be scaled to hundreds of containers across many hosts, providing capabilities such as associated load balancers, DNS, and more.
Use the feature matrix below to compare the features of the orchestration technologies that DuploCloud supports. Whatever option you choose, DuploCloud helps you implement it through the Portal or the Terraform API.
One dot indicates a low rating, two dots indicate a medium rating, and three dots indicate a high rating. For example, Kubernetes has a low ease-of-use rating, but a high rating for stateful application support.
Use the definitions below to understand how each feature in the matrix above is rated in relation to each of the three listed technologies (Kubernetes, Built-In).
Ease of Use:
Kubernetes is extensible and customizable, but not without a cost in ease of use. The DuploCloud platform reduces the complexities of Kubernetes, making it comparable with other container orchestration technologies in ease of adoption.
DuploCloud's Built-in orchestration mirrors docker run
. You can SSH into a virtual machine (VM) and run docker
commands to debug and diagnose. If you have an application with a few stateless microservices; or configurations that use environment variables or Azure VM extensions, Azure Blob, or Azure Key Vault, consider using DuploCloud's Built-in container orchestration.
Features and Ecosystem Tools: Kubernetes is rich in many additional built-in features and ecosystem tools, most notably Secrets Management and ConfigMaps. Built-In and AKS rely on native Azure services. While Kubernetes features have an equivalent in Azure, third parties tend to publish their software as Kubernetes packages (Helm Charts). Some examples are Influx DB, Time Series DB, Prefect, etc.
Suitability for Stateful apps: Stateful applications should be avoided in Azure. Instead, cloud-managed storage solutions should be leveraged for the best availability and SLA compliance. In scenarios where this is undesirable due to cost, Kubernetes offers the best solution. Kubernetes uses StatefulSets and Volumes to implicitly manage Azure Storage volumes. With Built-in and AKS, you must use a shared drive, which may not have feature parity with Kubernetes volume management.
Stability and Maintenance: Even though Kubernetes is highly stable, it is an open-source product. The native customizability and extensibility of Kubernetes can lead to points of failure when a mandatory cluster upgrade is needed, for example. This complexity often leads to support costs from third-party vendors. Maintenance can be especially costly with AKS, as versions are deprecated frequently and you are required to upgrade the control plane and data nodes. While DuploCloud automates this upgrade process, it still requires careful planning and execution.
Azure Cost: While the Azure control plane cost is relatively low, it is not recommended to operate an AKS environment without business support at an additional premium. If you are a small business, you may be able to add the support tier when you need it and then turn it off to reduce costs.
Multi-Cloud: For many enterprises and independent software vendors this is a requirement, either immediately or in the future. While Kubernetes provides this benefit, DuploCloud's implementation is much easier to maintain and easier to implement.
Feature | Kubernetes | Built-In |
---|---|---|
Ease of use
Features and ecosystem Tools
Suitability for stateful apps
Stability and maintenance
Azure cost
Multi-cloud (w/o DuploCloud)
Orchestration across multiple Cloud providers
The majority of workloads deployed on DuploCloud are in Docker containers.
DuploCloud supports virtually all orchestration techniques across multiple cloud providers, using a simplified and cloud-neutral interface. On Microsoft Azure, orchestration includes support for Managed Kubernetes Service (AKS), and WebApps in Azure, and native Docker Containers.
In addition, the DuploCloud platform has a built-in container management platform that provides an alternative to Kubernetes, which can be complex to implement.
DuploCloud supports many types of applications in Azure, including but not limited to:
Dockerized apps constitute about 90% of our user workloads. The platform orchestrates containerized application deployments using AKS or built-in container orchestrations as defined in the Container orchestration features section.
If you need other services, please get in touch with your DuploCloud support team. The typical turnaround time for creating a custom service is a business week.
Key concepts for using DuploCloud with Docker and Azure
While deploying Dockerized applications, familiarize yourself with some key concepts and terminologies.
See Use Cases for a description of DuploCloud Infrastructures and Tenants.
These are virtual machines. In AKS deployments, they are also called Worker nodes. By default, apps within a Tenant are pinned to VMs in the same Tenant.
Service is a DuploCloud term. DuploCloud Services are not Kubernetes Services. Services are microservices that are defined by a Name, DockerImage, and number of replicas in addition to many other optional parameters. Behind the scenes, a DuploCloud Service maps 1:1 either to a Kubernetes deployment set or to a StatefulSet depending on whether the microservice has stateful volumes or not. There are many optional configurations associated with a DuploCloud Service that represent various ways Docker containers can be run. A few of these are:
Environment variables
Host Network Mode
Volume mounts
Entrypoint or command overrides
Resource caps
Health Checks
If a service needs to be pinned to run only a specific set of Hosts, set an Allocation Tag on the Hosts as well as on the Service. The Allocation Tag is a case-insensitive substring match. For example, an Allocation Tag specified on a Service is usually a substring of the tag specified on the Host. If a Host is tagged HighCpu;HighMem, a Service tagged highcpu can be allocated on it. However, if the Service is tagged highcpu;gpu then it won't be allocated; it would need a Host tagged highcpu;gpu. If a Service does not have any tag set, it can be placed on any Host.
If the Host is tagged with a specific value and you have Services with the same tag, the Host is available for any Service that has no tags. If you want the exclusive assignment of a Host to a set of Services, ensure that every Service in the Tenant is tagged with some value.
In the case of Kubernetes deployments, the concept of Allocation Tags maps to labels on nodes, and on node selectors on the deployment set or StatefulSet.
Host Networking: By default, Docker containers have their own network addresses. you may want these containers to use the same network interface as the VM. This is called Host Network Mode.
Load Balancer: If a service must be accessed by other services, it needs to be exposed using a Load Balancer. Supported Load Balancers include:
A Network Load Balancer (NLB). An NLB distributes traffic across several servers by using the TCP/IP networking protocol. By combining two or more computers that are running applications into a single virtual cluster, NLB provides reliability and performance for web servers and other mission-critical servers.
An Application Load Balancer (ALB). An ALB provides outbound connections to cluster nodes inside the AKS virtual network, translating the private IP address to a public IP address as part of its Outbound Pool.