Goals

  • Go shopping. Do House Chores
  • Find a way to hit priorities if I can

2025-08-14 10:35

  • House Chore 1, turned out to be a bust. At least I got a walk out of it. Will try day after

2025-08-14 11:35

  • Nap

2025-08-14 11:46

  • Back. Now to skim three Terraform books and figure out one that will help me the most
  • Terraform in Depth, by Hafner it is.
  • 2025-08-14 11:54: Interrupted. BRB

2025-08-14 13:55

  • Back

  • 2025-08-14 14:25: Ok. Not that book. I seem to be mean to tech books. I gave it a fair try. This is not serving me right now though. Off to look for something else that matches my needs

  • 2025-08-14 14:26: Ok, found two. One is Bootstrapping Microservices, which seems to be exactly what I want. And the other is Terraform in Action, which is something I’ll pick up, if the Bootstrapping book does not work out.

  • 2025-08-14 14:34: Yes, Bootstrapping Microservices is it. Better to work from outside in. I know what I want. And I hope to learn more in depth and find what I’m not so good at as I actually do this

  • 2025-08-14 14:46: From the book,

    This book won’t teach you everything; there’s far too much to learn for any single book to do that. Instead, we’ll take a different approach: we’ll learn practically the minimum that is necessary to bootstrap a new application and get it in front of our customers.

    Why, yes please!

  • 2025-08-14 14:57: I thought I’d me doing my server first and then writing about a more generic version of what I did on the blog. Looks like I’ll be doing this the other way round

  • 2025-08-14 15:15: Tea

2025-08-14 15:45

  • Back.
  • Few heuristics on designing microservices:
    • Don’t overdesign or try to future proof your architecture. Start with a simple design for your application.
    • Apply continuous refactoring during development to keep it as simple as it can be.
    • Let a good design emerge naturally.
    • What I’m saying is that you should be planning for your plan to change! You should be able to respond quickly to changing circumstances, and that’s something also well supported by microservices.
  • More Design Principles:
    • Single responsibility principle: each service should have a single, well-defined area of responsibility.
    • Separation of concerns: clear separation of responsibilities rather than intermingled responsibilities, which helps make each microservice simpler and easier to understand.
    • Loose coupling: connections between services are minimal and that they don’t share information unless necessary.
    • High cohesion: all the code in a microservice belongs together and contributes to solving the problem that is the service’s area of responsibility. If a microservice solves more than one problem or has a larger area of responsibility, then this is an indication that it’s not highly cohesive.
  • Domain Driven Design
    A bounded context is a conceptual bubble within the domain model in which all the terms, entities, and logic within the bubble make sense together, belong together, and are consistent with each other. Creating bounded contexts is a way to carve up our domain models into logical and self-contained parts.
    The process of DDD can help us figure out the answer to this question: What goes into each microservice?
  • Is it “micro”-service?
    we should be building them around the concepts in our domain and to whatever size feels natural for that domain.

The tiny project, the book aims to build; A video streaming service


2025-08-14 16:05

  • Chapter 2!
  • The book is darned repetitive. And not in a good, Head First book way. I hope they stop doing this in future chapters
  • The author’s philosophy of development
    • Iterate
    • Keep it working
    • Move from simple to complex
  • 2025-08-14 16:38: Stop for chores. Be back.

2025-08-14 20:30

  • Back too late to continue. Bed Time!

Feedback on this post?
Mail me at feedback at this domain.