System Architecture
Explore FSS19 Phase 3 Modernization’s cloud architecture approach. FSS19 Phase 3 Modernization is implementing an architecture to support mission-critical functionality as the application is modernized over two production deployments.
Product/Technology Features
The technical architectural approach for the FSS19 Phase 3 Modernization applications is oriented towards the twin goals of expediting migration from the mainframe to the cloud and establishing the foundation for a cloud-native approach for future iterative development. The implementation is guided by the principles of aligning to GSA enterprise architecture, leveraging managed cloud services and GSA shared services where possible, following a containerization approach to facilitate resiliency, and fully automating the continuous release of all application deliverables.
The team outlined several features needed at the start of the FSS19 Phase 3 Modernization project, including: SSO Login/SecureAuth Integration, Okta, Caching Solution (e.g., Elasticache), Microservice Management, Independent Data Layer Management, S3, and RDS. FSS19 Phase 3 Modernization takes advantage of the FCS MCaaS platform which provides managed services oriented around containerization of workloads in Amazon EKS. This allows the FSS19 Phase 3 Modernization team to focus on the business value of the applications being migrated and inherit security, deployment, and hosting services managed by FCS. MCaaS tenants are provisioned for each environment, Dev, Test, and Production, with pre-deployed and configured services like Helm, Istio, and Flux that support deployments and traffic routing within the cluster and pipeline services like Github, Jenkins, ECR and Sonarqube. Other GSA enterprise cloud services outside MCaaS are employed for networking, DNS, load balancing, API management, and reporting and analytics.
Application Requirements
At the outset, the FSS19 Phase 3 Modernization team identified several key performance (e.g., uptime, accessible instances, asynchronous processing, page load expectations) and non-functional (e.g., data integrity/replication, modular new applications, security secrets, file transfer capability, notification capability) requirements when beginning the intake process with FCS MCaaS. Security requirements were also identified at the outset, including around encryption of sensitive data in transit and at rest, logging/monitoring/notification, log access, data retention, and data access.
Data Requirements
All systems in scope still rely on data currently housed on the Unisys Clearpath Mainframe in the DMSII database. There is one set of PIID tables (6 tables) that are in an on-prem Sybase database in the GSA Data Center. Once the FSS19 Phase 3 Modernization project is complete, all systems will rely on data housed on the GSA MCaaS cloud environment in a new MySQL database. The graphic below outlines reference architecture for the data migration for Mass Mods and Contracting Services.
Tables used by the applications will be migrated to the Cloud. An initial full load [Bulk Data Transfer (BDT)] will be performed followed by ongoing replication [Change Data Capture (CDC)].
Below are the detailed requirements:
- Perform an initial full load [Bulk Data Transfer (BDT)] for all tables followed by ongoing replication [Change Data Capture (CDC)]. The CDC is needed until such time that FSSOnline is also migrated to the cloud.
- Migrate the data as-is; there will be no transformation. Perform a one-time extraction for 6 tables from Sybase FSSOnline DB from GSA Data Center and load into MySQL DB. This will be handled by the application team.
- Load ongoing changes in Sales data from SRP Database into MySQL DB on a 3 times/week cadence via an API. Due to the volume of data, only the deltas are needed.
- Implement writeback on selective tables into legacy database using API. Ensure connectivity for API exchange from the MCaas environment. The API will be needed to sync data back as FSSOnline and other systems will need some of the cloud created data to continue functioning. At the end of Step 2, the API will no longer be used as all the relevant systems will be migrated. The team estimates less than 30,000 daily records that will need writebacks.
Cloud Dependencies
Key cloud dependencies include:
- ALB with Session Affinity
- Elasticache
- Access to infrastructure in lower environments
- Access to logs in all environments
- Monitoring and Notification Capabilities
- Simple Queue Service
- Simple Notification Service
- RDS (mySQL), DynamoDB/MongoDB Atlas/DocumentDB, Redshift*
- S3
- Redshift - Data Warehousing
Integrations
The FSS19 Phase 3 Modernization systems are highly integrated with other internal and external applications in the FSS19 ecosystem. The goal is to have a seamless transition of all the interfaces to the applications on the cloud:
Dependency Name | Details |
---|---|
OCMS | Interfacing application part of contract management lifecycle (post-award) |
SWS | Interfacing application part of contract management lifecycle (pre-award) |
ORS | Interfacing application part of contract management lifecycle (pre-award) |
eMod/eOffer | Interfacing application part of contract management lifecycle (post-award) |
ECMS | Support Service |
API Exchange | Support Service |
Okta | External vendor; Mass Mods users are authenticated through Okta SSO |
SecureAuth | External Vendor |
Vendor Support Center | Downstream System |
FPDS-NG | Downstream System |
CALM | Downstream System |
Advantage | Downstream system (PIID only) |
eLibrary | Downstream system (contract data) |
ROADS | Downstream system (contract data) |
SAM.gov | EPLS |