| Info |
|---|
Background information |
The "Govstack execution environment" is an environment for running a Govstack instance, a set of building block applications connected using the "information mediator BB" (X-Road).
...
The workloads (building block applications) are going to be stateful applications, requiring databases and file storage. Fargate nodes do not support EBS volumes, only EFS which is a network file system. This means that running databases within the cluster becomes problematic since a network file system semantics (and properties like latency) are not really suitable for database storage. Same might be true for services requiring file storage with semantics a network file system does not provide on a sufficient level (atomic operations, durability guarantees, locks, etc.).
One possible workaround for the database issue is to use ACK RDS controller which makes it possible to provision RDS databases using Kubernetes. If a workload requires a database that RDS does not support, we need to provide some other workaround.
Applications likely have user interfaces. While it is possible to expose those somehow (but there are the obvious challenges like how to handle authentication), we have worked on an assumption that applications are headless and can be operated and configured through APIs.
Kubernetes in general (and Fargate specifically) more or less only supports Linux-based workloads. Windows containers exist, but those also have restrictions (e.g. no EFS volume support).
On EKS Fargate, EFS driver does not (yet) support dynamic volume provisioning. This means that creating (or removing) the EFS volumes (access points) can not be easily done from Kubernetes, complicating deployment
Our current tradeoff is to use AWS EKS with managed node groups – Fargate has too many restriction that would likely require modifying the existing workloads, and would make the execution environment more AWS specific. Auto-scaling the node groups is not yet solved, but solutions for that exist (e.g. Karperter).
The current choice of execution environment also creates some constraints for building blocks that can be deployed into that environment. For example:
Is the building block already available as one or more OCI (Docker) container.
Is it designed to operate in a cloud environment (or specifically a Kubernetes cluster)
Is it packaged as a Helm chart for easy deployment
The Helm chart should be modular and allow selecting a minimal core setup with essential functionality only.
Does the building block require databases. Which one?
Related, does the building block require some caching layer (memcached, redis, ...).
If it does, does the cache expect a durable cache with file storage.
What are the compute resource requirements (memory, CPU, ...)
Are there requirements for persistent file storage?
Are there some special requirements (e.g. the building block itself is deployed as a Kubernetes cluster), needs access to some special hardware (GPU, ...)
...