pulumi-cloud
pulumi-cloud copied to clipboard
pulumi
Figure out if we can provide any sort of minimal/simple orchestration for Azure's cloud.Service
AWS ECS natively provides simple ways to define a simple orchestration strategy using the 'REPLICA' property: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html#service_scheduler
This allows one to specify the number of instances to have, and has them spread over availability zones for high availability. Azure seems to lack any such native support at their container level. Instead, you need to bump up to a much higher layer of complexity with either Container-Services, Kubernetes-Services, or Traffic-Manager. We should try to figure out if we can still support this concept on Azure, while hiding all this complexity from teh user.
The key feature we need here is a single stable DNS name (either external or internal to the deployed application cluster) that distributes traffic to all replicas.
On AWS today, we use LoadBalancers for both internal and external endpoints. We plan to move to using service discovery based on internal DNS for internal endpoints - see https://github.com/pulumi/pulumi-cloud/issues/441.
On Azure, I believe Traffic Manager offers a simple solution for getting a stable DNS name that distributes traffic across a fixed set of hosts. This would provide a simple solution for the core problem here, and allow supporting arbitrary fixed numbers of replicas. I'd suggest we integrate that now to get to general parity on support for replicas != 1.
We will need to re-review overall load balancing strategy and the internal/external split that currently exists - it's not clear we can support these notions in a fully cross-cloud way - or if we can, they may require more significant changes to our implementation (perhaps we will require a full Kubernetes cluster under the hood instead of ACI?).
@lukehoban Thanks for the clarification. That makes me significantly more optimistic about reasonable approaches we can take here.