webfountain

Loose coupling is an essential property of fine-grained, event-driven systems. However, cloud resources that decouple event producers and consumers incur a run-time cost. How to weigh the trade-offs?

Making everything loosely coupled (or thinking carefully about your architecture) can actually make your cloud bill go down.

• Cost doesn’t mean just reading your billing statement and adding the numbers. Instead, you must consider the total cost of a solution and the trade-offs that are implied by the different approaches

• The complexity of a design decision isn’t measured in lines of code. A single line can introduce dependencies or make critical assumptions. As architects, we want to understand the structure of our solution, not just the lines of code.

• Distributed systems need special consideration. You’re not just wiring some random stuff together, you’re defining your application’s topology. Boundaries matter. Pattern diagrams help you express those decisions better than just a collection of service icons.

Architecture is the business of making (conscious) trade-offs, so it behooves us to look at which trade-offs this solution implies.

• Trades application code for platform services. Configure services using code or config autogeneration. The resulting automation code is therefore generally less error-prone.

• Explicitly writing logic requires a higher level of experience and professionalism that most developers want to achieve. This career goal sidesteps attaining a deeper knowledge of cloud platform and its components to write automation code.

• Using platform services gives you better data consistency

• As mentioned above, the refactored solution makes the application topology explicit. You no longer depend on passed-in environment variables to understand which component talks to which others.

What is 'Engineering'?

Engineering is the application of an empirical, scientific approach to finding efficient solutions to practical problems.

Fundamentals of an 'Engineering' Approach

• Iterative
• Employs Feedback
• Incremental
• Experimental
• Empirical

In this two part overview on observability Ben Hall walks us through the complexity of understanding and resolving problems in modern microserice architectures. With the use of OpenTelemetry (OTel) as a vendor-neutral standard, we can instrument our systems with OTel using it as "... a complete end-to-end implementation for generating, emitting, collecting, processing and exporting telemetry data to any supported observability back-end."

In short:

• We must be able to find out why they [problems] have occurred.
• For this, our system must be observable.
• To be observable, a system needs to be instrumented such that the code emits telemetry, which is typically logs, traces and metrics.
• This telemetry must be sent to a backend that supports joining up that telemetry data and answering questions about the system’s behaviour.