DevOps Architecture: Platform Primitives: Libraries
Libraries enable an application-scoped capability and are a foundational primitive for establishing platforms and standardizing an organization’s architecture. Libraries can help control implementation costs by “Solving Once” and distributing that solution everywhere. Adopting libraries is low friction because they are a common pattern with language level support for packaging, distribution and installation. This post will start by showing a high level view of how libraries can help shape architecture. Next it will discuss what libraries are and what they aren’t. After that the organizational benefits of libraries will be explored, and finally useful metrics in library adoption will be covered.
Organizational Topology
Libraries have a profound impact on Architectural and Organizational Topology. They reduce complexity by removing duplication. Consider an organization with a number of microservices. Each service provides its own implementation of a client SDK (“Implementation X” in the charts below) for talking to a shared service:
Libraries support an N:1 reduction in implementations. The chart below shows the topology of a centralized library:
In the chart above a library is used, which provides the organization with a capability. A client SDK is now available to any service (of the same language). Libraries reduce the implementation cost to constant time. No matter how many services are using the library the implementation cost is constant. Compare this with the original example where each service has its own implementation. In the original example the organization is paying for duplicate implementations which cost money and time. Libraries provide a huge organizational savings in terms of implementation and opportunity cost, but if this wasn’t enough it’s often the case that implementations carry their own hard dependencies.
Consider the case where each services initial implementation has an associated dashboard:
Each dependency may have a number of dependencies, including varying degrees of tests, observability/dashboards, and documentation. Libraries reduce implementation cost to constant:
Every service now has access to an Implementation and a dashboard.
What is a Library?
We just saw how libraries can affect our services and organizational topology, now let’s focus on exploring what libraries are: A library is a piece of application level code which is not directly executed. A library is coupled to a language, libraries are executed in the context of an application and are not standalone.
Libraries are a way to centralize any computation, and can be used to provide primitives to build like a REST client library, or an HTTP library, or a message publishing library, Or encapsulate common functionality. Libraries are:
- Not executed directly
- Language Specific
At the organizational level libraries provide a constant time implementation cost (0(1)), meaning once a library is created it becomes available for all services (of the language) to use. Libraries have a constant dependency cost (1 dependency for each service), 1 or 100 services (of a language) will still have a single library. Finally, libraries incur a linear integration cost O(n).
Libraries enable a constant architectural dependency complexity (O(1)), no matter how many services there will only be a single implementation per language. For this reason it’s common platform evolution to favor duplication for a certain low number of services, and then to refactor out the duplication into a library to benefit future services.
Common Examples
- Client SDK
- Logging
- HTTP Client
- Database Clients
- Encoding/Decoding
- Data Validation
How do Libraries Support an Orgs Ability to Deliver? (Benefits)
Libraries help to insulate teams from implementation details by establishing a single centralized and standardized source of truth for specific classes of functionality. It enables organizations to careful curate, implement, test and document best practices and distribute it to teams in a way that minimizes adoption friction. Teams have to focus on public api’s and the mechanics of usage vs implementations.
Standardization — Enable Defining HOW Something is Done
Libraries provide an organization with a per language Executable Best practice. Subject matter experts can own, create and maintain libraries. It abstracts teams from implementation details by allowing teams to focus on their core competencies, business goals and customers. Libraries are integral in promoting best practices. Instead of an organization providing documentation or guidance libraries provide functionality.
Centralize — Enables defining WHERE a Solution Lives
Libraries establish a single source of truth to accomplish certain sets of actions. The value of centralization increases when considering documentation and testing. Consider teams that are duplicating functionality, Each may have their own varying level of tests and coverage, or varying degrees of documentation. Centralization promotes democratization of knowledge because there is a single well known location to see how the organization solves a problem. When an organization finds a better way to solve a problem all clients of the library can benefit.
Cost ($)
Even for simple libraries it’s cheaper to solve something one time than it is to solve n times.
Speed — Velocity
Velocity gains derive from a library being both centralized and standardized. Libraries abstract teams from having to understand implementation details of how to solve specific problems. In addition to implementation, teams no longer are responsible for testing or documenting their own implementations. Finally, libraries reduce the opportunity cost teams incur from having to repeatedly solve problems not directly related to their domains.
Security: Audit/Access Control
This benefit derives from the centralization. Having one single location allows for better control over who can access/clone/install a library. Curating and forking an open source project could allow an organization to pin “officially” supported releases. This goes for implementations as well. With a library it’s easier to audit and approve a single way of doing things, opposed to trying to manage duplicate implementations.
Security — Bug
Consider the benefits that libraries can provide when bugs are encountered. If teams have duplicate implementations there are potentially N bugs to fix: ie each team has to apply the fix test and redeploy. Consider the workflow using a library: a bug is encountered, a fix and test is created, and a new release is made. Each team only needs to update their library version. If the change is backwards compatible low risk for the team reduce overhead because the team just applies a patch fix and doesn’t have to understand the specifics.
Democratization
Finally, libraries help promote democratization of information. When a team encounters a bug or are interested in an learning more about (or improving) an implementation, the location of the implementation is well understood. Improving libraries benefits the entire organization and not just a single team.
Key metrics
There are a number of metrics important with measuring the impact of libraries on an organization:
- Percentage of teams using library (# of adopters / # of candidates)
- Percentage of teams on the most recent release
- Distributions of teams behind the current release, ie What percentage of teams are within at least 2 releases?
- How long it takes each team to update to new releases
- Feature Coverage / Team — What percentage of library features is each team using?
When To Use
- When the functionality that is being encapsulated in a library is application level, ie logging, metrics, computations, client libraries
- Minimize the time teams needs to invest in order to perform some functionality.
- Organization would like to promote a single best practice way of doing things
- There is functionality common to multiple services but is currently duplicated across services.
- When the org would like to open source a piece of functionality
Conclusion
Libraries are an excellent place to begin formalizing a platform. Because they are shared and most languages provide built in ways to distribute them, they make a great first place to begin shaping a platform. Encapsulating functionality in a library can provide velocity speedups by reducing the amount of duplication, providing a single audible centralized location for functionality. Most importantly libraries reduce teams platform adoption cost. Instead of coding functionality from the bottom up they can pull in libraries providing capabilities they need which allows them to focus on their business domain and delivering the customer and business value.
