Amazon Elastic Container Service (Amazon ECS) vs. CoreOS rkt / Container Linux (project ended)

Amazon Elastic Container Service (Amazon ECS) is well suited where you need the ease of managing the clusters by letting AWS do the stuff for you. Obviously, whenever you want to run the docker based workloads, it is always better to go for either AWS ECS or AWS EKS. If you are interested in staying at AWS only and don't want to be cloud-agnostic, then go for AWS ECS instead of AWS EKS. AWS ECS is cheaper than AWS EKS and also more managed by AWS and better integrated with other AWS services. If you want to run those workloads as serverless, then AWS ECS Fargate is the best option to go with. If you already have a Kubernetes based setup that you want to migrate to AWS, then go for AWS EKS instead of AWS ECS.

Incentivized

It is very well suited for local testing where one knows what is being worked on and knows all the dependencies of the software project. On the other hand, it would be less appropriate in situations where a simple chroot can do the trick without the overhead of running a Go application.

Incentivized

• Well Integrated - As with the majority of AWS services, ECS works will with any other AWS product (Route 53, CloudWatch, IAM, etc).
• Easy to get started with - It is easy to get started building just about anything in AWS and using ECS is no exception to this rule. Be careful though -- AWS lets you do/build anything in any way you could think of and allowing yourself to shoot yourself in the foot is no exception.

Incentivized

• Running a secure container without messing up with low-level details
• Very clear and straightforward approach to building a container
• A way to go for new projects thinking of containers
• Comprehensive and well-written documentation compatible with UNIX keep it simple way of thinking

Incentivized

• The user interface sometimes seem to be confusing and cumbersome. It can be improved so that people can understand clearly which section to go for which functionality.
• When a container fails, the error logs are not readily available on the ECS console. If it can be provided it would be easier to debug from there itself instead of going to our log manager.
• Sometimes the old EC2 containers become stale and need to be restarted manually. There should be a notification for such scenarios. We have mostly been finding it out on our own and then fixing it by manually restarting EC2 instances.
• If this could be proactively monitored and notified, it would be great.

Incentivized

• Market share, it's often very difficult to find new talent who use CoreOS rkt.
• Lack of wow features, CoreOS rkt doesn't necessarily offer any immediate advantages over other container solutions.

Incentivized

Aside from some ECS-specific terms to learn at first, learning & starting to use ECS is relatively straightforward. AWS docs on the topic are also of high quality, with sound & relevant examples to follow. Troubleshooting container issues is also a breeze thanks to CloudWatch integration & helpful error messages on the AWS console.

Incentivized

Support is relatively good, although the documentation sometimes is lacking, as well as outdated in our experience, especially when we initiated the process of using this service. But once we found how to assemble things, we haven't really required support from anyone at AWS, the service works without problems so we haven't had the need to contact support, which speaks well of how ECS is built.

Incentivized

AWS Elastic Beanstalk is a good beginner level orchestration service but lacks container management and scaling capabilities. EC2 is again not a Managed cloud service. It is like just renting a computer on cloud and then managing it on our own. Compared to these ECS is a comprehensive solution that provides management, scaling, containerization and other service connectivity out of the box.

Incentivized

We evaluated CoreOS rkt and Docker when selecting software solutions for my department. We ended up using CoreOS rkt because of how well it fits with CoreOS and the choice of gRPC for the API. We provide a managed service that runs CoreOS on a bare metal server, CoreOS rkt was a logical choice for compatibility. We also found that developers were having better scusess interacting with gRPC than other container engines REST protocols. It was a close race but eventually there were just enough small benefits to push CoreOS rkt in front of the competition.

Incentivized

• We run 8 web applications (demo instances) on a single machine. At a particular time, no more than 3 applications run simultaneously. So, we keep only required containers up. This helps us to provision small EC2 machines without compromising performance.
• Overall Amazon ECS helps to have less number of dedicated machines as more than one solution can be deployed on a single instance. This reduces costs a lot.

Incentivized

• Developers spend less time configuring and more time coding.
• Less time training developers as CoreOS rkt lets them use whatever hardware and operating system they want.
• Reduced our IT costs, solutions are containerized using CoreOS rkt meaning they can write one solution with many developers in mind.

Incentivized