The prompts I wrote and used to drive this exploration:¶

Prompt: Architectural Principles¶

The following are the architectural principles for the architecture of a set of “backend” business components to support an e-commerce order management system. The system should follow these architectural principals:

1. The Business Components will be known as Business Services
2. All Business Services within this application will be loosely coupled.
3. The Business Services will be implemented using one or more loosely coupled MicroServices
4. The MicroServices that make up the Business Services will be containerized and deployed into one or more Kubernetes clusters
5. Each Business Services will be accessible via a set of Rest APIs
6. The microservices that make up the Business Services can be discovered and accessed via standard Kubernetes Service discovery as long as they are deployed in the same Kubernetes Cluster.
7. The APIs for each Business Service will provide an authorization check against the user identity or service account identity that is in the JWT Bearer Token of the Rest API header.
8. Each Microservice within the system shall implement exception handling and log all exceptions to a cloud logging service.
9. The data persistence for all data, also called business objects, will be the responsibility of the Business Service.
10. The Business Services may utilize a common instance of a database engine that is shared across Business Services. The tables within the schema to support the Business Services will not be dependent on each other.
11. All transactional activity, i.e. Business Events published from a Business Service will be captured and managed for audit purposes.
12. An API gateway should be used to handle routing, authentication, authorization, rate limiting,

Prompt: Naming standards¶

The following are the naming standards for this project:

1. The names of all Business Services is defined in the Component Architecture Picture
2. The naming of all APIs for the Business Services shall include a short name of the class as a suffix. In other words, following an verbNoun naming convention.
3. The names of the Business events published will also clearly describe what they refer to.

Prompt: Purpose of this application¶

The following is a set of stories relative to the application to be created.

1. As a customer I want to register myself with this application so that I can place orders for products.
2. As a vendor I want to have an application in place that enables me have a record of all customers so that I can do business with them.
3. As a vendor I want to have the capability to accept orders for my products from a variety of channels, i.e. Web, Mobile, so that I can satisfy my customers needs.
4. As a vendor I need to have an inventory management service in place so that I can properly fulfill and track all orders.

Prompt: Architecture Decisions¶

The following is a set of architecture decisions that have been made about this application.

1. The integration between Business Services will leverage a “choreographed” pattern in which business events are published to an event bus. Consuming Business Services will subscribe to the events and take the appropriate action. ( reference https://gzeien.github.io/cloud-notebook/patterns/microservice-integration/ )
   1. The Event Bus will be implemented using Google Cloud Pub-Sub
   2. The Events will follow the Cloud Events standard format. https://cloudevents.io
2. The architecture will allow for the use of business policies to be applied to the business events as they flow through the event bus. This will mirror the pattern described here: https://gzeien.github.io/cloud-notebook/patterns/event-driven-1/
3. The SQL database will be implemented using Google Cloud CloudSQL.
4. All application code for the Backend Business Services should be implemented using Python.
5. All GUI code will be developed using Angular.
6. An Istio Service Mesh will be used within this architecture
7. The network connection between the application environment and all cloud services, e.g. Google Cloud Pub-Sub will be via a private network connection.
8. Use environment variables for configuration (database URLs, service URLs, secrets) is crucial for containerization and Kubernetes deployments.
9. An API Gateway will be deployed and used to access all Business Service API’s

Prompt: Code Artifact Generation ( needs picture )¶

Using this architecture diagram, please create the code required for this application

The code created should have the following:

1. implementations of the APIs for the Business Class.
2. The service should authenticate the JWT Bearer token passed in the API header against the Identity Mgmt Service represented by the diagram
3. Please include implementations of all APIs for each Business Service and appropriate exception support.
4. create the DDL for the Order class in the SQL data base.

Prompt: Document APIs using Swagger¶

The purpose of this step is to ensure the APIs to the Business Services are clearly documented. Please create a swagger formatted API documentation for all APIs that have been created.

Prompt: Deployment Artifact Generation¶

1. Create the docker file statements to containerize each Business Service in separate containers. There could be multiple MicroServices in a docker container.
2. Create Helm Chart for each Business Service to deploy the containers in a Kubernetes Cluster
3. Create the DevSecOps scripts to perform security checks on each container, publish it to the Google repository. and be coded to deploy to the Kubernetes environment once it is available.

Prompt: Testing harness Artifact Generation¶

The purpose of this step is to create a testing harness to support the automated testing of each Business Service that has been created.

This testing harness should includes testing steps for each API and validation logic to ensure that the tested executed successfully,

Each test should be logged and the log entry should include when the test was run, they status of the test ( pass, fail ), and the resulting output.

Prompt: Cloud Service Environment Generation ( picture? )¶

The purpose of this step is to create a set of terraform files to deploy the operational environment for the system.

Key points to note regarding the deployment architecture:

1. It should be cloud native using the services of the selected hyperscaler
2. The hyperscaler should be Google Cloud.
3. The deployment architecture should have:
   1. A Google Cloud Project for the Host Services. This includes all networks ( VPC in this case), all network controls, a GCP Security Perimeter to control all ingress and egress.
   2. A Loadbalancer
   3. A VPC
   4. A GKE Kubernetes cluster that is configured for Private access only.
   5. A VPC for the cloud native database services as required, and specified, by the application environment
   6. VPC Peering between these VPCs.

Prompt: Documentation¶

The purpose of this step is create an architecture overview of the system with specific details on the application component model, architectural principals, and a bill of materials that itemizes everything in the solution architecture.

The documentation should also provide an executive summary with key points about the solution.

Additionally, it should provide a list of recommendations for improvements.