aws / aws/containers-roadmap

[EKS + Fargate] [request]: Managed Knative (i.e., competitor to Google Cloud Run)

Open
#763 2 comments 113 reactions 0 assignees View on GitHub
EKS Fargate Proposed
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**

I'm curious if there is any interest in building a managed Knative platform for AWS, similar to Google Cloud Run.

**Which service(s) is this request for?**

This could seemingly leverage Fargate + EKS behind the scenes, but would be better as a new service that doesn't require paying for the EKS control plane and compute resources required to run Knative / Itsio.

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

Fargate with EKS is a step in the right direction for a serverless CaaS platform based on FOSS / open standards, but it lags behind Google Cloud Run in certain respects, such as:

* No ability to scale to 0. At least a minimal number of containers must be running perpetually to provide HA in many cases, which can lead to a lot of underutilization and wasted compute costs.

* Fargate would ideally be capable of spinning up a container in under a second to support time-sensitive, event-driven use cases like scaling to 0, where usability is seriously impacted by longer start times. I believe this is not possible with Fargate today due to #696. In addition, Fargate charges for the time that a container is downloading, which is a double-whammy because not only do consumers have to wait for containers images to download that should have been cached, but also have to pay for this time! A pricing model similar to [CR](https://cloud.google.com/run/pricing#billable-time) would be more ideal.

* While EKS + Fargate could be used to self-host Knative + Itsio, the consumer would have the burden of configuring and managing this infrastructure, in addition to paying for its required compute resources (Knative + Itsio Fargate microVMs, as well as EKS control plane). The costs could be mitigated somewhat in many cases if Fargate supported options like #163, #79, and #751 to allow hosting containers with a lot of idle time in Fargate more cost-effectively.

**Are you currently working around this issue?**

Using EKS without Knative.

Contributor guide

Open the contributing guide

Research direction

No files or tests are identified. Start by reviewing the request and related issues #696, #163, #79, and #751, then define the scope for a managed Knative platform using EKS and Fargate; completion criteria would need to address scale-to-zero, startup time, pricing, and infrastructure management.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, kubernetes
Domain
cloud, devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.