This page has been replicated to a publicly accessible website located here
| Status | |
|---|---|
| Overview | The purpose of this page is to outline some of the key information and connections that product teams should be made aware of as part of team inception. This is a living and collaborative document. Teams can use this page a reference point to assist in locating some key areas of information related to their application. If the information you are using does not exist here please review other guideline pages and/or contact the architecture team. |
NRM teams that work within our Development and Digital Services (DDS) branch start with a partnership agreement to ensure alignment between NRIDS and the program area.
NRM Digital Service Delivery Partnership Agreement
Before starting development, or when new team members begin contributing, ensure everyone on the team has the same understanding about coding practices, technology choices, and roles within your team. This is typically done during sprint 0.
Data is the enduring asset as part of any digital service in Government. Below are some recommended resources to get teams familiar with the data ecosystem within BC Government:
Open Data Policy increases government transparency and accountability through the public release of information, including data.
BC Data Catalogue is a resource for discovering thousands of datasets from across Government, and in some cases gaining access to the services themselves.
Core Metadata Standard defines the metadata elements that help make digital information easier to find, to improve services, and increase government’s efficiency
Gender and Sex Data Standard improves how government collects and uses data to serve B.C.'s diverse population.
Indigenous Languages Technology Standard: the BC Government is committed to including Indigenous languages in government records, systems and services. The BC Sans font is an open-source "living" typeface developed for government to improve the readability and delivery of digital services. It was designed to support special characters and syllabics found in Indigenous Languages in B.C. When designing and building your product, ensure it has the ability to collect, store, manage and display BC Sans characters. Connect with your architects for more details and references.
Working with Data is a developer focused guide around developing data solutions within BC Government.
Is your team replacing, re-architecting or re-platforming an existing application? If so, it's the Product Owner's responsibility to ensure the existing application is retired and the data is transitioned or preserved to ensure data quality, accuracy and currency as well as overall portfolio sustainability. Product Owners may reach out to their assigned Ministry Portfolio Manager (MPM) for assistance with the Application Retirement process.
Ensure you allocate time and budget in your backlog to manage the overall lifecycle of the business processes, data and associated products.
Helpful links on Application Retirement:
The BC Government has invested heavily in the Red Hat OpenShift platform to provide self service private cloud capabilities. Training is available through the exchange lab to get teams acquainted with the platform; a good primer is here.
https://developer.gov.bc.ca/ExchangeLab-Course:-OpenShift-101
The landing page for the private cloud service is here: https://cloud.gov.bc.ca/private-cloud/
Namespace provisioning can be found here: https://registry.developer.gov.bc.ca/public-landing
Information on resource tuning for OpenShift Namespaces can be found here: https://beta-docs.developer.gov.bc.ca/application-resource-tuning/
The RedHat learning portal is a great resource to learn more about the platform, and they also provide a sandbox to 'learn by doing'.
Some of the more important concepts to understand up front are:
Our friends and collaborators in Forestry Digital Services and the Architecture team have created an application template that includes pluggable API backends (Node/Nest, Python/FastAPI, Go/Fiber, Java/Quarkus) and frontend (React, Vite), with a deployment pipeline to the OpenShift platform with an option to include a PostgreSQL/PostGIS database and leveraging the backup container provided by the BC DevExchange. This is a great resource to get product teams up and running.
BC Government has endorsed several public cloud services and provides quickstart guides and sample applications!
Approved AWS services can be found here: https://developer.gov.bc.ca/AWS-Services
Source code should be stored in a GitHub repository in the "bcgov" tenancy.
Access management for the bcgov GitHub tenancy can be found here: https://just-ask.developer.gov.bc.ca/
NRM specific guidance on Github is here: Source Code Repositories
Most NRM digital products leverage the OCIO SSO service that is backed by Keycloak.
https://bcgov.github.io/sso-requests
The platform services team operates a Vault service.
It is described here: https://beta-docs.developer.gov.bc.ca/vault-secrets-management-service/
Access to the service is here: https://vault.developer.gov.bc.ca/ui/vault/auth?with=token
It's important that teams engage with the NRM Security and Privacy teams early and often. They can support you with general advice as well as Security Threat Risk Assessments (STRA's) and Privacy Impact Assessments (PIA's).
NRM Security Knowledge Base: NRM Information Security Home
NRM Privacy Knowledge Base: NRM Privacy Knowledge Base
OWASP (Open Web Application Security Project) is another great reference for security best practices for development teams: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content
The deployment pipeline is a key component for your application. For visibility, collaboration and maintainability modern teams are moving away from Jenkins towards GitHub actions.
It is strongly recommended that code be submitted using a Pull Request. Automated testing can and should replace manual UAT wherever practical.
NRM has a modern CI/CD template using GitHub Actions and HELM: OpenShift QuickStart targeted for OpenShift Silver or Gold Cluster.
NRM has a modern CI/CD template using GitHub Actions, HELM and Argo: OpenShift QuickStart Emerald targeted for OpenShift Emerald Cluster.
We recommend adopting an "API First" philosophy for application development, where teams both build and consume their API's. Providing API specification with proper metadata is mandatory irrespective of the underlying implementation(REST, graphql, grpc etc..)
Along with API first approach the Architecture team highly recommends looking at Domain Driven Design(DDD) where each micro-service API is bounded by its business domain(https://martinfowler.com/bliki/DomainDrivenDesign.html)
Also look at Event-Driven Architecture (Event Sourcing and CQRS) when building micro-services as it promotes highly decoupled APIS, communicating over an event streaming platform (https://microservices.io/patterns/data/event-sourcing.html, https://microservices.io/patterns/data/cqrs.html)
We recommend a Test Driven Development (TDD) approach to API development, as it makes the application code more reliable and efficient along with easier maintenance in the future.
There are several ways to name test methods/functions but we recommend using the pattern test<method_name>_<given_condition>_<expected_behavior>, it makes the tests more readable, predictable and becomes living documentation of the codebase.
BC Government has published a set of API Guidelines here: https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines
Information on the corporate API gateway can be found here: https://bcgov.github.io/aps-infra-platform/
Most of the teams working on OpenShift are choosing a flavor of PostgreSQL to persist data for their application.
Some points of consideration are:
For NRM guidance specific to data and database design, please visit this space: NRM Data and Database Development Guidelines
Database backups can be setup using the backup container image; information can be found here: https://developer.gov.bc.ca/Backup-Container
BC Government has an on premise object storage solution that delivers low cost storage for unstructured and semi-structured data. The service is billed monthly to the highwatermark of the storage your team consumes in their S3 bucket at $0.07/GB/Month. To get an S3 object storage bucket, contact the Optimize team.
COMS (Common Object Management Service) is an emerging common component that leverages the object storage solution. The advantage of this component is that it includes the ability to tag and add metadata, and integrates with BC Government's standard identity providers (IDIR, BCeID). To learn more, attend the Common Services Showcase team sprint reviews or contact the team via email.
An emerging companion to the Common Object Management Service being built by the Common Services team is BCBox, which is a hosted solution that uses the COMS API to allow users to upload, tag and share files using any OIDC compliant authentication mechanism. The code repository for BCBox can be found here.
General resources for Agile designers at Digital Government (BC Visual Identity, Official BC Design System, Web Style Guide, Content Design Guidance, UX Research Guidance, Service Design Playbook) can be found here:
https://digital.gov.bc.ca/resources#:~:text=Read%20the%20playbook-,For%20Designers,-B.C.%20Visual
Additional design system guidance: https://developer.gov.bc.ca/Design-System/About-the-Design-System
BC Parks has extended their Design Guide to include the use of the BC Sans font and other additions specific to their program:
https://bcgov.github.io/bcparks/design-guides
Many agile teams are using a flavor of Javascript framework for their front end development (Angular, Vue, React etc). We recommend you pick the framework that works best for the team, and if you are developing a suite of applications for your program area, harmonize across the suite where that makes sense. This will minimize risk associated with changes to the team and enable other developers to work with your code.
A comparison of web mapping frameworks in use in BC Government can found here: https://bcgov.github.io/bcwebmaps-options/
Similar to front end frameworks, we recommend you choose a development language that best suits the team and the business challenge you are working on. If you are developing a suite of applications for your program area, harmonize across the suite where that makes sense. This will minimize risk associated with changes to the team and enable other developers to work with your code.
There are many languages in use by agile teams across government, the most popular being Go, Python, Java, Javascript and Typescript. The Technology Radar is a great reference to see where the momentum is around languages and frameworks.
Information on NRM Web Domains can be found here: Web-Application domains
An example of a public facing URL is https://fom.nrs.gov.bc.ca/public/projects
Information on how to obtain an SSL certificate can be found here: Automation of TLS Certificates for Websites
Further information on security certificates can be found here: Security Certificates
Information on certbot can be found here: https://github.com/BCDevOps/certbot
BC Government has a selection of mature common components and common services.
Digital Government reference: https://digital.gov.bc.ca/common-components
NRM Specific Guidance: Common Components and Common Services
Many teams require reporting and analytics capabilities for their application data. Metabase is an easy-to-use open-source dashboarding and business intelligence tool that has broad usage in the NRM. Architecture has created a packaged install of Metabase tailored to teams wanting secure access to Zone B Oracle databases.
There are many teams working across the NRM and beyond. To connect with your NRM colleagues, see the team directory here NRIDS Development and Digital Services
The community uses Rocket.Chat to solicit help from other teams on all sorts of subjects. Users can authenticate with IDIR or their GitHub ID.
https://chat.developer.gov.bc.ca/
Channels of interest might include #general #devops-alerts #devops-operations #nr-iitd-agile-teams and any channel prefixed with "#nr-"
The NRM teams have a DevOps Guild to facilitate connections and collaboration between teams: https://apps.nrs.gov.bc.ca/int/confluence/display/DEVGUILD
You can also reach out to the NRM Architecture team, who can help connect your team with the right resources.
BC DevHub: https://developer.gov.bc.ca, https://docs.developer.gov.bc.ca/
Common Components: https://digital.gov.bc.ca/common-components
Communities of Practice: https://digital.gov.bc.ca/communities
BC Gov StackOverflow: https://stackoverflow.developer.gov.bc.ca/
Q. Do I need my application and data architecture to be formally approved?
A. No, there is no formal approval process for your architecture. We recommend collaborating with the architecture team during any architectural spikes or any significant architectural decisions. Our collective experience and connectedness across the community can typically provide value for the team.
Q. Do I have to use OpenShift to host my application?
A. No. We would generally like new applications to be running in a containerized or serverless hosting architecture. OpenShift is a strong option for teams starting out given the maturity of the platform and the surrounding community, as is the AWS Public Cloud Service, both operated by BC Government teams. Following cloud native design principles will help ensure that your application workload is portable between hosting platforms.
Q. Can I pass my application off to an ops team so the team can work on new apps?
A. We generally follow the "you build it, you run it" philosophy, and therefore recommend you build a sustainment plan into your application roadmap. Adhering as closely as possible to the 12 Factor principles is a great way to promote a sustainable, cloud native build.
This page has been replicated to a publicly accessible website located here
| Status | |
|---|---|
| Overview | The purpose of this page is to outline some of the key information and connections that product teams should be made aware of as part of team inception. This is a living and collaborative document. Teams can use this page a reference point to assist in locating some key areas of information related to their application. If the information you are using does not exist here please review other guideline pages and/or contact the architecture team. |
NRM teams that work within our Development and Digital Services (DDS) branch start with a partnership agreement to ensure alignment between NRIDS and the program area.
NRM Digital Service Delivery Partnership Agreement
Before starting development, or when new team members begin contributing, ensure everyone on the team has the same understanding about coding practices, technology choices, and roles within your team. This is typically done during sprint 0.
Data is the enduring asset as part of any digital service in Government. Below are some recommended resources to get teams familiar with the data ecosystem within BC Government:
Open Data Policy increases government transparency and accountability through the public release of information, including data.
BC Data Catalogue is a resource for discovering thousands of datasets from across Government, and in some cases gaining access to the services themselves.
Core Metadata Standard defines the metadata elements that help make digital information easier to find, to improve services, and increase government’s efficiency
Gender and Sex Data Standard improves how government collects and uses data to serve B.C.'s diverse population.
Indigenous Languages Technology Standard: the BC Government is committed to including Indigenous languages in government records, systems and services. The BC Sans font is an open-source "living" typeface developed for government to improve the readability and delivery of digital services. It was designed to support special characters and syllabics found in Indigenous Languages in B.C. When designing and building your product, ensure it has the ability to collect, store, manage and display BC Sans characters. Connect with your architects for more details and references.
Working with Data is a developer focused guide around developing data solutions within BC Government.
Is your team replacing, re-architecting or re-platforming an existing application? If so, it's the Product Owner's responsibility to ensure the existing application is retired and the data is transitioned or preserved to ensure data quality, accuracy and currency as well as overall portfolio sustainability. Product Owners may reach out to their assigned Ministry Portfolio Manager (MPM) for assistance with the Application Retirement process.
Ensure you allocate time and budget in your backlog to manage the overall lifecycle of the business processes, data and associated products.
Helpful links on Application Retirement:
The BC Government has invested heavily in the Red Hat OpenShift platform to provide self service private cloud capabilities. Training is available through the exchange lab to get teams acquainted with the platform; a good primer is here.
https://developer.gov.bc.ca/ExchangeLab-Course:-OpenShift-101
The landing page for the private cloud service is here: https://cloud.gov.bc.ca/private-cloud/
Namespace provisioning can be found here: https://registry.developer.gov.bc.ca/public-landing
Information on resource tuning for OpenShift Namespaces can be found here: https://beta-docs.developer.gov.bc.ca/application-resource-tuning/
The RedHat learning portal is a great resource to learn more about the platform, and they also provide a sandbox to 'learn by doing'.
Some of the more important concepts to understand up front are:
Our friends and collaborators in Forestry Digital Services and the Architecture team have created an application template that includes pluggable API backends (Node/Nest, Python/FastAPI, Go/Fiber, Java/Quarkus) and frontend (React, Vite), with a deployment pipeline to the OpenShift platform with an option to include a PostgreSQL/PostGIS database and leveraging the backup container provided by the BC DevExchange. This is a great resource to get product teams up and running.
BC Government has endorsed several public cloud services and provides quickstart guides and sample applications!
Approved AWS services can be found here: https://developer.gov.bc.ca/AWS-Services
Source code should be stored in a GitHub repository in the "bcgov" tenancy.
Access management for the bcgov GitHub tenancy can be found here: https://just-ask.developer.gov.bc.ca/
NRM specific guidance on Github is here: Source Code Repositories
Most NRM digital products leverage the OCIO SSO service that is backed by Keycloak.
https://bcgov.github.io/sso-requests
The platform services team operates a Vault service.
It is described here: https://beta-docs.developer.gov.bc.ca/vault-secrets-management-service/
Access to the service is here: https://vault.developer.gov.bc.ca/ui/vault/auth?with=token
It's important that teams engage with the NRM Security and Privacy teams early and often. They can support you with general advice as well as Security Threat Risk Assessments (STRA's) and Privacy Impact Assessments (PIA's).
NRM Security Knowledge Base: NRM Information Security Home
NRM Privacy Knowledge Base: NRM Privacy Knowledge Base
OWASP (Open Web Application Security Project) is another great reference for security best practices for development teams: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content
The deployment pipeline is a key component for your application. For visibility, collaboration and maintainability modern teams are moving away from Jenkins towards GitHub actions.
It is strongly recommended that code be submitted using a Pull Request. Automated testing can and should replace manual UAT wherever practical.
NRM has a modern CI/CD template using GitHub Actions and HELM: OpenShift QuickStart targeted for OpenShift Silver or Gold Cluster.
NRM has a modern CI/CD template using GitHub Actions, HELM and Argo: OpenShift QuickStart Emerald targeted for OpenShift Emerald Cluster.
We recommend adopting an "API First" philosophy for application development, where teams both build and consume their API's. Providing API specification with proper metadata is mandatory irrespective of the underlying implementation(REST, graphql, grpc etc..)
Along with API first approach the Architecture team highly recommends looking at Domain Driven Design(DDD) where each micro-service API is bounded by its business domain(https://martinfowler.com/bliki/DomainDrivenDesign.html)
Also look at Event-Driven Architecture (Event Sourcing and CQRS) when building micro-services as it promotes highly decoupled APIS, communicating over an event streaming platform (https://microservices.io/patterns/data/event-sourcing.html, https://microservices.io/patterns/data/cqrs.html)
We recommend a Test Driven Development (TDD) approach to API development, as it makes the application code more reliable and efficient along with easier maintenance in the future.
There are several ways to name test methods/functions but we recommend using the pattern test<method_name>_<given_condition>_<expected_behavior>, it makes the tests more readable, predictable and becomes living documentation of the codebase.
BC Government has published a set of API Guidelines here: https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines
Information on the corporate API gateway can be found here: https://bcgov.github.io/aps-infra-platform/
Most of the teams working on OpenShift are choosing a flavor of PostgreSQL to persist data for their application.
Some points of consideration are:
For NRM guidance specific to data and database design, please visit this space: NRM Data and Database Development Guidelines
Database backups can be setup using the backup container image; information can be found here: https://developer.gov.bc.ca/Backup-Container
BC Government has an on premise object storage solution that delivers low cost storage for unstructured and semi-structured data. The service is billed monthly to the highwatermark of the storage your team consumes in their S3 bucket at $0.07/GB/Month. To get an S3 object storage bucket, contact the Optimize team.
COMS (Common Object Management Service) is an emerging common component that leverages the object storage solution. The advantage of this component is that it includes the ability to tag and add metadata, and integrates with BC Government's standard identity providers (IDIR, BCeID). To learn more, attend the Common Services Showcase team sprint reviews or contact the team via email.
An emerging companion to the Common Object Management Service being built by the Common Services team is BCBox, which is a hosted solution that uses the COMS API to allow users to upload, tag and share files using any OIDC compliant authentication mechanism. The code repository for BCBox can be found here.
General resources for Agile designers at Digital Government (BC Visual Identity, Official BC Design System, Web Style Guide, Content Design Guidance, UX Research Guidance, Service Design Playbook) can be found here:
https://digital.gov.bc.ca/resources#:~:text=Read%20the%20playbook-,For%20Designers,-B.C.%20Visual
Additional design system guidance: https://developer.gov.bc.ca/Design-System/About-the-Design-System
BC Parks has extended their Design Guide to include the use of the BC Sans font and other additions specific to their program:
https://bcgov.github.io/bcparks/design-guides
Many agile teams are using a flavor of Javascript framework for their front end development (Angular, Vue, React etc). We recommend you pick the framework that works best for the team, and if you are developing a suite of applications for your program area, harmonize across the suite where that makes sense. This will minimize risk associated with changes to the team and enable other developers to work with your code.
A comparison of web mapping frameworks in use in BC Government can found here: https://bcgov.github.io/bcwebmaps-options/
Similar to front end frameworks, we recommend you choose a development language that best suits the team and the business challenge you are working on. If you are developing a suite of applications for your program area, harmonize across the suite where that makes sense. This will minimize risk associated with changes to the team and enable other developers to work with your code.
There are many languages in use by agile teams across government, the most popular being Go, Python, Java, Javascript and Typescript. The Technology Radar is a great reference to see where the momentum is around languages and frameworks.
Information on NRM Web Domains can be found here: Web-Application domains
An example of a public facing URL is https://fom.nrs.gov.bc.ca/public/projects
Information on how to obtain an SSL certificate can be found here: Automation of TLS Certificates for Websites
Further information on security certificates can be found here: Security Certificates
Information on certbot can be found here: https://github.com/BCDevOps/certbot
BC Government has a selection of mature common components and common services.
Digital Government reference: https://digital.gov.bc.ca/common-components
NRM Specific Guidance: Common Components and Common Services
Many teams require reporting and analytics capabilities for their application data. Metabase is an easy-to-use open-source dashboarding and business intelligence tool that has broad usage in the NRM. Architecture has created a packaged install of Metabase tailored to teams wanting secure access to Zone B Oracle databases.
There are many teams working across the NRM and beyond. To connect with your NRM colleagues, see the team directory here NRIDS Development and Digital Services
The community uses Rocket.Chat to solicit help from other teams on all sorts of subjects. Users can authenticate with IDIR or their GitHub ID.
https://chat.developer.gov.bc.ca/
Channels of interest might include #general #devops-alerts #devops-operations #nr-iitd-agile-teams and any channel prefixed with "#nr-"
The NRM teams have a DevOps Guild to facilitate connections and collaboration between teams: https://apps.nrs.gov.bc.ca/int/confluence/display/DEVGUILD
You can also reach out to the NRM Architecture team, who can help connect your team with the right resources.
BC DevHub: https://developer.gov.bc.ca, https://docs.developer.gov.bc.ca/
Common Components: https://digital.gov.bc.ca/common-components
Communities of Practice: https://digital.gov.bc.ca/communities
BC Gov StackOverflow: https://stackoverflow.developer.gov.bc.ca/
Q. Do I need my application and data architecture to be formally approved?
A. No, there is no formal approval process for your architecture. We recommend collaborating with the architecture team during any architectural spikes or any significant architectural decisions. Our collective experience and connectedness across the community can typically provide value for the team.
Q. Do I have to use OpenShift to host my application?
A. No. We would generally like new applications to be running in a containerized or serverless hosting architecture. OpenShift is a strong option for teams starting out given the maturity of the platform and the surrounding community, as is the AWS Public Cloud Service, both operated by BC Government teams. Following cloud native design principles will help ensure that your application workload is portable between hosting platforms.
Q. Can I pass my application off to an ops team so the team can work on new apps?
A. We generally follow the "you build it, you run it" philosophy, and therefore recommend you build a sustainment plan into your application roadmap. Adhering as closely as possible to the 12 Factor principles is a great way to promote a sustainable, cloud native build.
| Status | |
|---|---|
| Overview | This page is intended to provide a recommendation when developing custom applications on AWS |
| Status | |
|---|---|
| Overview | This page is intended to provide a recommendation when developing custom applications on AWS |
When developing a custom application on the AWS Platform, we recommend 1 of 2 baseline architectures. Containers over RDS, or Serverless (lambda) over NoSQL (DynamoDB).
For containers over RDS, QSOS has been adapted be deployed on AWS. Note: This is still a work in progress.
For serverless, there is currently no quickstart.
Note: The same principals apply when using the quickstart, we do not recommend deviating away from the baseline technologies in the repo.
https://github.com/bcgov/quickstart-aws-containers
| Status | |
|---|---|
| Overview | This page is intended to provide a recommendation when developing custom applications on OpenShift |
| Status | |
|---|---|
| Overview | This page is intended to provide a recommendation when developing custom applications on OpenShift |
When developing a custom application on the OpenShift Platform, we always recommend using the quick start OpenShift application (QSOS) . OCIO is currently creating a wizard from the QSOS to provide an easier onboarding experience. https://test.developer.gov.bc.ca/create
This repository has the recommend technologies within the repo. In general though we suggest using the below technologies. It is not recommended to deviate from the baseline technologies not in QSOS.
frontend - Vue.JS / React.JS
backend - Node.JS / Java
database - Postgres
https://github.com/bcgov/quickstart-openshift
| Status | |
|---|---|
| Overview | This page is intended to provide a high level overview of running an application in various environments and provide a basic understanding of the differences between application hosting environments. Please ask a member of our team to review this with you if you are discussing hosting options. |
The below options outline the 4 primary ways to host applications.
Note: Azure and Google are not mentioned below as the Province has not completed agreements with these providers, hence they are currently not recommended for use.
Overview: Running an application on-premise referred to a typical server (VM) hosted through OCIO and managed by the NRIDS Infrastructure Team for general server management.
Please not the below is not a representation about a specific application but a representation of what an on-premise application could be.
| Pros | Cons |
|---|---|
Network access to government services and applications within SPAN
| Difficult to deploy
|
Network access from government services and applications within SPAN
| Limited control over servers
|
Access to system databases
| Limited Tech Stack
|
Access to internal APIs
| Limited Scalability
|
When this might fit?
When this might not fit?
Overview: Running an application in Openshift (Silver/Gold/Emerald) with the platform managed by OCIO
Please note the below is not a representation about a specific application but a representation of what could be.
| Pros | Cons |
|---|---|
Control over deployment, patches, updates,
| Database stability
|
Supporting GitHub
| Database cluster complexity
|
When this might fit?
When this might not fit?
Note: For direct DB access to ZoneB databases Or Storing Protected C data, emerald cluster may be required
Overview: Running an application in BCGOV AWS tenancy owned by OCIO
Please note the below is not a representation about a specific application but a representation of what could be.
| Pros | Cons |
|---|---|
Scalability of resources
| Steep learning curve
|
Reduced IT management overhead
| Limited use for Data Types
|
Access to a breadth of services not available on premise | Little or no cost certainty
|
When this might fit?
When this might not fit?
Overview: A vendor run and managed application hosted outside government networks provided as a "service"
Please not the below is not a representation about a specific application but a representation of what could be.
Red Line: Firewall
Blue Line: SPAN network boarder
| Pros | Cons |
|---|---|
Less responsibility to maintain
| Vendor Managed
|
Vendor and Product lock in
| |
Limited use for Data Types
| |
Difficult to meet requirements of the Cloud Security Schedule and Cloud Privacy Schedule
|
When this might fit?
When this might not fit?
| Status | |
|---|---|
| Overview | This page is intended to provide a high level overview of running an application in various environments and provide a basic understanding of the differences between application hosting environments. Please ask a member of our team to review this with you if you are discussing hosting options. |
The below options outline the 4 primary ways to host applications.
Note: Google (GCP) is not mentioned below as it is not recommended for use.
Overview: Running an application on-premise referred to a typical server (VM) hosted through OCIO and managed by the NRIDS Infrastructure Team for general server management.
Please not the below is not a representation about a specific application but a representation of what an on-premise application could be.
| Pros | Cons |
|---|---|
Network access to government services and applications within SPAN
| Difficult to deploy
|
Network access from government services and applications within SPAN
| Limited control over servers
|
Access to system databases
| Limited Tech Stack
|
Access to internal APIs
| Limited Scalability
|
When this might fit?
When this might not fit?
Overview: Running an application in Openshift (Silver/Gold/Emerald) with the platform managed by OCIO
Please note the below is not a representation about a specific application but a representation of what could be.
| Pros | Cons |
|---|---|
Control over deployment, patches, updates,
| Database stability
|
Supporting GitHub
| Database cluster complexity
|
When this might fit?
When this might not fit?
Note: For direct DB access to ZoneB databases Or Storing Protected C data, emerald cluster may be required
Overview: Running an application in BCGOV AWS tenancy owned by OCIO
Please note the below is not a representation about a specific application but a representation of what could be.
| Pros | Cons |
|---|---|
Scalability of resources
| Steep learning curve
|
Reduced IT management overhead
| Limited use for Data Types
|
Access to a breadth of services not available on premise | Little or no cost certainty
|
When this might fit?
When this might not fit?
Overview: A vendor run and managed application hosted outside government networks provided as a "service"
Please not the below is not a representation about a specific application but a representation of what could be.
Red Line: Firewall
Blue Line: SPAN network boarder
| Pros | Cons |
|---|---|
Less responsibility to maintain
| Vendor Managed
|
Vendor and Product lock in
| |
Limited use for Data Types
| |
Difficult to meet requirements of the Cloud Security Schedule and Cloud Privacy Schedule
|
When this might fit?
When this might not fit?