#19 — First deploy Facade into Azure’s staging environment

Repo: Twill-AI/facade State: closed | Status: done Assignee: Unassigned

Created: 2024-06-17 · Updated: 2024-10-10

Description

To unblock UI from having real back-end to work with, we need be able to upload at least Facade service into some “staging” environment for showing demos and don’t make UI developers to spin up back-end service(s) locally.

Please look at https://app.diagrams.net/#G1RXbC0x8RzI9OXLBRnsObdNYk7ImZP1KY#%7B%22pageId%22%3A%22vyag1kLY_BlGWwEGG1LA%22%7D Eventually we would need in Facade and BusinessData services to be uploaded to some virtual network and be connected to LoadBalancer with public IP (with dedicated domain name, in production it would be twillpayments.com). Exactly this ID/domain should be used by UI which would be hosted as static website (HTML/CSS/JS files) in Azure Blob or Azure CDN.

Facade and BusinessData are expected to be scalable, i.e. run as multiple replicas. So we need to deploy them as Docker containers into some service which allows to scale pods (i.e. replicas) if theirs:

• average CPU
• average RAM
• (optional) HTTP or WebSocket response duration

usage is higher than some threshold we configured.

Kubernetes is a good solution for this but it is too heavy to manage. So idea is to use something smaller.

Also we need to automate process of deploying into “staging” environment from GitHub CI eventually.

But for now requirements are:

AC:

• Have a diagram of “staging” network to deploy Facade and BusinessData containers in Azure with LoadBalancer (some Azure service) which has public IP and domain name. This network should allow public access only from t

Notes

Add implementation notes, blockers, and context here

Related

Add wikilinks to related people, meetings, or other tickets