This reference architecture is an end-to-end sample derived from a customer engagement. We've distilled it down to the main technical lessons learned to serve as a scaffold for future work. The majority of business logic and detail related to data models have been removed to simplify the solution; this extends to security and infrastructure elements.

There is an accompanying article in the Azure Architecture Center that this reference supports.

The implementation shows:

• managing and deployment using Terraform
• distributed telemetry using App Insights
• secret management using Key Vault
• networking lockdown using Azure Functions
• load testing using Locust
• database access using Mongo API on Azure Cosmos DB

The organization needs to digitally store the results of patient medical tests. Other internal and third-party systems will need to interface with this data via an API that allows reading and writing of the data. These interactions need to be recorded in an audit register. Access to the API needs to be managed by a system that allows for easy integration with different authentication mechanisms. APIs should not be publicly accessible outside of a single managed endpoint. All code and infrastructure deployment should be automated.

The following diagram represents the architecture of the solution.

At the core of the solution is a set of microservices. The first service (PatientTests API) provides the CRUD operations for patients and their associated tests. The second service (Audit API) provides operations to create auditing entries. Both of these services store data in Azure Cosmos DB, using the Mongo API. The Azure Cosmos DB endpoint can be replaced with another MongoDB service, without changing code. The services don't share data, and each service may be deployed to its own independent database.

The Audit API is locked down to only be accessible at a network level from other systems in the same vnet. The PatientTests API is similarly locked down to only be accessible from the API Management subnet. Only the API Management is accessible from the public internet. In addition to the network-level security, the function apps are also protected by requiring API keys for access. These keys are stored in Key Vault, along with other sensitive data such as connection strings, and is only available to specified identities. More information on the security aspects can be found in Security patterns. In addition, keys can be rotated to make the system more secure. More information about key rotation can be found in Key rotation.

Telemetry is captured across the whole request pipeline from API Management and the functions. Telemetry shares a common operation ID, allowing it to be correlated across these components. More information about this distributed telemetry tracing can be found in Distributed telemetry.

The solution may be deployed using Terraform. The Terraform templates and code is available in the /env folder. The readme explains how to deploy the environment into your own Azure subscription. This can easily be automated using a system such as Azure DevOps or GitHub Actions.

The PatientTests API and the Audit API may be found in the /src folder.

These three folders contain a dev container, which will have all the prerequisites installed, to help you get going quicker.

The APIs are built using TypeScript on Azure Functions. Both the PatientTests API and the Audit API have a full suite of automated integration and unit tests. This helps to prevent regressions when any changes are made. It is also set up to do linting using ESLint to maintain code styles and help guard against unintentional errors. The services' respective readme's contain information on how to run the tests and linting.

The project contains a Locust load test against the API Management in the /src/LoadTest folder. Locust is an open-source load testing tool and the tests are written in Python. The load tests can be run locally and remotely in AKS cluster.