System Architecture

Access to the ASSIST user interface is granted to users upon successful authentication internal mechanisms for Client, Contractor, or Support users and via the GSAuth for GSA users. Authentication directs users to the appropriate module landing page (be it CPRM or ASSIST). This methodology is a prevalent approach for the deployment of Angular and ReactJS single page applications.

Application traffic undergoes a process of routing through the application load balancer, where certification validation occurs. Subsequently, the traffic is directed to the network load balancer, which in turn dispatches the request to the corresponding EKS containers.

The core components of the ASSIST business system are architected within a Multi-tenant Container-as-a-Service (MCaaS) environment, an infrastructural service accessed through our collaborative engagements with the Federal Acquisition Services' Cloud Services (FCS). The technical underpinnings of MCaaS rely on the capabilities offered by Amazon Web Services' (AWS) Elastic Kubernetes Service (EKS).

Our system environments, namely, Development (DEV), Testing (TEST), Staging (STAGE), and Production (PROD), each operate within their respective EKS Clusters. This framework endows each environment with a distinct operational sphere, facilitating effective lifecycle management of each module from development to production.

The ASSIST data storage is composed of several distinct components, each operating in concert within the AWS environment to facilitate various functionalities:

1. Database: ASSIST utilizes AWS Aurora Serverless V2 as its primary database. This setup is bifurcated into 'writer' and 'reader' instances. The division allows us to direct read-only traffic to the reader instances. Applications that primarily request data, like BIRT reports and external interfaces such as Tableau and Business Objects Reports, engage with these reader instances.
2. File Storage: For long-term and reliable storage of files, ASSIST incorporates AWS Elastic File Service (EFS). This is particularly instrumental for interaction with the FSS-19 system.
3. Document Storage and Processing: ASSIST employs AWS S3 buckets for the storage and processing of documents and files. To ensure system security and integrity, these files undergo Clam AntiVirus scanning. This procedure aids in the early detection and mitigation of potential malware and viruses.

The Current System Architecture section, along with several other sections, illustrate how ASSIST leverages a suite of common components provided by Multi-tenant Container-as-a-Service (MCaaS):

1. AWS S3: ASSIST utilizes AWS S3 for reliable storage and retrieval. Specifically, an S3 bucket is allocated for storing ASSIST invoicing files, ensuring these files are safely kept and readily accessible.
2. ClamAV File Scanning Service: To maintain the integrity and safety of our stored files, ASSIST integrates the ClamAV file scanning service. This component scrutinizes files and categorizes them as clean, infected, or encrypted. In the event a file is detected to harbor a virus, access to the file is promptly inhibited, and the infected file can be permanently removed if necessary. The scanning process is initiated when a file is placed into a specified S3 bucket, triggered by an AWS Lambda function. Metadata about the scan result and timestamp are stored within the object's TagSet. This metadata is utilized by ASSIST to update our database and reflect the status of the uploaded file.
3. Flux CD: As part of ASSIST's CI/CD pipeline, Flux CD is incorporated. This tool serves as a Continuous Delivery solution, aimed at maintaining synchronicity between Kubernetes clusters and configuration source - Git repositories. It also automates the process of implementing configuration updates when they become available.
4. DataDog: Continuous monitoring and logging of ASSIST's services are facilitated through the integration of DataDog. All constituent elements of the ASSIST ecosystem, including its databases, incorporate logging and monitoring features facilitated via Datadog integration. Datadog is a robust cloud-scale monitoring service that allows for comprehensive observability of infrastructure and applications. Custom agents configured within the environments actively gather data from various sources such as pods, databases, and load balancers to maintain a constant stream of health check indicators. This data is relayed to Datadog, where it is processed, analyzed, and made readily available for operational and performance insights.

As described above, ASSIST is split into multiple applications that are deployed in the MCaaS environment. Each of these applications are deployed in separate containers running in the managed MCaaS environment. These applications provide one or more services in use by ASSIST. The breakdown of each of the applications and the services deployed in each are detailed in the diagram below.

The following diagram displays the high-level dependencies between ASSIST applications. The arrows indicate the dependency direction. This diagram displays dependencies at the application level between the user interface and the back-end applications. It also depicts dependencies at the service level. This diagram does not display any dependencies between ASSIST and its external interfaces. Each relationship is described in the provided Key. The Key numbers correspond to the numbers displayed on the association lines in the diagram. 

The ASSIST platform is characteristically designed to facilitate various external integrations with a range of disparate systems. These systems function in dual capacities—they either receive or provide information to/from the ASSIST platform. Communication processes between ASSIST and these systems utilize dedicated ports and protocols, all of which operate under the purview of formalized Interconnection Security Agreements (ISAs) that have been uniquely crafted for each system interface.

The succeeding diagram provides a visualization of this complex architecture. The box on the left encapsulates all communication channels directed towards ASSIST, including both application-level and database-level interactions.

Note: In addition to the information provided below, check out the ASSIST GFE Process whitepaper to learn about how ASSIST migrated the development process from contractor laptops to GSA Government Furnished Equipment (GFE) laptops to better leverage the FCS CI/CD pipeline.

The ASSIST CI/CD Pipeline is central to all development activities for the ASSIST program. All deployed applications within the ASSIST boundary are built using the MCaaS CI/CD Pipeline. The ASSIST Team manages multiple simultaneous release trains depending on technical and business priorities and timelines. ASSIST has established a CM process to manage the release trains starting with release naming as described below.

The CM process defines merge strategies to keep releases in sync; release strategies; and details how code is promoted through the ASSIST dev, test, stage, and production environments:

Upon beginning work on a story or defect, the ASSIST Team develops code within a feature branch specific to the functionality using a specific naming convention (feature/<issue ID>_<description>). Once a feature or defect is complete, tested, and committed, it is ready to be reviewed. A PR is created to merge from the feature branch to the appropriate release branch. Upon PR creation, Jenkins executes a preliminary build to ensure all unit tests and code quality gates pass in addition to ensuring the application and docker image successfully build. The PR is allowed to me merged only upon success of the PR build and two peer reviews and approvals. This in turn kicks off a release build for the application, performing the same checks as the PR build with an added Stackrox scan against the built image to detect any newly created security vulnerabilities.

A successful build against the release branch will yield a deployable application image, which the Jenkins build environment then tags and pushes to MCaaS ECR. The configuration of all deployments within the clusters is governed via Infrastructure-as-Code using Flux, controlled using GitOps practices. Changes to the Flux configuration follows the same process as the application repositories: all configuration and image tag changes to the clusters require a pull request to the assist-flux-config repository with two peer reviews and approvals. With the image policy mechanism provided by Flux v2, the DevOps team will ensure the latest image tags for a given release are automatically deployed to the designated Dev and Test environments the moment they become available.

A release if deployed to Staging via manual promotion of the release image tags for each application. Deployment to Production follows a similar procedure, with the addition of a separate git repository - assist-prod-flux-config - for production Flux configurations.