Hi Markus,
thinking about scalability and the edge case. When there are not enough containers and new controllers are being created, and all of them redirect traffic to the controllers with containers, doesn't it mean overloading the available containers a lot? I'm curious how we throttle the traffic in this case.

I guess the other approach would be to block creating new controllers when there are no containers available as long as we don't want to overload the existing containers. And keep the overflowing workload in Kafka as well.

Thanks,
Martin Gencur
QE, Red Hat

On 13.7.2018 19:29, Markus Thoemmes wrote:
Hello OpenWhiskers,

I just published a proposal on a potential future architecture for OpenWhisk 
that aligns deployments with and without an underlying container orchestrator 
like Mesos or Kubernetes. It also incooperates some of the proposals that are 
already out there and tries to give a holistic view of where we want OpenWhisk 
to go to in the near future. It's designed to keep the APIs stable but is very 
invasive in its changes under the hood.

This proposal is the outcome of a lot of discussions with fellow colleagues and 
community members. It is based on experience with the problems the current 
architecture has. Moreover it aims to remove friction with the deployment 
topologies on top of a container orchestrator.

Feedback is very very very welcome! The proposal has some gaps and generally 
does not go into much detail implementationwise. I'd love to see all those gaps 
filled by the community!

Find the proposal here: 
https://cwiki.apache.org/confluence/display/OPENWHISK/OpenWhisk+future+architecture

Cheers,
Markus


Reply via email to