webfountain

Data API Management

-

Your Partner in Strategic Data Solutions

🚧 Under Construction 🚧

We're currently working on improving our blog. Please excuse our pixels!

Tech News

What we're reading

  • Architecture

    I made everything loosely coupled. Will my cloud bill go up?

    Published: February 13, 2023 Listed: March 14, 2023

    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.

  • Software Engineering

  • Observability

    The Modern Observability Problem (Part 1)

    Published: October 15, 2022Listed: November 21, 2022
    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.