Comments by "TheEvertw" (@TheEvertw) on "Mastering Your Microservices With Observability" video.

  1. Observability needs to be designed into the system by the Architect, and he/she needs to take responsibility that it is implemented. You need observability to test and maintain a system, so it DEFINITELY should be in the list of key stories for a new system. "As a developer, I want to know what is happening inside the system in order to debug it" -- and take it from there.
    1
  2. An introspection / monitoring system is usually over-engineered. Learn from the UNIX principles: you can not predict at design time how you will want to use the data from that system. So let it generate a text-based stream, and make it interactive so that you can tell it what you want to see in the output -- like the log level. Than you can design your heart out for any storage, post-processing, logging or visualisation backend you may want.
    1
  3. Micro-services are not a new idea. UNIX was built around micro-services, only back then they were called processes. So if we want to have a truly useful micro-service architecture, we can learn a lot by looking at the features that the UNIX architecture provided. UNIX offers solutions for: * Configuration of services * Starting and Stopping services in a pre-defined order * Interactively monitoring, starting and stopping services. * Interactively monitoring the input and output to services. * Logging. * Setting a unified Time for the services. * Offering a unified method for reading and writing data, which the user can (re)direct, store and replay as he/she pleases. This is very useful during testing and trouble-shooting. * Methods for authentication & authorization. As it stands, UNIX is locked into the single "computer" paradigm. I wonder why people aren't more interested in e.g. Plan9, which elevates the UNIX principles into a Cloud operating system.
    1