Container Orchestrators
There are several container orchestration technologies in the state of the art. DuploCloud abstracts the complexity of these allowing you to purely focus on you being able to achieve the deployment, update and debugging of the your containerized application. User can choose which technology to use. DuploCloud supports all of them and makes it easy for the user to consume
  • Natively Built-in a.k.a "I don't care": DuploCloud platform has a built in container management capability which has the exact same interface as the docker run command except that it can be scaled to hundreds of containers across many hosts along with capabilities like associating load balancers, DNS etc.
  • Kubernetes (AWS EKS): DuploCloud platform uses AWS EKS underneath and provides a simple easy to use interface hiding the complexities of Kubernetes. This abstraction also allows you to input more complex K8S configurations around POD, Container, Secrets etc.
  • AWS ECS Fargate: This is a cloud Native proprietary service from AWS. The key advantage of this is that one does not have to manage any servers.
Following is a summary of various parameters based on which we have rated the three technologies. We also describe below the rationale for this rating. DuploCloud is agnostic of which mechanism the user decides to chose.
Higher the dot, the better it is.
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 Duplo)
  • Ease of Use:
    • Kubernetes is not easy and that does not require any explanation. DuploCloud platform has made it far simpler abstracting most complexities so this rating is just relative to other schemes.
    • Built-in Container Orchestration scheme's main advantage of that it is a mirror of Docker Run. One can SSH into a VM, run docker commands to debug and understand what is going on. If you have an application with just 10-15 stateless micro-services that pick configurations using either ENV variables or AWS services like SSM, S3 or Secret store as described here and then you could consider just using the Built-in container orchestration.
    • ECS Fargate has proprietary constructs like Task definitions, tasks, Service etc which require some learning curve. Being serverless, one has no control over the Host Docker hence commands like Docker ps, Docker restart etc are out of scope. It is hardest when debugging a container crash. One has to be very disciplined to be able to debug purely from central logging. DuploCloud does make it relatively easy with out-of-the-box setup for logging, shell access, abstracting complexities of other proprietary constructs and behavior.
  • Features and Ecosystem Tools: Kubernetes is very rich in many additional built-in features and ecosystem tools. most notable ones like Secrets Management and Config Map. In case of BuiltIn and ECS one can rely on native AWS services like AWS Secrets Manager, SSM, S3 etc. Which all the built-in 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: As such it can be argued that statefull applications should be avoided in AWS and instead cloud managed storage solutions should be leveraged for best availability and SLA. But in a scenario where that is undesirable either due to to cost or other reasons then Kubernetes is the best solution. Kubernetes has a built concept called Stateful set and Volumes where it implicitly manages EBS volumes. With Built-in and ECS you have to use a shared EFS drive which has a few more setup steps and may not have feature parity with K8S handling of volumes.
  • Stability and Maintenance: Kubernetes has a come a long way and is now highly stable. One has to remember that it still remains an open source product. But the complexity can mean that when there are complex and advanced features in play things can go wrong. This can also be a situation when the cluster is upgraded to a new version (which by the way is mandatory quite often). But we have seen these issues far less now and the DuploCloud team is available 24x7 for any issues. One should not consume kubernetes without AWS business support and that will add 10% to your bill. The Built-in solution is maintained by DuploCloud itself so there is stability concern assuming you are trusting DuploCloud for everything here :-). ECS comes with the high bar and SLA of AWS.
    • Maintenance should be called out as a pain in EKS because every 2 quarters or so, the EKS version is depricated by AWS as the ecosystem moves very fast and the user is required to upgrade not only their control place but also all the data nodes. While DuploCloud automates the process, it nevertheless requires careful planning and execution.
  • AWS Cost: While the EKS control plane cost is about $75 a month, one should not operate a EKS environment without business support. This can add a 10% premium to your overall bill. If you are a small business you might operate w/o this support tier. One optimization here is one can add the support tier when needed and turn it off, thus saving significant cost.
  • Multi-Cloud: For many enterprises and ISVs this might be a requirement either immediately or in future. If you don't rely on DuploCloud then only Kubernetes is portable across clouds.
Export as PDF
Copy link
Edit on GitHub