# FAQ ## Frequently asked questions ### What is the Devops app responsible for?
Show answer Devops is the backend runtime and delivery layer of Rierino. It is where you define API flows, assemble microservices, expose them through gateways, deploy them, and operate them. See [Overview](https://docs.rierino.com/devops/overview).
### What are the main building blocks in Devops?
Show answer Think in six main groups: * **API Flows** for orchestration and endpoint logic * **Microservices** for runtime services and reusable backend components * **Gateway & Security** for API exposure, auth, and edge control * **Branching & Migration** for promoting changes across environments * **Administration** for controlling deployed services * **Batch Tasks** and **Pro-Code** for specialized jobs and extensions Most teams spend the most time in [API Flows](https://docs.rierino.com/devops/api-flows), [Microservices](https://docs.rierino.com/devops/microservices), and [Gateway & Security](https://docs.rierino.com/devops/gateway-and-security).
### How do sagas, runners, and deployments fit together?
Show answer A **saga** defines the flow. A **runner** executes backend work. A **deployment** decides where one or more runners run. In practice, a request often enters through the gateway, triggers a saga, calls handlers inside one or more runners, and runs inside a specific deployment target. See [API Flows](https://docs.rierino.com/devops/api-flows) and [Microservices](https://docs.rierino.com/devops/microservices).
### What is the difference between a saga and a runner?
Show answer A saga is orchestration. It defines the sequence, branching, and routing of work. A runner is execution infrastructure. It hosts the handlers, states, queries, streams, and other elements that actually perform the work. Use a saga when you need flow control. Use a runner when you need reusable service capability.
### What is an element in Devops?
Show answer An element is a reusable backend building block inside a runner. Examples include handlers, state managers, query managers, systems, streams, actions, and roles. Elements let you configure a capability once and reuse it across many services. See [Elements](https://docs.rierino.com/devops/microservices/elements).
### When should I use a saga instead of only exposing a CRUD service?
Show answer Use a plain CRUD-style service when the endpoint maps cleanly to create, read, update, or delete on one domain. Use a saga when you need orchestration across steps or systems. Typical saga cases include validation, branching, retries, transformations, enrichment, async triggers, and combining multiple services into one API.
### What are the most critical runtime components to understand first?
Show answer Start with these: * **Sagas** for API and process flow * **Runners** for service execution * **Handlers** for business actions * **State managers** for aggregate storage * **Query managers** for read models and searches * **Streams** for async and event-driven communication * **Deployments** for rollout and scaling Once these click, most of Devops becomes much easier to navigate.
### How are APIs exposed to consumers?
Show answer APIs are exposed through the gateway layer. The gateway maps paths to backend services, applies security rules, and forwards requests to the right runners or channels. This is also where token handling, session behavior, and edge-level controls live. See [Gateway & Security](https://docs.rierino.com/devops/gateway-and-security).
### Where do authentication and authorization fit?
Show answer They start at the gateway edge. Gateway configuration controls how requests are authenticated and how sessions or tokens are handled before business logic runs. Some authorization decisions can also be enforced deeper in flows and handlers, depending on the use case.
### What can usually change in real time, and what usually needs deployment?
Show answer Many configuration-level changes can be applied quickly. That often includes saga updates, routing logic, element configuration, and other metadata-driven behavior. Deployment is usually required when runtime packaging, infrastructure placement, binaries, or environment-specific rollout settings change. The safest mental model is: * **Flow and config changes** are often immediate * **Runtime packaging and environment rollout** are deployment concerns
### What is a deployment in Rierino?
Show answer A deployment is a grouped release unit for runners. It defines how and where runners are installed or started for a target environment. One deployment can contain one or many runners, depending on how you want to package scale, isolation, and operational ownership. See [Deployments](https://docs.rierino.com/devops/microservices/deployments).
### How should I think about state managers, query managers, and streams?
Show answer They solve different backend access patterns: * **State managers** are for entity storage and direct record access * **Query managers** are for search, filtering, reporting, and read-heavy access * **Streams** are for event-driven input and output Together, they let one platform handle transactional APIs, search-oriented reads, and async processing. See [State Managers](https://docs.rierino.com/devops/microservices/elements/state-managers), [Query Managers](https://docs.rierino.com/devops/microservices/elements/query-managers), and [Streams](https://docs.rierino.com/devops/microservices/elements/streams).
### Can Devops orchestrate both internal and external systems?
Show answer Yes. That is one of its main strengths. Flows can combine internal runners with external APIs, databases, streams, file systems, and specialized connectors in one controlled process.
### How does Devops relate to Configuration, Design, and Data Science?
Show answer Devops runs the backend services. **Configuration** defines reusable runtime assets such as queries, rules, and dynamic handlers. **Design** builds the admin UI that consumes Devops APIs. **Data Science** adds ML, GenAI, MCP, and related model-driven capabilities that Devops flows can call. Devops is often the execution center that ties the other apps together.
### What is the typical path for building a new backend capability?
Show answer A common path looks like this: 1. Define the needed data access or integration elements. 2. Assemble or update a runner with those elements. 3. Create a saga if the capability needs orchestration. 4. Expose it through the gateway if it needs an API endpoint. 5. Add it to a deployment and promote it across environments. This keeps service design, exposure, and rollout separate but connected.
### When should I care about branching and migration?
Show answer As soon as multiple people or environments are involved. Branching helps teams isolate work. Migration helps teams promote those changes safely to test and production. This matters even more when configuration is edited live and multiple services depend on shared assets. See [Branching & Migration](https://docs.rierino.com/devops/branching-and-migration).
### Where should I go next for deeper Devops FAQs?
Show answer Start with the subsection that matches your immediate goal: * Need endpoint orchestration or process logic → [API Flows](https://docs.rierino.com/devops/api-flows) * Need service structure or deployment model → [Microservices](https://docs.rierino.com/devops/microservices) * Need API exposure or auth setup → [Gateway & Security](https://docs.rierino.com/devops/gateway-and-security) * Need promotion and release flow → [Branching & Migration](https://docs.rierino.com/devops/branching-and-migration) * Need runtime control after deployment → [Administration](https://docs.rierino.com/devops/administration) Subsection-specific FAQs can then go deeper without repeating the core mental model.