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?

tl;dr

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

Summary:

• 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.

Summary:

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

Summary:

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.