The systems model of IDP, as inspired by the Backstage System Model, is an approach to managing and understanding complex software ecosystems. This model is particularly relevant in the context of DevOps and microservices architectures, where the large number of interdependent components can be overwhelming.
In the context of IDP, the systems model is used to describe and organize the various software components, services, and tools that make up an organization's technical landscape. It is structured around five key concepts: Domains, Systems, APIs, Components, and Resources.
Let's try to map a city-like software ecosystem, IDP's service catalog acts as a central repository, organizing and providing crucial information about the software assets. This ecosystem, with its interconnected neighborhoods (Domains), buildings (Systems), services (APIs), establishments (Components), and utilities (Resources), mirrors the complex yet structured world of software development and operations.
Detailed Modeling in IDP
Components and Dependencies
Let's start with a core backend service, like a central office in a building, providing specific functionalities.
Core Queueing Library:
Now let's start adding a library component, akin to a specialized tool used within the office.
Showing how the Core Backend depends on the Core Queueing Library.
APIs and Their Consumption
Core API: Represented as a service provided by the Core Backend.
API Provision: Indicating that the Core Backend exposes the Core API.
Systems and Their Components
A system that includes the Core Backend and Core API.
Linking the Core Backend and API to the Core System.
City Domains and Expansion
New part of city: For example, expanding the city, a new Domain AI is created.
Now to get the backend service and it's dependencies and ownership right in the software catalog we write an IDP YAML with the help of following conecpts:
Function: Domains are like neighborhoods, each with its unique character, housing systems that share common goals or technical requirements.
Example: The "Data Analytics District" could be a Domain, grouping systems related to data processing and analysis.
Structure: Systems are akin to buildings, each encapsulating a set of functionalities provided by various components. Example: The "Customer Insights Tower" in the Data Analytics District represents a System comprising data processing services, analytics tools, and customer feedback components.
Interactions: APIs are the services that allow different systems and components to communicate, much like the utilities in a city.
Example: The Customer Insights Tower might offer a RESTful API for querying processed customer data.
Specific Functions: Components are like the different offices or shops in a building, each serving a specific function.
Example: Within the Customer Insights Tower, there's a "Feedback Analysis Suite," a component dedicated to analyzing customer feedback.
Support Infrastructure: Resources are the essential infrastructure elements that support the systems, similar to a city's utilities.
Example: The Customer Insights Tower relies on cloud storage and computing resources to handle large datasets.
Definitions and Reference
A Domain is a high-level organizational unit in the Backstage model, grouping together systems that share common characteristics such as business goals, domain models, terminology, or documentation.
To create a bounded context for easier management and understanding of related systems.
The "Payments" Domain includes systems related to payment processing, sharing common documentation, API entity types, and integration standards.
A System is an abstraction layer encapsulating the implementation details of specific functionalities. It consists of a collection of resources and components and exposes one or several APIs.
To reduce complexity by allowing consumers to interact with functionalities without needing to understand the underlying implementation details.
A playlist management system includes backend services for playlist management and a database, exposing functionalities through various APIs like RPC, datasets, and event streams.
APIs are the primary means of interaction within the software ecosystem. They are implemented by components and define the boundaries between different components and systems.
To facilitate interaction and discovery within the software ecosystem, ensuring scalability and manageability.
A public API exposed by a system for other Spotify components, documented and discoverable in Backstage.
A Component is a discrete unit of software, such as a mobile feature, website, backend service, or data pipeline.
To implement specific functionalities and APIs, encapsulating code dependencies and interacting with system resources.
A backend service for user data processing, implementing specific APIs and relying on system resources like databases.
Resources are the infrastructure elements required for a system's operation, including databases, cloud storage, CDN services, etc.
To support the operational needs of systems, allowing for a clear visualization of resource usage and facilitating targeted tooling development.
Cloud storage buckets and CDN services used by a video streaming system.
In practice, implementing a systems model like the one used by Backstage, involves creating a centralized catalog or repository where all the information about systems, components, and their relationships is stored and managed.