SaaS Boost Extension Development Specification

[goodbyedavid]

Hi Team, I created this doc as reference for extension development, would like to get some feedback of it.

---

SaaS Boost Extension Development Specifications

The Need

AWS SaaS Boost provides organizations with ready-to-use core software elements for successfully running SaaS workloads in the cloud. Software builders can focus on preserving core intellectual property by removing the complexities of building SaaS solutions using AWS SaaS Boost.

Get a boost with tenant management, deployment automation, analytics dashboards, billing and metering, an administrative web interface, and more. This environment reduces development and experimentation time, allowing you to get your software into the hands of customers faster.

SaaS Boost is under active development, one of the focus areas is extension development, currently File Systems, Database and Billing are being supported. Noticeably, a lot of preferred services/applications are not supported by SaaS Boost yet, hence preventing clients and customers to migrate to a silo SaaS model using SaaS Boost.

Extensions are conditional nested CloudFormation stacks. When provision a tenant, each extention will be used as blueprint for needed cloud resources.

This document lists the specifications of extension development for SaaS Boost.

Specifications

1. UI

Update Admin Web UI to capture extension configuration.
Code location: /aws-saas-boost/client/web.

When you set up an application with extension, you might still want to pass some configuration settings. For example, for a free tier tenant, a t3.nano ec2 instance could be good enough for some experimental activities. But for an enterprise level tenant, a m6g.4xlarge might be the right choice. We need a way to define our configurations, and pass the information from the frontend to the backend. You can check the UI code for File Systems, Database and Billing for the insight of how in React this is being set.

This can be broken down into 3 layers.

• Subforms
• Components
• Containers

In subforms, a panel will be defined to represent the new extension. Text input box, dropdowns and other input forms can be used to capture the user preferred parameter settings. This subform is then imbedded into the application component which helps setting the default values and card locations. Application container takes care of the marshall and unmarshall the data values from the forms and invokes the backend apis.

When you create new UI components, you can utilize the following script to load the code rather than go through the whole SaaS Boost install scripting process.

./build_webapp.sh ${env} ${region}
./copy_to_web.sh ${env} ${region}

2. MicroServices

Two of the micro services we need to enhance for the extension development are Settings service and Onboarding service. Settings service models extension and parameters. Onboarding service passes parameters from SSM parameter store during the onboarding process.
Code location:
/aws-saas-boost/services/settings-service
/aws-saas-boost/services/onboarding-service

Update Settings service to model extension and parameters
A new class representing your extension model should be created under
/aws-saas-boost/services/settings-service/src/main/java/com/amazon/aws/partners/saasfactory/saasboost/.
This class uses builder pattern for class definition, BillingProvider.java and Database.java can be referred as examples of how to set up a new class.

AppConfig is the class representive of the domain object that gets filled out by the web form application setting page. The new extension model will be referrenced in AppConfig.
/aws-saas-boost/services/settings-service/src/main/java/com/amazon/aws/partners/saasfactory/saasboost/AppConfig.java

DAL is the data access layer that interacts with appConfig object using configuration values. It helps setting and getting the values in parameter store.
/aws-saas-boost/services/settings-service/src/main/java/com/amazon/aws/partners/saasfactory/saasboost/SettingsServiceDAL.java

SettingsService itself defines REQUIRED_PARAMS, READ_WRITE_PARAMS and TENANT_PARAMS. And the Lambda request handlers which will be used by API gateway.
/aws-saas-boost/services/settings-service/src/main/java/com/amazon/aws/partners/saasfactory/saasboost/SettingsService.java

A quick way to deploy new service code is through script /aws-saas-boost/services/settings-service/update_service.sh

./update_service.sh ${env} sb-${env}-artifacts-xxxx

Some Useful APIs when developing mircoservices(you can get the bear token from the request header from accessing control plane admin UI):
GET Application Configuration:

curl --location --request GET 'https://xxxx.execute-api.us-east-1.amazonaws.com/v1/settings/config' \
--header 'Authorization: Bearer bear-token-from-admin-ui-request-header' \
--data-raw ''

SET Application Configuration

curl --location --request POST 'https://xxxx.execute-api.us-east-1.amazonaws.com/v1/settings/config' \
--header 'Authorization: Bearer bear-token-from-admin-ui-request-header' \
--header 'Content-Type: application/json' \
--data-raw '{
    "name": "sb",
    "domainName": "",
    "sslCertArn": "",
    "minCount": 1,
    "maxCount": 1,
    "computeSize": "S",
    "defaultCpu": 512,
    "defaultMemory": 1024,
    "containerPort": 8080,
    "healthCheckURL": "/index.html",
    "operatingSystem": "LINUX",
    "instanceType": "t3.medium",
    "filesystem": {
        "fileSystemType": "EFS",
        "mountPoint": "/mnt",
        "fsx": null,
        "efs": {
            "encryptAtRest": false,
            "lifecycle": 0,
            "filesystemLifecycle": "NEVER"
        }
    },
    "database": {
        "engine": "AURORA_PG",
        "instance": "T3_MEDIUM",
        "version": "11.9",
        "family": "aurora-postgresql11",
        "database": "sbqa",
        "username": "admin",
        "password": "password",
        "bootstrapFilename": "",
        "port": 5432,
        "engineName": "aurora-postgresql",
        "instanceClass": "db.t3.medium"
    },
    "billing": null
}'

Update Onboarding service to pass parameters
Onboarding services orchestrates all infrastructure and resources for a new tenant in your environment.
Onboarding services needs to be modified to understand the model of the new extension and retrieve the parameter store values. It then uses the values to invoke cloudformation.
Code location: /aws-saas-boost/services/onboarding-service

A quick way to deploy new service code is through script /aws-saas-boost/services/onboarding-service/update_service.sh

./update_service.sh ${env} sb-${env}-artifacts-xxxx

3. Cloudformation

Cloudformation temple is used to create resources for new tenants. Extensions are defined as nested stacks.
We need to create new nested stacks for the extenstion and make sure root cloudformation template gets newly created parameters being passed by the onboarding service.
Code location: /aws-saas-boost/resources

Provision resources per tenant and define parameters needed for template: /aws-saas-boost/resources/tenant-onboarding.yaml
Parameters, Conditions should be defined accordingly, Resources should be defined as Type: AWS::CloudFormation::Stack to refer to nested stack.

Update IAM policies for tenant computing resources: /aws-saas-boost/resources/saas-boost-svc-onboarding.yaml