Multiple container orchestration technologies for ease of consumption
Most application workloads deployed on DuploCloud are in Docker containers. The rest consist of serverless functions, Big data workloads like Amazon EMR jobs, Airflow and SageMaker. 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:
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.
Use the feature matrix below to compare the features of the orchestration technologies that DuploCloud supports. Whatever option you choose, DuploCloud can help 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 applications.
Use the definitions below to understand how each feature in the matrix above is rated compared to Kubernetes, Built-in, or ECS Fargate.
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 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 such as SSM, S3, or Secret store, 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 have no control over the Host Docker, so commands such asdocker ps and docker restart
are unavailable. This makes debugging a container crash very difficult and time-consuming. DuploCloud simplifies using Fargate with an out-of-the-box setup for logging, shell access, and abstraction of proprietary constructs and behavior.
Features and Ecosystem Tools: Kubernetes is rich in additional built-in features and ecosystem tools, most notably Secrets Management and ConfigMaps. Built-In and ECS rely on native AWS services such as AWS Secrets Manager, SSM, S3, and so on. While Kubernetes features have an equivalent in AWS, 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 AWS. Instead, managed cloud 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 Elastic Block Storage (EBS) volumes. With Built-in and ECS, you must use a shared EFS 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 EKS, as versions are frequently deprecated, requiring you to upgrade the control plane and data nodes. While DuploCloud automates this upgrade process, it still requires careful planning and execution.
AWS Cost: While the EKS control plane cost is relatively low, operating an EKS environment without business support (at an additional premium) is not recommended. If you are a small business, you may be able to add the support tier when you need it and remove it when not needed to reduce costs.
Multi-Cloud: For many enterprises and independent software vendors this is, or will soon be, a requirement. While Kubernetes provides this benefit, DuploCloud's implementation is much easier to maintain and implement.
Feature | Kubernetes | Built-In | ECS Fargate |
---|---|---|---|
Ease of use
Features and ecosystem tools
Suitability for stateful apps
Stability and maintenance
AWS cost
Multi-cloud (w/o DuploCloud)
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 use cases for a description of DuploCloud Infrastructures and Tenants.
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 many other optional parameters. Behind the scenes, a DuploCloud Service maps 1:1 to a DeploymentSet or a StatefulSet, based on whether the microservice has stateful volumes. There are many optional Service configurations representing various ways that Docker containers can be run. Among these are:
Environment variables
Host Network Mode
Volume mounts
Entrypoint or command overrides
Resource caps
Kubernetes health checks
If a service needs to be pinned to run only a specific set of hosts, you set an Allocation Tag on both the hosts, as well as the Service. Allocation Tags are case-insensitive substrings. Allocation Tags on a service should be a substring of the tag specified on the host. For example, if a Host is tagged as HighCpu;HighMem, then the service (if it is tagged highcpu) can be allocated on this host. 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 which has no tags. If you want the exclusive assignment of a host to a set of services, ensure every service in the Tenant is tagged.
For Kubernetes deployments the concept of allocation tags is realized by mapping it to labels on nodes and then node selector on the Deploymentset or Statefulset
By default, Docker containers have their network addresses. At times, you may want these containers to reuse the same network interface that the VM uses. This reuse is called Host Network Mode.
Every DuploCloud Service that communicates with other Services, needs to be exposed by a LoadBalancer. DuploCloud supports the following Load Balancers (LBs).
Application Elastic Load Balancer (ELB): When exposed by an ELB, the DuploCloud Service is reachable from anywhere unless it is marked as Internal, in which case it is reachable only from within the VPC (or DuploCloud Infrastructure). Application ELBs allow you to use a certificate for terminating SSL on the LB, which allows you to avoid providing application SSLs and certificates, such as a certificate issued from AWS Amazon Certificate Manager (ACM). In Kubernetes, the platform creates a NodePort pointing to the DeploymentSet and adds the Host IPs of the worker nodes 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 to the Kubernetes Proxy running on each Worker Node. The Worker Node forwards the NodePort to the container.
Classic ELB (Only applicable to Built-In Container Orchestration): Classic ELBs can be used when the application is exposing non-HTTP ports and they operate on any TCP port. When exposed by an ELB, the Service is reachable from anywhere unless it is marked as Internal, in which case it is reachable only from within the VPC (or DuploCloud infrastructure). Classic ELBs allow you to use a certificate for terminating SSL on the LB. which allows you to avoid providing application SSLs and certificates, such as a certificate issued from AWS Amazon Certificate Manager (ACM).
Cluster IP (Kubernetes only): Kubernetes ClusterIP load balancers can be used if you are required to expose the application only within the Kubernetes Cluster.