Key terms and concepts in DuploCloud container orchestration
The following concepts do not apply to ECS. ECS uses a proprietary policy model, which is explained in a later section.
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
Resource caps
Kubernetes health checks
A Service can be configured to run only a specific set of Hosts by setting allocation tags on the Hosts and Service. Allocation tags are case-insensitive substrings. On a Service, allocation tags should be a substring of the Host tag. For example, if a Host is tagged HighCpu;HighMem, a Service tagged highcpu can be placed on it. Services without allocation tags can be placed on any Host.
If a Host has a specific tag and there are Services with the same tag, the Host can also be used by any Service that doesn’t have a tag. To ensure a Host is only used by a specific set of Services, ensure all Services in the Tenant are tagged.
For Kubernetes Deployments, allocation tags are implemented using labels on nodes and then applying node selectors in your Deployment or StatefulSet configurations.
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., AWS Amazon Certificate Manager (ACM) certificates).
In Kubernetes, the platform creates a NodePort 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 AWS Amazon Certificate Manager (ACM) certificates.
Kubernetes ClusterIP Load Balancers can be used if you are required to expose the application only within the Kubernetes Cluster.
Multiple container orchestration technologies for ease of consumption
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.
| Feature | Kubernetes | Built-In | ECS Fargate |
|---|
One dot indicates a low rating, two dots a medium rating, and three dots a high rating. For example, Kubernetes has a low ease-of-use rating but a high rating for stateful applications.
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.
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).
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.
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.
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.
Ease of use |
Features and ecosystem tools |
Suitability for stateful apps |
Stability and maintenance |
AWS cost |
Multi-cloud (w/o DuploCloud) |