Write libraries instead of services, where possible
Advocates of “libraries over services” argue that shipping code users can run themselves gives them control over upgrades, avoids surprise breakages from remote APIs, and reduces dependence on third‑party infrastructure. Others counter that services are often easier to monetize, observe, and operate at scale, especially when shared state, databases, or multi-language support are involved. Many conclude that a pragmatic approach is to design core functionality as reusable libraries and, where needed, wrap them in thin services or CLI tools, with the right choice depending on architecture, organizational structure, and customer needs.
Scope of “libraries vs services”
- Many agree with the article’s intuition: default to libraries, only add services when necessary.
- Others argue this is oversimplified and context-dependent (scale, compliance, data locality, team size, monetization).
Failure, upgrades, and control
- Library updates break only when the user chooses to upgrade; they can roll back easily.
- Service changes can break clients at the provider’s chosen time; SLAs and contracts mitigate but don’t remove that risk.
- Some see forced migration via services as user-hostile; others say coordinated upgrades are the tradeoff for shared development cost and security fixes.
- Both models face versioning pain: libraries with many versions in the wild vs services with compatibility layers and versioned APIs.
Data storage and architecture
- Key objection: many services fundamentally depend on databases and shared state; pushing that into a library offloads complex ops to users.
- Suggestions: define repository interfaces and let users “bring their own storage”; use common backends (Postgres, S3 APIs) or personal data pods.
- Counterpoint: storage is inherently messy (latency, throughput, snapshots, encryption, corruption handling); abstractions are leaky and coordination is poor.
Organizational dynamics and scale
- In many enterprises, new functionality defaults to a microservice; libraries are rarer and harder to coordinate across teams and repos.
- Monorepo cultures sometimes put upgrade burden on library owners, which discourages frivolous breaking changes but increases their scope of responsibility.
- Some view heavy service use as a workaround for political/coordination problems rather than technical necessity.
Monetization, control, and user autonomy
- Services are easier to monetize, observe, and control; libraries are harder to sell and support but give users autonomy and avoid lock-in.
- Examples raised: IoT devices and SaaS products that could have been local libraries but are instead recurring, opaque-cost services.
Practical guidance and hybrid approaches
- Common pattern advocated: always design core logic as a library, then optionally wrap it as:
- A thin service (HTTP/gRPC, etc.).
- A Unix-style CLI that reads/writes structured data.
- Heuristics: pure/algorithmic logic → library; components tied to private data stores, heavy shared state, or specialized infra → service.
Terminology confusion
- Several commenters find the article’s broad definition of “library” (any user-runnable software) confusing versus the usual “non-runnable dependency” meaning.