Trainee AWS Cloud Engineer at Cravita Technologies India Private Limited
Real User
Top 5
2024-10-25T09:37:00Z
Oct 25, 2024
I would like to see enhanced faster application scaling and better integration with the elastic file system to unify storage volumes and improve the launch time of instances. It requires enhancements to orchestrate containers more effectively and handle resource limits like CPU and memory constraints, particularly when load balancing, as it affects the auto-scaling configurations.
Senior Technical Architect; Head of Platform at Blenheim Chalcot IT Services India
Real User
Top 5
2024-10-18T15:20:00Z
Oct 18, 2024
Challenges include higher costs for smaller clients, limited control over underlying infrastructure customization, and potential latencies during task startup. There's also the need for comprehensive monitoring to manage costs effectively.
Global Solutions Architect at a computer software company with 201-500 employees
Real User
Top 20
2024-10-16T19:03:00Z
Oct 16, 2024
AWS Fargate needs improvement in terms of setup complexity. Currently, it is difficult to configure compared to other services like EC2 instances or Lambda functions.
Service computing is not as straightforward compared to other computing services. It requires more effort to use effectively. In comparison to traditional cloud computing services, service computing demands a deeper understanding and a more complex setup. Additionally, integrating it with an existing infrastructure can be challenging.
If there are any options to manage containers, that would be good. That relates more to the cost point. For example, over the next three months, I'll be making a comparison between solutions like CAST AI and other software-as-a-service platforms that offer Kubernetes management with an emphasis on cost reduction. Instead of deploying in private, you can use CAST AI with any Kubernetes provider and any cloud, for example. This may solve scaling problems. So, if it allows you to reduce costs by four percent or more of your processing expenses, that AI-assisted Kubernetes-managed solution is something to consider. After saving on scaling using containers with a self-managed cloud cluster, I think the next step is to use an additional approach. Cloud providers may help you reduce some costs, but a specialized service focused on optimizing your Kubernetes resources in relation to your container usage could be beneficial. For example, this kind of solution allows you to not only auto-select the instances for cluster nodes based on the current processing load but also define containers that can be spot instances in terms of fault tolerance. In those cases, the solution will deploy your containers on spot instances, distribute your spot-tolerant processes across the cluster, and potentially achieve additional cost reductions. You cannot do that with something like Fargate. That's the next step for a company that needs to scale its processes to another level. Maybe that's worth considering.
We have encountered some issues recently. For example, AWS released a new feature called a better quarter, which greatly helped us. Before that, we faced challenges in vertically scaling our workload. After the release of the new feature, we were able to scale vertically by utilizing sixteen CPU units and a large memory capacity. We also experienced issues with scaling in, as it would abruptly terminate the task. However, AWS introduced a feature called task protection that has been helpful in resolving this issue. Nevertheless, during this period, we were exploring a move to Spark due to the challenges we encountered, which is why I rated the overall product as an eight out of ten.
AWS Cloud Architect at a tech services company with 1-10 employees
Real User
2022-12-08T17:15:45Z
Dec 8, 2022
This service could be improved if the AWS Console was either reverted to an old version or if it updates its functionalities. I would like to see the older dashboard instead of the newer version. I don't like the new dashboard.
We would like to see some improvement in the process documents that are provided with this product, particularly for auto-scaling and other configuration tools that are a bit complicated.
I heard from my team that it's not easy to predict the cost. That is the only issue we have with AWS Fargate, but I think that's acceptable. AWS Fargate isn't user-friendly. Anything related to Software as a Service or microservice architecture is not easy to implement. You're required to have DevOps from your side to implement the solution. AWS Fargate is just a temporary solution for us. When we grow to a certain level, we may use AKS for better control.
LÃder de Proyecto at a tech services company with 201-500 employees
Real User
2022-01-04T20:57:10Z
Jan 4, 2022
The main area for improvement is the cost, which could be lowered to be more competitive with other major cloud providers. Because eventually, the cost of the infrastructure gets higher, which means clients opt for fewer deployments in order to cut costs.
A new compute engine that enables you to use containers as a fundamental compute primitive without having to manage the underlying instances. With Fargate, you don’t need to provision, configure, or scale virtual machines in your clusters to run containers. Fargate can be used with Amazon ECS today, with plans to support Amazon Elastic Container Service for Kubernetes (Amazon EKS) in the future.
Fargate has flexible configuration options so you can closely match your application needs and...
I would like to see enhanced faster application scaling and better integration with the elastic file system to unify storage volumes and improve the launch time of instances. It requires enhancements to orchestrate containers more effectively and handle resource limits like CPU and memory constraints, particularly when load balancing, as it affects the auto-scaling configurations.
Challenges include higher costs for smaller clients, limited control over underlying infrastructure customization, and potential latencies during task startup. There's also the need for comprehensive monitoring to manage costs effectively.
AWS Fargate needs improvement in terms of setup complexity. Currently, it is difficult to configure compared to other services like EC2 instances or Lambda functions.
Service computing is not as straightforward compared to other computing services. It requires more effort to use effectively. In comparison to traditional cloud computing services, service computing demands a deeper understanding and a more complex setup. Additionally, integrating it with an existing infrastructure can be challenging.
AWS needs to work on multi-container enterprise developer components. They need to simplify that kind of setup.
If there are any options to manage containers, that would be good. That relates more to the cost point. For example, over the next three months, I'll be making a comparison between solutions like CAST AI and other software-as-a-service platforms that offer Kubernetes management with an emphasis on cost reduction. Instead of deploying in private, you can use CAST AI with any Kubernetes provider and any cloud, for example. This may solve scaling problems. So, if it allows you to reduce costs by four percent or more of your processing expenses, that AI-assisted Kubernetes-managed solution is something to consider. After saving on scaling using containers with a self-managed cloud cluster, I think the next step is to use an additional approach. Cloud providers may help you reduce some costs, but a specialized service focused on optimizing your Kubernetes resources in relation to your container usage could be beneficial. For example, this kind of solution allows you to not only auto-select the instances for cluster nodes based on the current processing load but also define containers that can be spot instances in terms of fault tolerance. In those cases, the solution will deploy your containers on spot instances, distribute your spot-tolerant processes across the cluster, and potentially achieve additional cost reductions. You cannot do that with something like Fargate. That's the next step for a company that needs to scale its processes to another level. Maybe that's worth considering.
We have encountered some issues recently. For example, AWS released a new feature called a better quarter, which greatly helped us. Before that, we faced challenges in vertically scaling our workload. After the release of the new feature, we were able to scale vertically by utilizing sixteen CPU units and a large memory capacity. We also experienced issues with scaling in, as it would abruptly terminate the task. However, AWS introduced a feature called task protection that has been helpful in resolving this issue. Nevertheless, during this period, we were exploring a move to Spark due to the challenges we encountered, which is why I rated the overall product as an eight out of ten.
This service could be improved if the AWS Console was either reverted to an old version or if it updates its functionalities. I would like to see the older dashboard instead of the newer version. I don't like the new dashboard.
We would like to see some improvement in the process documents that are provided with this product, particularly for auto-scaling and other configuration tools that are a bit complicated.
AWS Fargate could improve the privileged mode containers. We had some problems and they were not able to run.
I heard from my team that it's not easy to predict the cost. That is the only issue we have with AWS Fargate, but I think that's acceptable. AWS Fargate isn't user-friendly. Anything related to Software as a Service or microservice architecture is not easy to implement. You're required to have DevOps from your side to implement the solution. AWS Fargate is just a temporary solution for us. When we grow to a certain level, we may use AKS for better control.
The main area for improvement is the cost, which could be lowered to be more competitive with other major cloud providers. Because eventually, the cost of the infrastructure gets higher, which means clients opt for fewer deployments in order to cut costs.