Base Microservice Specifications

Overview

This document will describe basic functions all Microservices will have

Software Topics

Versioning

To distinguish when containers were built, each container will have a buildinfo.json text file generated.

{
  "timestamp":"2021-10-16T14:45:51.208015",
  "base-version":"<insert base version here>",
  "application-version":"<insert application version here>"
}

In the keys "base-version" and "application-version", developers will be required to follow the semantic versioning method, a sequence versioning method that follows a vX.Y.Z format (eg: v1.2.3), where X is a major change, Y is a minor change and Z is a patch change. Additional information can be added on the end of the version number to distinguish between test builds, nightly builds, ect. Example: v1.1.2-20211209Nightly

Syslog Logging

In effort to centralize logging, all containers must log to a local syslog server. In the condition of Cloud 4.0, a syslog container will be active for programs to log to. A general syslog message will follow RFC 5424.

Event Messaging

Microservices will have their own event messaging topics that other microservices can subscribe to. For instance, an authentication microservice might have a topic for notifying other services when tokens have expired.

Database/caching

Each microservice will have its own database and cache. This is to reduce complexity of having a global cache and database, having a global cache also can reduce security.

Well Known Endpoints

/health

Can return HTTP status 200 for healthy,

{
	"status":"OK"
}

or 500 for not healthy.

{
	"status":"NOK",
    "reason":"Some reason as a string"
}