Software Architecture Books Summary And Highlights -- Part 13 Dependency Management

 

Dependency Management

Highlights

Shared Library vs Shared Service

The shared library technique is a good approach for homogeneous environments where shared code change is low to moderate.

One distinguishing factor about the shared service technique is that the shared code must be in the form of composition, not inheritance.

The shared service technique is good to use in highly polyglot environments (those with multiple heterogeneous languages and platforms), and also when shared functionality tends to change often.

SAH ch 8 Reuse Patterns

Sidecar pattern and service mesh

Share common operational lib such as logging, monitoring, service discovery, auth… and connect these lib among services.

SAH ch 8 Reuse Patterns

Source control vs Dependency-management

All else being equal, prefer source control problems over dependency-management problems. Source control problems are a lot easier to think about and a lot cheaper to deal with than dependency-management ones.

SWG Ch 21 dependency management

Dependency cost

you must consider the cost of upgrading dependency and how to reduce the cost.

human cost contains development time and computation resource for development.

Code cost contains version controls and build cost.

These cost should all be scalable. otherwise, these cost will grow in a situation like a boiling frog.

Scalable policy: When a internal lib is upgraded, letting the lib owner update all client usage of the lib is more scalable than letting the client upgrade the lib usage.

SWG ch 1 what is software engineering?

when importing a dependency, we need to think about the maintenance cost, the reliability of the dependency (tests, author’s credibility…), the cost of developing it ourselves.

Most problems in dependency management stop being problems when you can see exactly how your code is being used and know exactly the impact of any given change.

SWG Ch 21 dependency management

Dependency management options

1. no version update as long as the dependency is good enough at beginning and you don’t know how long your own project will last
2. semantic version:
   1. use SAT-solver to find a single compatible version for all depending packages based on their requirements and constraints. e.g. ≥1.5 but there may not be a solution at all
3. Bundled Distribution Models
   1. dedicated distributor manually selects all dependencies’ version and bundle them into a single unit.
4. live at head
   1. consumer develops CI tests in open source lib’s codebase. When the lib owner changes the api, the tests are ran. If anything fails, the commit is blocked. The owner needs to work with consumer to solve it.
   2. unproven at scale

SWG Ch 21 dependency management

Managing Dependencies in Build system

1. internal dependency:
   1. transitive dependency: A → B → C, C’s symbol should not be accessible to A because B can be changed to remove C as dependency. A need to directly depend on C.
2. external dependency
   1. one version rule
   2. transitive dependency
      1. multiple external dependencies can depend on different versions of other lib
      2. bazel doesn’t download transitive external dependencies. It generate a manifest of them instead and allow manual edit to adjust versions
         1. At larger scales, the cost of manually managing dependencies is much less than the cost of dealing with issues caused by automatic dependency management.
   3. Security and reliability of external dependencies
      1. Another alternative that completely sidesteps the issue is to vendor your project’s dependencies. When a project vendors its dependencies, it checks them into source control alongside the project’s source code, either as source or as binaries. This effectively means that all of the project’s external dependencies are converted to internal dependencies. 
      2. checking every third-party library referenced throughout Google into a third_party directory at the root of Google’s source tree. However, this works at Google only because Google’s source control system is custom built to handle an extremely large monorepo, so vendoring might not be an option for other organizations.

SWG Ch 18 build system

Versioning practices:

1. Defer It for as Long as Possible:
   1. Ignore other service’s data as much as possible and only consume the needed piece so that other data’s change won’t affect you
2. Catch breakage early with tests
3. Use semantic versioning e.g. 1.0.1
4. coexist both the old and new interfaces in the same running service
5. Use Multiple Concurrent Service Versions.
   1. cons:
      1. has to branch code
      2. hard to deploy simple bug fix
      3. old service and new service create same data
   2. useful only when old version and new version coexist for very short period of time

MSV Ch 4 Integration

Related Chapters

SAH ch 8 Reuse Patterns

MSV Ch 4 Integration

SWG ch 1 what is software engineering?

SWG Ch 18 build system

SWG Ch 21 dependency management