Architecture
- Oleksii Danyliuk
- jarkkohyoty
Terms and definitions
Term | Explanation |
|---|---|
GovStack Instance | A set of applications that implement the building block specifications, including necessary configuration and data, deployed in the Sandbox execution environment. Always includes the Information Mediator building block. |
Sandbox hosting environment
A public cloud providing the resources for hosting the Sandbox (AWS, EKS)
Integration and configuration pipelines
Implemented only for emulated components
Takes applications complying to GovStack BB specs as input and outputs "sandboxed" building block variants. Most of the time the input should be a OCI container image. The output is a prepared container images "packaged" as helm charts. As much as possible, configuration should be done ahead of time so that deployment becomes easier and can be done on-demand.
Deployment engine
Not implemented
Takes a GovStack instance specification (list of required building blocks variants) and assembles a GovStack instance. That is, provisions resources, installs apps and applies the necessary configuration. The govtstack instance could be realized e.g in Kubernetes (if it is "mininal", one could even run it on their own machine using microk8s or minikube or similar).
The "applies the necessary configuration" is likely a component of its own right, because it e.g. generates the synthetic date (unless the software factory preparation step can already do parts of it).
Sandbox execution environment
About the Govstack execution environment
Sandbox portal
Only partially implemented
About reproducing the sandbox
The whole solution quite complex, so reproducing it in full is also challenging. However, it strives to be modular:
"As a government services developer, I can take the artifacts produced by the CI/CD pipelines and set up the a Govstack instance on my own environment”.
Container images
Helm charts
Deployed on a local execution environment (e.g. microk8s)
"As a goverment IT department, I can take the sandbox specifications and adapt and implement it in my own environment"
Terraform configuration for SandBox infrastructure
Pipeline configuration for producing the deployment artifacts
Assumptions and limitations
The following two assumptions are derived from the building block design design principles, which state that the building blocks should be cloud native.
This architecture assumes that the building block applications are headless and can be operated via APIs only. That is, “looking into” the building blocks running within a GovStack instance and accessing the (possible) user interfaces of the various components is out of scope of this design.
This assumption was mostly incorrect, most real building block implementations having own admin user interfaces.
It is also assumed that the automated deployment and configuration of a building block application is possible (preferably via APIs, or at least it should be possible to manually create a pre-configured image of an application for deployment purposes).
While automated deployment is likely possible, this goal has not been reached and requires considerable amount of work.
Limitation: There is no defined way for a third party developer to directly access the GovStack instance. The current solution is to deploy a GovStack instance on ones own environment, which is supported by publishing the necessary setup scripts, descriptions and configurations. However, such a deployment might not have access to building blocks that are not automatically deployable (because a container image and e.g. Helm chart for those does not exist as such applications are represented by a gateway component and/or a mock).