So what is this project? I’ve come to realize during my work that most of the time you’re not able to get the full end-to-end picture of a software stack. That’s why I wanted to start a project that does is not required to reach production but is meant as a test-bed for cool technologies I’d like to experiment with.
So I came up with the following project: A metric storage and visualisation application featuring:
- Distributed Microservice architecture
- Asynchronous & Synchronous Messaging
- Large-scale data (metrics) storage
- Observability of Metrics, Logs & Traces
- Automated preview (ephemeral) environments
- Deployments on modern K8S/OpenShift environments
Architecture
The general architecture looks like the following:
Metrics Ingress (API Ingress Point)
The first service is responsible for exposing a HTTP endpoint to process metrics from external services. This service validates incoming metrics, parses information into an internal format and publishes the resulting data (if valid) onto the message bus. In the future this service can also be responsible for authenticating incoming metrics.
Note: Logs Ingress is not yet planned to be implemented but would be responsible for parsing incoming logs into metrics based on a users configuration.
Metrics Processor (Business Logic Processing)
The second service is responsible for handling business logic within the application. Sending update notification, processing metadata of metrics, etc. For now this is a very simple service but can be expanded in the future.
Metrics Store (Data Storage)
The metrics store is responsible for managing the metric storage. This decoupled approach for data storage came from the need to have a single service govern the dataset and allows this service to freely experiment with various ways of storing a large amount of metrics and keep it’s interface public.
Metrics Frontend
The metrics frontend application is responsible for the user-facing side of the stack and manages interaction and data presentation.
Messaging
The current choice of messaging engine is Nats.IO, a high performance distributed messaging framework that can handle millions of messages per second. Nats is used for all internal communication between services through Messaging, Queues (w/ JetStream) and Request/Reply mechanisms. NATS allows for simple microservice communication without the need for Service Meshes and other discovery mechanism.
Data Storage
For data storage PostgreSQL is used because of it’s open source nature and high performance storage. Aditionally the future use of TimeScaleDB is highly useful if (when) standard Postgres performance has been reached. The goal is to take bare Postgres as far as possible for the development of this application to learn the most about Postgres.
Language Choice
The software in use comes down to Go, for its simplicity, performance and great standard library. Plus I really like programming in Go, so why not take advantage of that during this project, there’s already so much to learn.