How Voyatek’s child support solution Thrive implements granular control of container deployments

In modern cloud environments, organizations need efficient ways to manage and deploy multiple microservices while maintaining individual service autonomy and deployment flexibility. This is particularly important for complex solutions like child support systems that require both reliability and agility in their deployment processes.

Voyatek offers an open-source, cloud-based child support solution that leverages a microservices architecture powered by Amazon Web Services (AWS). Thrive is a cloud-native platform packed with purpose-built features and automation to empower child support agencies as they help families succeed. The solution comprises multiple independent services, each handling specific business functions, with separate user interface portals for different stakeholder groups. By design, each service can be deployed, scaled, and maintained independently, while still allowing for secure inter-service communication where needed. This architecture provides agencies with the flexibility to update individual components without disrupting the entire system.

The solution also provides flexibility in source control management allowing any enterprise Git provider of choice (such as GitHub, GitLab, or Bitbucket). The backend business services are maintained as distinct projects within a single repository for simplified governance, while shared resources and user interface code for the different user portals (agency staff, customers, and employers) are all maintained in separate git repositories. Both source control management approaches support independent development and deploy cycles.

Solution overview

This architecture allows DevOps teams to efficiently manage multiple microservices while maintaining independent deployment pipelines for each service. By implementing service-specific deployment processes, organizations can achieve the following operational advantages:

Independent deployments: Deploy individual services without affecting other components, enabling rapid iterations and reducing deployment risk
Dynamic scaling: Scale services based on specific performance needs and usage patterns
Separate development cycles: Maintain independent development and deployment cycles for all application components allowing teams to work at their own pace, control the impact of change, and isolate regression testing needs
Targeted monitoring: Implement focused monitoring and alerts for each service, improving incident response and system visibility
Efficient resource management: Manage shared resources while preserving service autonomy and cost optimization

The flexible source control approach further enhances organizational capabilities by allowing agencies to use their preferred Git provider while maintaining consistent deployment processes. This protects existing enterprise source control investments and enables organizations to scale their deployment management effectively across multiple teams.

This overall approach enables rapid iterations and targeted testing for specific service updates, reducing deployment risk while maintaining system stability. The architecture combines the benefits of microservices with modern DevOps practices, providing both flexibility and reliability.

Architecture

The solution architecture comprises of several key components that work together to deliver a scalable and maintainable microservices-based system.

Figure 1: Architectural diagram showing the deployment pipeline for Voyatek’s child support solution

The key components include:

Frontend Delivery and Build Pipeline

Frontend code is maintained in dedicated repositories
Frontend Pipeline builds and deploys directly to Amazon Simple Storage Service (Amazon S3)
Amazon CloudFront provides global content delivery and caching

Backend Services and Container Management

Amazon API Gateway for REST API management and routing
VPC Link connecting Amazon API Gateway to internal services
Network Load Balancer (NLB) and Application Load Balancer (ALB) for traffic distribution
Amazon Elastic Container Registry (Amazon ECR) for storing container images
- Enables version control of container images
- Supports rollback capabilities
- Maintains deployment history

Microservices Layer (Amazon ECS)

Multiple distinct containerized services handle different aspects of the child support system, some of which are as follows:

Case Intake Service: Handles new case submissions and initial processing
Utilities Services: Provides shared management of regions, offices, teams, users, and worker tasks across the system
Case Management Service: Manages ongoing case operations and updates
Establishment Service: Handles legal processing and the establishment of monetary and medical support orders
Collections Service: Processes payments and distributes money across account balances

Pipeline Notifications and Monitoring

AWS CodeStar (also known as AWS CodeConnections) Notifications for pipeline events
Integration with Amazon Simple Notification Service (Amazon SNS) for notification delivery
Email notifications for pipeline status changes including:
- Pipeline execution start
- Successful completion
- Failure alerts
- Manual approval requirements

The integration of these components creates a robust continuous integration and continuous delivery (CI/CD) system that delivers key capabilities for modern microservices management. Individual components work together to provide granular control over module deployments, reliable container management, detailed monitoring, and immediate status notifications. This architecture handles complex microservices structures while maintaining deployment independence for each module and flexibility in source control choices.

Implementation

To implement this solution, you’ll configure several key components. The following steps provide a detailed walkthrough:

Step 1: Configure Pipeline Mapping

The system uses a module-to-pipeline mapping to determine which pipeline should be triggered based on code changes:

python
# Define file paths and corresponding pipeline names
file_path_pipeline_map = {
  'cs/Support/CSLiveSupportSrv/Collections/': 'voyatek-cse-service-deploy-Collections-Pipeline',
  'cs/Support/CSLiveSupportSrv/Utilities/': 'voyatek-cse-service-deploy-Utilities-Pipeline',
  'cs/Support/CSLiveSupportSrv/Case-Intake/': 'voyatek-cse-service-deploy-Case-Intake-Pipeline',
  'cs/Support/CSLiveSupportSrv/Case-Management/': 'voyatek-cse-service-deploy-Case-Management-Pipeline'
}

The system compares (git diff) the latest commit against the last commit when the pipeline was executed. The last commit information is stored in Amazon DynamoDB for persistence and quick retrieval.

Step 2: Configure Individual Pipelines

Each module has its dedicated pipeline defined in Terraform, as shown below:

``terraform
# Pipeline definition with source and build stages
resource "aws_codepipeline" "module_pipeline" {
  name     = "${var.module_name}-pipeline"
  role_arn = aws_iam_role.codepipeline_role.arn	

  artifact_store {
    location = aws_s3_bucket.artifact_bucket.bucket
    type     = "S3"
  }
  stage {
    name = "Source"
    
    action {
      name             = "Source"
      category         = "Source"
      owner            = "AWS"
      provider         = "CodeCommit"
      version          = "1"
      output_artifacts = ["source_output"]
      
      configuration = {
        RepositoryName = var.repository_name
        BranchName    = var.branch_name
      }
    }
  }
  stage {
    name = "Build"
    action {
      name            = "Build"
      category        = "Build"
      owner           = "AWS"
      provider        = "CodeBuild"
      version         = "1"
      input_artifacts = ["source_output"]
      
      configuration = {
        ProjectName = aws_codebuild_project.module_build.name
      }
    }
  }
}
# Build project configuration
resource "aws_codebuild_project" "module_build" {
  name          = "${var.module_name}-build"
  description   = "Build project for ${var.module_name}"
  service_role  = aws_iam_role.codebuild_role.arn

  artifacts {
    type = "CODEPIPELINE"
  }
  environment {
    compute_type                = "BUILD_GENERAL1_SMALL"
    image                      = "aws/codebuild/standard:5.0"
    type                       = "LINUX_CONTAINER"
    image_pull_credentials_type = "CODEBUILD"
    
    environment_variable {
      name  = "MODULE_NAME"
      value = var.module_name
    }
  }
  source {
    type      = "CODEPIPELINE"
    buildspec = "buildspec.yml"
  }
}

# Build trigger configuration
resource "aws_cloudwatch_event_rule" "pipeline_trigger" {
  name        = "${var.module_name}-pipeline-trigger"
  description = "Trigger pipeline on repository changes"

  event_pattern = jsonencode({
    source      = ["aws.codecommit"]
    detail-type = ["CodeCommit Repository State Change"]
    resources   = [aws_codecommit_repository.module_repo.arn]
    detail = {
      referenceType = ["branch"]
      referenceName = [var.branch_name]
    }
  })
}``

Step 3: Build Process Configuration

The build process requires careful orchestration to handle dependencies and provide consistent deployments. Here’s the buildspec configuration:

version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 18
    commands:
        npm install
  pre_build:
    commands:
        npm run test
  build:
    commands:
        npm run build
        aws s3 sync ./dist s3://${ARTIFACT_BUCKET}/${MODULE_NAME}/
artifacts:
  files:
    * '*/'
  base-directory: 'dist'

This buildspec configuration addresses several key requirements:

Dependency handling: The npm install step makes sure that all required dependencies are properly installed.
Artifact management: The build artifacts are synchronized to an Amazon Simple Storage Service (Amazon S3) bucket using a module-specific path structure, allowing for:
- Clear separation between module artifacts
- Easy rollback capabilities
- Efficient updates to the front-end content
- Amazon CloudFront cache invalidation after the build

Step 4: Container Management and Version Control

The solution leverages Amazon ECR for comprehensive container management. Amazon ECR provides secure storage of container images, version tracking of deployments, and support for rollback operations, and maintains deployment history for audit purposes. Each microservice’s container image follows a strategic tagging approach that includes the build version for sequential tracking, the Git commit hash for traceability, and a timestamp for chronological ordering.

This tagging strategy enables precise tracking of deployments, quick identification of problematic versions, the ability to roll back to any previous version, and maintains a comprehensive audit trail for compliance and troubleshooting purposes.

Step 5: Pipeline Notification Configuration

The solution implements pipeline notifications using AWS CodeStar Notifications and Amazon Simple Notification Service (Amazon SNS):

```terraform
# SNS Topic Configuration
resource "aws_sns_topic" "pipeline_notifications" {
  name = "${var.project_name}-${var.environment_name}-pipeline-notifications"
}

# Email Subscription Configuration
resource "aws_sns_topic_subscription" "pipeline_notification_subscription" {
  count     = var.pipeline_notification_endpoint != "" ? 1 : 0
  topic_arn = aws_sns_topic.pipeline_notifications.arn
  protocol  = "email"
  endpoint  = var.pipeline_notification_endpoint
}

# Notification Rule Configuration
resource "aws_codestarnotifications_notification_rule" "this" {
  detail_type    = "BASIC"
  event_type_ids = [
    "codepipeline-pipeline-pipeline-execution-succeeded",
    "codepipeline-pipeline-pipeline-execution-failed",
    "codepipeline-pipeline-manual-approval-needed",
    "codepipeline-pipeline-pipeline-execution-started"
  ]
  name     = "${local.name_prefix}-pipeline-notifications"
  resource = aws_codepipeline.this.arn
  target {
    address = var.notifications_topic_arn
  }
}

For monitoring and third-party messaging service integration, the following configuration uses pipeline notifications and Amazon Simple Notification Service (Amazon SNS) for direct integration:

``terraform
resource "aws_cloudwatch_alarm" "deployment_status_alarm" {
  alarm_name          = "${var.module_name}-deployment-status"
  metric_name         = "DeploymentStatus"
  namespace           = "AWS/CodePipeline"
  statistic           = "Average"
  period              = 60
  evaluation_periods  = 1
  threshold           = 1
  comparison_operator = "GreaterThanThreshold"

  alarm_actions = [
    aws_sns_topic.deployment_notifications.arn
  ]
}

resource "aws_sns_topic" "deployment_notifications" {
  name = "${var.module_name}-deployment-notifications"

  subscription {
    protocol = "https"
    endpoint = "<<https://hooks.example.com/incoming/your-messaging-service-webhook>>"
  }
}``

Conclusion

This solution provides granular control over container deployments while maintaining simplicity and reliability. The integration with third-party messaging services provides immediate visibility into deployment status, enabling quick response to issues.

The combination of AWS services, Infrastructure as Code practices, and modern DevOps methodologies creates a robust platform for managing complex government solutions while maintaining the security and reliability requirements necessary for child support systems.

Next steps

This deployment architecture has established a solid foundation for microservices management. To continue exploring advanced DevOps practices, consider these AWS resources and enhancement opportunities:

Blue/Green Deployments:

Infrastructure as Code:

Monitoring and Observability:

Security and Compliance:

AWS Public Sector Blog