CI/CD SaaS tools primarily focus on Kubernetes. But in that single-minded focus, most solutions have forgotten about ECS customers. Harness hasn’t. Harness understands that many customers are happy with their ECS environments and don’t have plans to move to Kubernetes.
Our 2020 State of Continuous Delivery Insights Report from earlier this year found that 31% of companies use Amazon ECS exclusively for container orchestration, while 67% use Kubernetes.
Naturally, this led to CI/CD vendors building their applications for Kubernetes. But in doing so, they alienated a quarter of the market.
The Harness ECS experience is now uniform with Harness Kubernetes experience. ECS container definitions and task definitions can be managed in Git. Users can now run ECS workloads through Run Task to allow short term workloads to be spun up, executed, and terminated by ECS without user intervention.
The Harness ECS Experience empowers developers to automate their deployments without having to manage deployment scripts and various failure conditions during deployment. Harness provides the ability to pull ECS Task Definitions from a user's Github and then allows them to templatize their Task Definitions across teams, users can also override values in their Task Definition.
Harness ECS support provides out of the box Canary, Blue-Green, and Rolling Deployment strategies with automated rollback capabilities. Users no longer have to script out these deployments or manage failure scenarios.
Harness now has native support for running short-lived ECS Tasks and terminating those tasks upon completion. This is extremely useful for running containerized DB Migration Workloads or Smoke Testing Workloads. No more scripting those steps, a user can bring a container for Harness to deploy it as a task with their ECS Service.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.