observability

TL;DR Know Why With microservices, you will inevitably ship your org chart! Think about why you are doing it at an organizational level. Don’t focus on computer science! Focus on velocity. Optimize for velocity (not engineering velocity and not systems throughput). By assigning project teams to microservices, you reduce person-to-person communication and increase velocity. Serverless Still Runs on Servers The idea of single-purpose services is a failure mode to do it blindly....

TL;DR Observability is the ability to understand what is going on in the inner workings of a system just by observing it from the outside. Your software should explain itself and what is doing! Pillars of observability are logs, metrics, traces, and events. Logs are structured logging or non-structured textual data. Used for auditing and debugging purposes. Very expensive at scale. Cannot be used for real-time computational purposes. Hard to track across different and distributed processes....

TL;DR Observability refers to three different things: logs, metrics, and traces. The problem with logs is that you have to know what to search for before you know what the problem is! The problem with metrics is they are aggregated by time and you cannot break them down by high-cardinality dimensions (like user id for example). Logs, metrics, traces, and events they each prematurely optimize one thing and comprise another thing based on a premise upfront....

TL;DR Microservices are about communicating through APIs! A service mesh defines the communication interface between microservices. In an orchestrated environment (Kubernetes), containers talk to each other on top of overlay networking. Service mesh is a central source of truth for controlling the information flow between microservices. Mesh enables both the scalability benefits of microservices as well as centralized advantages of monoliths. Service meshes come with built-in observability (logging, metrics, and tracing) for microservices communications....