Amazon Elastic Container Service (Amazon ECS) is a scalable, high performance container management service that supports Docker containers.
N/A
Heroku Platform
Score 9.2 out of 10
N/A
The Heroku Platform, now from Salesforce, is a platform-as-a-service based on
a managed container system, with integrated data services and ecosystem for deploying modern apps. It takes an app-centric
approach for software delivery, integrated with developer tools and
workflows. It’s three main tool are: Heroku Developer Experience (DX), Heroku
Operational Experience (OpEx), and Heroku Runtime.
Heroku Developer Experience (DX)
Developers deploy directly from tools like…
There is no additional charge for Amazon ECS. You pay for AWS resources (e.g., Amazon EC2 instances or Amazon EBS volumes) you create to store and run your application. You only pay for what you use, as you use it; there are no minimum fees and no upfront commitments.
—
More Pricing Information
Community Pulse
Amazon Elastic Container Service (Amazon ECS)
Heroku Platform
Features
Amazon Elastic Container Service (Amazon ECS)
Heroku Platform
Container Management
Comparison of Container Management features of Product A and Product B
Amazon Elastic Container Service (Amazon ECS)
8.1
Ratings
5% above category average
Heroku Platform
-
Ratings
Security and Isolation
9.00 Ratings
00 Ratings
Container Orchestration
8.50 Ratings
00 Ratings
Cluster Management
7.80 Ratings
00 Ratings
Storage Management
8.00 Ratings
00 Ratings
Resource Allocation and Optimization
7.30 Ratings
00 Ratings
Discovery Tools
7.30 Ratings
00 Ratings
Update Rollouts and Rollbacks
8.50 Ratings
00 Ratings
Self-Healing and Recovery
8.40 Ratings
00 Ratings
Analytics, Monitoring, and Logging
8.20 Ratings
00 Ratings
Platform-as-a-Service
Comparison of Platform-as-a-Service features of Product A and Product B
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.
Heroku is very well-suited to early stage and/or rapidly changing projects. It is great for getting moving quickly or changing direction quickly. In scenarios where there is already scale or well-defined requirements, it may be preferable to set things up directly on AWS or another cloud provider to avoid the additional costs of Heroku as the middleman.
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.
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.
Could be less expensive, although you get what you pay for
Sleeping apps can be an annoyance: Heroku automatically puts your apps in sleep mode and they have to spin back up after periods of inactivity. Much of this can be solved but it requires working around the built-in functionality. I understand why they do it but it's an area that could be improved.
Restrictions to server access means you can't customize as much as you could if you owned the server. But again, this is also a benefit because it's about convention over configuration. So you can't configure as much, but then, you typically don't have to.
Heroku is a critical and core part of our infrastructure that is serving our customers well. We are very satisfied with the cost of our solution. While it would be difficult to move away from Heroku, we have no plans to do so. We have had no major issues with it and it is a pleasure to use. Other products on the market might offer comparable functionality, but until we expose a need that Heroku cannot satisfy, we'll stay the course.
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.
If you have basic backend and Git knowledge, deploying to Heroku is a breeze. It now supports many types of backends, including hybrid backends (ex: nginx + application server) through its build pack system. The dashboard is easy to use, and the CLI tools are well designed. Accessing the add-ons is also easy. It uses an SSO-type system so you don't have to re-sign in to view the add-on dashboards.
Heroku availability correlates pretty strongly to AWS US EAST availability. We had a couple of times where there was a Heroku-specific issue but not for the last 7-8 months.
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.
I've used it for many years without facing any major problem. It's not hard at all to get used to it, it's documentation is outstanding and simple. We are close to 2020 and I don't think most of the existing companies or startups should still face old problems such as wasting time deploying code and calculate computing resources.
Be ready to pay a bit more than expected in the beginning if you're migrating from a big server. The application is probably not ready for the change and you have to keep improving it with time.
It's also important to consider that you can't save anything to the disc as it will be lost when your application restarts, so you have to think about using something like S3.
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.
Heroku has advantages over Docker, Google App Engine and AWS products, but it depends largely on your use case. If you are already in AWS, it's probably in your best interest to stay with AWS products. However, other "Cloud Formation/Orchestration" products like Docker are typically lacking the ease-of-use factor that allows you to get up and running with Heroku quickly.
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.