Welcome to the simple store, this is a small project to demonstrate monitoring across a distributed architecture (for now)

• slides
• Docker images - please note the lastest known working versions of each container is specified in the deployments.yaml

The solution looks at using:

• Rancher / Graphana - Dashbaords
• Istio (Envoy) / Prometheus - to provide metrics
• Kiali - Topology, note Kiali can use data from Prometheus and Jaeger
• Jaeger - Tracing (via OpenTracing)
• Datadog - Logging (note this can be used for all)

an alternative for Metrics, Topology, Tracing and Dashboards look at Apache Skywalking.

an alternative service mesh consider https://linkerd.io, or https://mae.sh/

Repositories

• core - shared .net application/framework code (setup of logging, messagebus, database, monitoring etc)
• apigateway - implementation of the api gateway using Ocelot (its mainly configuration)
• basket - users store items in the basket, the basket can be created and checkedout. Uses redis as a quick temporary store.
• catalog - items which the shop offer, images are stored on disk and the metadata is in a prosgres database.
• ordering - contains all the orders, these are created from the basket being checked out and are set in the ready state once the stock as been reserved.
• warehouse - contains the stock information, i.e. quantity, when a basket is checked out this will reserve stock and when the order is completed, the stock will be removed.
• infra - setup of the cluster (k8s and terraform)

stateful services

at the moment all services are inside a container, consider using a PaaS instance instead.

• Redis - used for a fast data cache
• RabbitMq - the message bus between services
• PostgreSql - is being used as a document database (JsonB fields) this is fully supported by Marten.

Repo structure

service repos have:

• src - all the source files
• .circleci - Circle CI build scripts
• k8s - kubernetes deployment files - not using helm atm.

Design issues

as this is a demo for monitoring there are some design issues which have been skipped:

• REST model - the anemic domain model is stored in the db and exposed directly to over the web api - look at ports and adaptors to solve this.
• Domain model - it's anemic, this maybe ok for you, consider DDD or Transcript
• Eventing without transactions - all events are happening within a DB transaction, meaning that if the transaction fails the event has already been published - consider Event filters and the CAP (dotnet opensource project with regards to events), NServiceBus or AllAboard
• Dead letter queue - we have a retry policy, however look into how to handle messages which cannot be processed.
• API Versioning - this is a quick impl, all API (HTTP and AMQP) need to be versioned
• Security - there is none - consider OpenId Connect, and integrate with the api gateway
• HELM Charts - consider using them, and set the deployment to be rolling
• Secrets - currently stored in config files, consider Hashi Corp Vault
• Concurrency - consider version number on models (Optimistic).
• dotnet core ioc registrations - in .NET Core we can register services, the core project is a quick impl of this, consider neatening it up.
• Application Framework Packages - Core is 1 package, consider separating this into multiple, 1 for each concern, as at the moment your service will have a dependency on packages it does not use.
• Interfaces - the code uses direct dependencies, this debatable, even more so with micro-services (i can see the point both ways)
• Automated testing - any good automated testing framework should work, consider contract testing minimum, as it acts as documentation.

These are a few things we would normally need to consider for the production version.