## Notes *Building Microservices* is an [[O'Reilly]] book. My personal notes about the second edition by Sam Newman will follow. ## Chapter 1 - What Are Microservices Microservices are a way of drawing boundaries between portions of a system. These boundaries can be drawn along databases, because an individual microservice tends to govern a single domain of business. ### Key Concepts #### Independent Deployability A microservice should be able to change its internal implementation without disturbing those microservices that depend on it. #### Modeled Around a Domain [[Domain-driven design]] scales beyond a UI-API-database architecture. #### Owning Own State Ensure that databases aren't shared between microservices and that each microservice pings another microservice business domain to get data from another database. Ensure that changes in a microservice does not break its contract with other microservices. #### Size There's no defined rule on how large a microservice should be. Ideally it would be small enough for the development team to remember the code. #### Flexibility Microservices have a cost. The same friction for moving away from a monolith design and toward a microservice design is the same friction of moving from microservices to something else. ### Alignment of Architecture and Organization Conway's Law > Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of those organizations. A three-layered architecture couples around traditional technical domains: UI, business logic, database; and not around business domains. Changing functionality requires changes in all three tiers and could affect other lines of business. Stream Aligned Teams > A stream-aligned team is a team aligned to a single, valuable stream of work ... the team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work. This leads me to believe that there could be [[internal variables]] that define how decoupled a team or organization is defined. It also brings up memories about being part of a company or project that restructures itself every once in a while to meet financial goals. One perspective of restructuring is that it is expensive to the organization. Restructuring does not benefit the teams initially because new members need to get up-to-speed on a new codebase, procedures, code reviews, delivery processes, existing contracts between other microservices, and more. It also reminds me of being a part of Story Builder where I used to oversee production deployments. The problem with these deployments is that I asked outside teams if they had anything they wanted to merge and deploy at the same time. This was because we used a monorepo and had multiple engineers working in the same code folders and I had to ask individual developers if their code was ready to be deployed. This leads me to believe that this degree of collaboration is an *internal variable* for describing the friction between teams in an organization. ### Monolith #### Single-Process Monolith A single-process monolith is the most basic aspect of a monolith. There is no clear delineation of internal modules. #### Modular Monolith There are clear boundaries within the code, but everything still needs to be combined for deployment. Despite modularization in the code, the code connection to the database is still singular. ### Enabling Technology The author thinks that technology adoption should be done incrementally, and I believe the same. There is another set of technology that microservices tends to need to adopt. #### Log Aggregation and Distributed Tracing [[Log Aggregation]] should be adopted *before* developing microservices. However looking for a trail of logs can be difficult since they are aggregated into a single collection. Therefore it is also necessary to be able to follow that trail using a technology like [[Distributed Tracing]]. #### Containers and Kubernetes TBD #### Streaming Helps further decouple request-response-based communication between microservices and also opens up the possibility of other patterns of communication. ### Advantages of Microservices #### Technology Heterogeneity Each microservice can choose the tech stack that best optimizes for performance. #### Robustness Individual business lines may fail, but other aspects of the product are unaffected and can still run. #### Scaling If a monolith needs to scale, then everything needs to multiple. However, in a microservices architecture, individual components can scale, thus wasting less resources. #### Ease of Deployment In a monolith, deploying an one-line change means deploying the whole thing, which can lead to risks. This leads to waiting until enough changes justify a deployment, but then everything must be tested and this becomes expensive. Alternatively, in microservices,