Turbonomic support ECS for EC2 and/or Faragate

Thank you Ricardo for taking the time to provide your ideas to IBM. We value the relationship with you and appreciate your willingness to share details about your ideas. IBM has evaluated the request and has determined that it cannot be implemented at this time or does not align with our current strategy or roadmap. If you have any additional feedback, thoughts or ideas, or if there is anything else we can do, please do not hesitate to reply to this message to continue the conversation. We are glad to re-assess at a later in 2024 if there is increased customer need/demand for this. thanks

Hi Eva. Thank you so much for your attention.

I thought that ECS use Kubernetes framework enough for a new kubeturbo delevopment. But as you said, this is a cold water on my plans.

My last 5 PoVs that was AWS customers, all of them use ECS and EKS, with plans to move entirely to ECS in the future.

Of course, I don't know how much is the effort to develop a "ecsturbo" but we can walk away from this technology. I have a prospect that is using 5.000 nodes in ECS clusters, for example.

Hi Ricardo - I am always impressed with your technical prowess :) Your experience is valid! But here are the use cases that we really cannot do.

1. if the entire cluster is entirely EKS Fargate - no nodes that are seen managed by customer (this is different from having a Fargate node pool along side an EKS node pool) - we have a challenge that we should support resizing up requests. Requests are the main mechanism to tell AWS what size k3s node should get spun up to run that pod.

2. Yes a spot instance type node is still a node. What I cannot do is predict when those nodes may change to a smaller size, which may mean I shouldn't get rid of one. It's more about the volatility of spot instances. However, I will still move pods, resize workloads and scale spot instance type nodes.

But EKS is not the ask in this Idea ;) The ask in this Idea is to support ECS (AWS's proprietary Elastic Container Service) and ECS Fargate (Serverless ECS), which is an entirely different container orchestrator and not k8s based. I do not see the business justification yet to invest in a team of people to build an ecsturbo probe and handle all the scenarios around ECS. Kubeturbo only can talk to the k8s control plane. ECS is not kubernetes.

Hi Eva. In a recent conversation with my customer, he informed me that for EKS or ECS clusters that use regular EC2, Spot instances or Fargate, if it's possible deploy a kubeturbo as a any other deployment that will change the pods only. After vertical scaling, all infrastructure will be impacted with a reducing (or increasing) in resources. We don;t need to manage the fargate or this ECS worker nodes.

As a recent test, I deployed kubeturbo in a EKS cluster that is all made by spot instances and it worked fine. The changes reduced the number of worker nodes that spun daily.

For Fargate use cases, we need to have a "kubeturbo" that understand the workload and do vertical resizes to assure performance, also reducing requests, making the whole service cheaper.

All AWS large customers are receiving incentives to move to ECS (cheaper, easier to manage and faster education for new hiring). Ignore ECS will narrow us just to EKS customers, reducing our coverage, since customers that are AWS shop, doesn't care if it's proprietary and can't move between technologies.

Fargate = the entire backend is managed by AWS and only visible to AWS. What is the use case that Turbo can impact in Fargate?

For ECS where the customer manages or sees their EC2 instances, there is parking support. https://www.ibm.com/docs/en/tarm/8.9.6?topic=reference-park-stop-start-cloud-resources. Was this value reviewed with the customer?