An overview of the container orchestration technologies DuploCloud supports
Most application workloads deployed on DuploCloud are in Docker containers. The rest consist of serverless functions, and big data workloads like Amazon EMR jobs, Airflow, and Sagemaker. DuploCloud abstracts the complexity of container orchestration technologies, allowing you to focus on deploying, updating, and debugging your containerized application.
Among the technologies DuploCloud supports are:
Kubernetes: On AWS, DuploCloud supports orchestration using Elastic Kubernetes Service (EKS). On GCP we support GKE auto pilot and node-pool based. On Azure we support AKS and Azure web apps.
Built-in (DuploCloud): DuploCloud platform's Built-in container management has the same interface as the docker run command, but it can be scaled to manage hundreds of containers across many hosts, providing capabilities such as associated load balancers, DNS, and more.
AWS ECS Fargate: Fargate is a technology you can use with Elastic Container Service (ECS) to run containers without having to manage servers or clusters of EC2 instances.
You can use the feature matrix below to compare the features of the orchestration technologies that DuploCloud supports. DuploCloud can help you implement whatever option you choose through the DuploCloud Portal or the Terraform API.
See the sections below for a detailed explanation of the cloud orchestrator's feature matrix ratings.
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 use/adoption.
DuploCloud's Built-in orchestration mirrors docker run. You can Secure Shell (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 AWS services like SSM, S3, or, consider using DuploCloud's Built-in container orchestration.
ECS Fargate contains proprietary constructs (such as task definitions, tasks, or services) that can be hard to learn. As Fargate is serverless, you can't control the host Docker, so commands such as docker ps and docker restart are unavailable. This makes debugging a container crash very difficult and time-consuming. DuploCloud simplifies Fargate with an out-of-the-box setup for logging, shell access, and abstraction of proprietary constructs and behavior.
Kubernetes is rich in additional built-in features and ecosystem tools like Secrets and ConfigMaps. Built-in and ECS rely on native AWS services such as AWS Secrets Manager, SSM, S3, and others. While Kubernetes features have AWS equivalents, third parties like Influx DB, Time Series DB, Prefect, etc. tend to publish their software as Kubernetes packages (Helm charts).
Stateful applications should be avoided in AWS. Instead, managed cloud storage solutions should be leveraged for the best availability and Service Level Agreement (SLA) compliance. If this is undesirable due to cost, Kubernetes offers the best solution. Kubernetes uses and to implicitly manage Elastic Block Storage (EBS) volumes. With Built-in and ECS, you must use a shared Amazon Elastic File System (EFS) drive, which may not have feature parity with Kubernetes volume management.
Although Kubernetes is highly stable, it is an open-source product. Kubernetes' native customizability and extensibility can lead to points of failure. For example, when a mandatory cluster upgrade is needed. This complexity often leads to support costs from third-party vendors. Maintenance can be especially costly with EKS, as versions are frequently deprecated, requiring you to upgrade the control plane and data nodes. DuploCloud automates this upgrade process but still requires careful planning and execution.
AWS Cost
EKS control plane is fairly inexpensive, but operating an EKS environment without business support (at an additional premium) is not recommended. Small businesses may reduce costs by adding the support tier only when needed.
Multi-Cloud
For many enterprises and independent software vendors, multi-cloud capabilities are, or will soon be a requirement. While Kubernetes provides this benefit, DuploCloud's implementation is much easier to maintain and implement.
Stability and maintenance
AWS cost
Multi-cloud (w/o DuploCloud)
Ease of use
Features and ecosystem tools
Suitability for stateful apps
Key terms and concepts in DuploCloud container orchestration
Familiarize yourself with these DuploCloud concepts and terms before deploying containerized applications in DuploCloud. See the DuploCloud Common Concepts section for a description of DuploCloud Infrastructures, Tenants, Hosts, and Services.
These are virtual machines (EC2 Instances, GCP Node pools, or Azure Agent Pools). By default, apps within a Tenant are pinned to VMs in the same Tenant. One can also deploy Hosts in one Tenant that can be leveraged by apps in other Tenants. This is called the shared-host model. The shared-host model does not apply to ECS Fargate.
Service is a DuploCloud term and is not the same as a Kubernetes Service. In DuploCloud, a Service is a micro-service defined by a name, Docker Image, number of replicas, and other optional parameters. Behind the scenes, a DuploCloud Service maps 1:1 to a Deployment or StatefulSet, based on whether it has stateful volumes. There are many optional Service configurations for Docker containers. Among these are:
Environment variables
Host Network Mode
Volume mounts
Entrypoint or command overrides
Allocation tags allow you to control which Hosts a Service can run on by specifying tags on both the Host and the Service. Services without allocation tags can be scheduled on any Host.
Docker Services use case-insensitive, substring-based matching.
For example, if a Host has the tag HighCpu;HighMem, a Service tagged highcpu or cpu would match and be eligible to run on that Host.
Kubernetes Deployments use exact, case-sensitive matching based on Kubernetes node labels and node selectors. For example, a Host tagged frontend-prod will only match a Service with the exact same tag. For example Frontend-Prod or frontend-prod-1
If a Host is tagged and a matching Service exists, the Host may still be used by untagged Services unless all Services in the tenant are tagged. To fully isolate Hosts for a specific purpose, ensure all Services use allocation tags.
By default, Docker containers have network addresses. Sometimes, containers share the VM network interface. This reuse is called host networking mode.
A DuploCloud Service that communicates with other Services, must be exposed by a Load Balancer. DuploCloud supports the following Load Balancers (LBs).
A DuploCloud Service exposed by an ELB is reachable from anywhere unless marked Internal, then, is only reachable from within the VPC (or DuploCloud Infrastructure). Application ELBs allow you to use a certificate to terminate SSL on the LB and avoid providing application SSLs and certificates (e.g., certificates).
In Kubernetes, the platform creates a pointing to the Deployment and adds the Worker Nodes' Host IPs to the ELB. Traffic flows from the client to the external port defined in the ELB (for example, 443), to the ELB's NodePort (for example, 30004 on the Worker Node), and the Kubernetes Proxy running on each Worker Node. The Worker Node forwards the NodePort to the container.
Classic ELBs can be used when an application exposes non-HTTP ports that operate on any TCP port. Unless marked as Internal, Services exposed by an ELB are reachable from anywhere. Internal Services are reachable only from within the VPC (or DuploCloud infrastructure). Classic ELBs let you use a certificate to terminate SSL on the LB. This allows you to avoid providing application SSLs and certificates, such as certificates.
Load Balancers can be used if you are required to expose the application only within the Kubernetes Cluster.
Resource caps
Kubernetes health checks
-.