Amazon Elastic Container Service Reviews

I have set up Container Service environments for various clients using different cloud providers, including AWS. I have used the Amazon Elastic Container Service in this capacity.

One of my clients from Israel is running web-based applications that are using PostgreSQL as the backend database connection. I think that it is a user-learning software, and they provide it to big companies to give KT sessions for new employees.

They use the Totara application and for that, we have set up the infrastructure including VBA and database applications. We also manage their Amazon Route 53, and we have set up Jenkins for CICD purposes.

They use EC tools for AWS and try to save on costs through the various savings plans and through the RX solution.

From time to time, their solution has problems due to the failure of the underlying hardware. When they deprecate older hardware, for example, sometimes it causes the production environment to be affected. This is the main cause of their problems. In response, we moved them to the ECS solution, after which we get a highly-available environment with minimal billing on a monthly basis.

This solution is a good deal for our clients.

Using this Container Service is a very cost-effective solution. We can use this service with minimal costing.

The production environment is highly available, which nowadays is a requirement for all of the big companies. There is a 99% uptime with this Amazon ECS.

This is a fully-managed product and we don't have to be concerned with problems related to the underlying hardware or configuration management.

The problem with containerization technology is that many businesses do not trust it right now, and only use it in their development environment. For example, if you spin down the container then all of the data inside it gets deleted. From our perspective, we think that this technology is good, and it is really an issue of awareness. I am very much excited by this technology and am okay with it. I think that it would help if the vendor provided more use cases and explanations as to how ECS can be utilized.

As part of my experience, I have been working with this cloud-based technology for the past four years.

Based on the experience that I have had throughout my career, I find that this product is very stable. The only problem it has is with awareness, where businesses need to better trust it.

It's predetermined that ECS is scalable. There are two types of scalability, which are horizontal scaling and vertical scaling. If you upgrade your container from a resource perspective, that is horizontal scaling. If you upgrade the core device, where suppose that you have one container and after that, you have created multiple containers to distribute the nodes, then that is vertical scaling. ECS already covers these in the scaling policy, so we have nothing to worry about in this regard.

Our client with the Totara application has thousands of users that they are managing in ECS.

We have not used the Amazon technical support, although some of our clients have already purchased it. We rarely raise issues that are the result of the underlying hardware. That cannot be resolved from our side because it is managed by AWS.

In 99% of the cases, we solve issues through support that we provide to our clients.

Prior to ECS, we used Docker and Swarm. This is an open-source technology but there are some issues with that solution, which is why we have chosen the dedicated service by AWS. We always try to take the easiest approach.

When you use Swarm, you are responsible for managing the application. There is the possibility of failure because of a version mismatch or some of the other dependencies. But, if you are going to use the ECS service provided by AWS then they manage the infrastructure and all of the underlying hardware, as well as configuration management. We don't need to care about any of these things. Rather, we only have to set up the infrastructure and support it. This is a benefit to using ECS.

When I first started working with ECS, my feeling was that it was complex. However, after working on it for a longer time, I now feel that it's very simple. It took me six months of working on it, and now I am very happy.

Essentially, it depends on how much experience you have. With more experience, you feel it is very simple, whereas if you do not know the solution, then you will feel it is complex.

If you start with a container that is 500MB or 800MB in size, it will take about 30 minutes to deploy on the production server. We follow a deployment plan and implementation strategy that is specified in our corporate documentation. We generally follow this when we deploy in a production environment.

Our strategy for new release and deployment begins with backing up the currently-running solution. We take a backup of the current artifact because whenever we deploy a new release in the production environment, there is a change that we will experience a failure. We also keep a backup of the older releases.

The next step is that we test it from the various environment test stages, including beta and staging. We prefer to deploy to various environments.

There is also an issue of authentication that is mandatorily applied. Only release managers or release administrators can deploy any changes to the production environment. It is not possible for developers to perform this task.

After the deployment to the staging area, there is a QA to who we give ownership for testing. Once QA approves the release, the deployment will take place on the production server.

There are a few more steps in our process, but this is a summary of our strategy.

We normally use the AWS deployment tool, although sometimes, we use an open-source deployment tool. Price-wise, it is always best to use open-source technology because it will reduce your costs.

The deployment and maintenance are done for the client by our in-house team. We have a team of between four and five members, and I am the senior person who is leading them right now. My engineers work on projects and I guide the various steps. If they face any issue or there is any doubt, then I provide guidance. I am a solution architect, as well, and I always try to meet the project deadline so that the client will always be satisfied.

We provide technical support for our clients, as well. The first step is that we need to understand the infrastructure. We need to know how the infrastructure has been set up and what the configuration details are. We need to know which applications are running in the container. Basically, we need the infrastructure details. If you provide the infrastructure diagram, that will be helpful input for us. Essentially, we have to become familiarized with the infrastructure so that we can easily troubleshoot any issue. This way, if the business is negatively affected then we can give a solution shortly.

Our client was paying up to $2,000 USD per month for 20 to 22 servers before implementing ECS. Nowadays, they pay $400 to $500 per month, which is a huge difference in the yearly billing.

Our client is paying between $400 and $500 USD per month for this service.

My advice for our clients is that before creating the infrastructure, take steps to analyze your needs, and gather the requirements. You want to know what the requirements are, and what resource utilization you have. Suppose, for example, that your requirements are for two CPU cores and one terabyte of RAM. If you are not aware of the actual requirements of the application and the user then you work with the unknown and run the risk of setting up an infrastructure with a high level of resources. This will be costly.

Our approach is to take some time to understand the application and the resource requirements before the setup. After analyzing, we draw the diagram to prepare the plan and then set up the infrastructure.

The biggest lesson that I have learned from using this product is that it is highly available, cost-effective, and reliable. I get all three of these benefits from this technology.

I would rate this solution a nine out of ten.

We are using Amazon Elastic Container Service for Docker-based configuration. Previously, we had to manually go into an instance and then issue all Docker agents and instances. Now, we are using Amazon ECS to automate all of our Docker containers.

We are deploying our microservices architecture in the ECS container install. We are using ECS as a service.

It has an Auto Scaling group feature. We can use this feature to have an Auto Scaling group to specify a minimum and maximum count for all types of configurations. Based on the specified values, Amazon Elastic Container Service scales the required CPU environmental metrics.

Sometimes, the instances fail under the ECS container cluster, and we have to manually go and find out the black sheep in the ECS container instance. 

We had an issue earlier where one of the instances under the ECS container cluster went down, and we were not able to identify that instance. The instance got terminated, but a new instance did not come up. Therefore, I had to manually get that instance up. It could be optimized better. In production, we normally cannot sustain such things. It can be optimized in terms of instances, durability, and serving the requests of customers.

We have been dealing with Amazon Elastic Container Service for three to four years. 

It's good. Our platform stability has rated from 97%, 98% to 99.99%. We are pretty much happy with the stability of Amazon Elastic Container Service. We have been allocated a relationship manager, and he will be more than happy to offer all the technical specs and the building details. We didn't find any issues as of now.

It's scalable. We haven't found any issues as of now in our organization. It's good. 

It's very good. We'll be getting timely updates about the new features and objects available. They will know how we are deploying and whether we want any technical support. If you're going for a long, big bang approach of releasing the product as a whole, they'll be warming out ELBs. We don't know how ELB warming works out. They'll provide some extra help. So, technical support is very good.

The initial setup is straightforward. We'll be using AWS CLI commands for initializing the cluster. It is not hard to set up. It is pretty straightforward. 

We deployed it ourselves. We have four DevOps engineers and four AWS engineers for a team of 150 developers. We have enough for the complete platform.

I don't exactly deal with the pricing. We have a separate Infra team that deals with the pricing. They are more into the scalability part. 

Based on our requirements, the pricing will increase. The automation teams will test some of the benefits to see how can we can optimize the cost. They'll have a security manager connection and some alerts based upon the usage to see how to reduce the building cost based upon the installations. 

I would recommend Amazon Elastic Container Service. They have a big R&D team, and they'll be providing good features for customers. I think AWS has been pretty good on this R&D thing. I would like to appreciate their team, which continuously looks into customer satisfaction and comes up with a new bunch of services every time. They're moving to a customer-centric approach. 

We aren't looking into specific new features. We are in the testing phase currently. If they are releasing some new features, we should definitely use them based on our requirements.

I would rate Amazon Elastic Container Service an eight out of ten.

We use the solution for backup.

The solution is user-friendly. Some of its features are better than Azure.

The solution’s UI should be improved.

I have been using the solution for the past two years.

The solution is stable.

The solution is scalable. We have 50 users for the solution.

The support is responsive.

The initial setup is complex. We need a developer and an operations personnel for the deployment.

The pricing of Amazon EC2 Container Service is average.

I have worked with Azure.

I rate Amazon EC2 Container Service a nine out of ten.