Issues related to the implementation of Building Blocks and the Information Mediator within a Kubernetes cluster.

Owned by Satyajit Suri
Last updated: Jul 19, 2023
3 min read

Background - This note is prepared as background information for discussion on approach for creating BB instances in the Sandbox and alignment with IM BB structure within a Kubernetes cluster. The issues first came up for discussion during the BB<>Sandbox meeting on July 18th. Link to the meeting discussion - July 18, 2023 - Alignment Meeting # 14 - GovStack - GovStack Wiki (atlassian.net)

 

Target audience - Architecture Team (@Satyajit Suri @Aare Laponin @Jukka Aaltonen (Deactivated) @Nico Lueck @PSRAMKUMAR @Steve Conrad @Wes Brown) @Vasil Kolev @Meelis Zujev (Deactivated) @Aleksander Reitsakas @Vikash Madduri @Allan Bernard

 

Key points that need to be further discussed and clarified in the Architecture Team/ Technical Committee:

  1. Instances of Building Blocks: One of the main points of confusion is about instances of Building Blocks and their placement within applications and organizations (members). As Building Blocks are pieces of software providing specific services they can be deployed as instances within different applications. The concern is that each Building Block instance needs to be at the same level as the application (Level 3 from member applications). This suggests that if there are multiple applications within an organization, there should be corresponding instances of Building Blocks to support them. Key questions: Should there be one instance of a Building Block at Level 3 from member applications or if there could be multiple instances in different places? What is the optimal placement and number of instances for Building Blocks within applications and organizations to ensure efficient communication and service provision?

  2. Applications and Building Blocks: There is a need to clarify the relationship between applications and Building Blocks. Building Blocks are essentially applications themselves, and the Information Mediator treats them as pieces of software running and providing specific services. The Information Mediator acts as a gateway facilitating communication between these applications/ Building Blocks.

  3. Sandbox Structure and Deployment: There needs to be clarity on the structure of the Sandbox and its connectivity to Building Blocks. The current setup involves a single network for all Building Blocks, but there's a suggestion that scenarios might need separate networks. There is a possibility of one scenario spanning multiple organizations, the setup and deployment of which needs to be clarified and discussed. There is a need to clarify the difference between application level and the sandbox structure. The sandbox is said to contain different numbers and applications, indicating a complex network setup. Key Question: How should Building Blocks be deployed and connected within the Sandbox?

  4. Organization and Kubernetes Cluster: There is a need to clarify the concept of "organization" in the context of the Kubernetes cluster. In terms of the Information Mediator, it is clarified that "organization" refers to a member of GovStack. Organizations are like virtual closed networks, and the Information Mediator serves as a gateway between these networks. Key Question: How does the concept of organization within the Kubernetes cluster relate to the Information Mediator and the deployment of Building Blocks?

  5. Multiple Instances and Scenarios: The issue of multiple instances of building blocks for different scenarios and organizations has also been raised. It is suggested to have separate instances for different organizations when needed. However, the specific setup and deployment for these scenarios are not entirely clear. Key Questions: How can the Sandbox architecture support scenarios that span multiple organizations while maintaining isolated configurations for each scenario? How should the sandbox structure be organized to accommodate multiple instances of Building Blocks, applications, and Information Mediator in an architecturally correct manner?

 

Immediate Next Steps: Given the tight implementation timelines of the BB providers and the Sandbox, the importance of resolving these issues urgently is stressed. It is necessary to discuss the above issues in the Technical Committee/ Architecture Group for alignment of the Sandbox structure and Information Mediator as per GovStack’s requirements.

@PSRAMKUMAR – Request you to lead the discussion and call for the meeting with the relevant stakeholders (Architecture group, Sandbox, BB Providers)

@Vasil Kolev – Request you to provide the necessary documentation regarding the proposed Sandbox structure.