diff --git a/301redirects.json b/301redirects.json index ece4ca6565..d6da0fb033 100644 --- a/301redirects.json +++ b/301redirects.json @@ -5495,6 +5495,18 @@ "destination": "/docs/products/console/api-console/advanced-section/", "addedOn": "2025-11-26" }, + "/docs/products/console/project-configuration/infrastructure-project": { + "destination": "/docs/products/console/project-configuration", + "addedOn": "2026-08-06" + }, + "/docs/products/console/tutorials/infrastructure-project/create-project-configuration": { + "destination": "/docs/products/console/project-configuration", + "addedOn": "2026-08-06" + }, + "/docs/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console": { + "destination": "/docs/runtime-components/plugins/integration-connector-agent/10_overview", + "addedOn": "2026-08-06" + }, "/docs/products/fast_data/fast_data_engine_v2/(.*)": { "destination": "/docs/products/fast_data_v2/$1", "addedOn": "2026-01-07" diff --git a/docs/getting-started/faqs/mia-platform-console-faqs.md b/docs/getting-started/faqs/mia-platform-console-faqs.md index a0b1f78dc2..afbc6f7115 100644 --- a/docs/getting-started/faqs/mia-platform-console-faqs.md +++ b/docs/getting-started/faqs/mia-platform-console-faqs.md @@ -47,10 +47,6 @@ In the top-right corner of the Design area, click on the branch/revision name to From the branch/revision management popover in the Design area, you can select "Merge from another branch". This will open a diff editor where you can compare the configurations of the source and target branches/revisions side-by-side. You can review all changes, resolve conflicts by editing the configuration directly, and then confirm the merge. The merged configuration must then be saved. [Discover more](/products/console/api-console/api-design/merge_collaboration.md) -#### What are Infrastructure Projects? -Infrastructure Projects are a specialized project type designed for Operations teams and **platform engineers** to manage infrastructure using **Infrastructure as Code** (IaC) principles. Instead of managing applications, these projects manage infrastructure components like cloud resources (e.g., using **Terraform**) or Kubernetes operators. They support a two-phase deployment process (`plan` and `apply`) to ensure changes are reviewed before execution, providing better control over infrastructure provisioning. -[Discover more](/products/console/project-configuration/infrastructure-project.md) - #### How can I delete a Project? You can delete a Project from the **Project Settings -> Advanced** tab. Clicking the "Delete Project" button will open a confirmation modal where you must type the project's name to confirm. This action is irreversible and will remove the project from the Console, with options to also delete associated namespaces and archive the Git repository. [Discover more](/products/console/project-configuration/delete-a-project.md) @@ -221,7 +217,7 @@ Yes. You can configure a **Jenkins** instance as a **CI/CD Tool Provider** at th [Discover more](/products/console/deploy/pipeline-based/configure-jenkins.md) #### How does the Console support different cloud providers like AWS, GCP, and Azure? -Mia-Platform Console is cloud-agnostic. It interacts with any CNCF-compliant Kubernetes cluster, regardless of the underlying provider (**aws cloud computing**, **google cloud run**, etc.). You can connect clusters from GKE, EKS, or AKS. For other integrations, it supports specific providers like **aws secrets manager** or **azure key vault**. Features like **Infrastructure Projects** can manage cloud-specific resources like **aws s3** buckets or **aws fargate** services using **Terraform**. +Mia-Platform Console is cloud-agnostic. It interacts with any CNCF-compliant Kubernetes cluster, regardless of the underlying provider (**aws cloud computing**, **google cloud run**, etc.). You can connect clusters from GKE, EKS, or AKS. For other integrations, it supports specific providers like **aws secrets manager** or **azure key vault**. Cloud-specific resources like **aws s3** buckets or **aws fargate** services can be described as [Infrastructure Resources](/products/console/software-catalog/items-manifest/infrastructure-resource.md) in the Software Catalog and managed with **Terraform**. [Discover more](/products/console/company-configuration/clusters-management/overview.md) #### What are Webhooks and how can I use them? diff --git a/docs/getting-started/use-cases/ai-agent-lifecycle.md b/docs/getting-started/use-cases/ai-agent-lifecycle.md deleted file mode 100644 index 14d28c7d6e..0000000000 --- a/docs/getting-started/use-cases/ai-agent-lifecycle.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: ai-agent-lifecycle -title: AI Agent Lifecycle -sidebar_label: AI Agent Lifecycle ---- - -# AI Agent Lifecycle - -Generative AI is really promising, but the path to production is fraught with challenges. Organizations often struggle to bridge the chasm between powerful Large Language Models (LLMs) and their proprietary data, orchestrate intelligent agents, and securely govern their entire lifecycle in production environments. Mia-Platform addresses these complexities by providing a structured approach to build, orchestrate, and govern end-to-end AI-native systems as a core function of the platform. AI turns from a theoretical asset into an engine for tangible business value, allowing you to ship intelligent, context-aware, secure, and seamlessly integrated applications at speed. - -## Core Capabilities for AI-Native Systems - -Mia-Platform demystifies the adoption of Generative AI by offering a structured approach to architecting, orchestrating, and governing intelligent systems at scale. - -### Build Context-Aware RAG Applications - -A primary challenge is making general-purpose LLMs reason with private, proprietary data sources. Mia-Platform enables the development of complex [**Retrieval-Augmented Generation (RAG)**](/runtime-components/templates/ai-rag-template/10_overview_and_usage.md) applications. These systems enhance LLMs so that they can access and utilize your internal knowledge bases from both structured and unstructured data sources, returning answers that are not only accurate but also deeply contextualized to your specific business domain and are therefore valuable for you. This turns your private data into a powerful competitive differentiator. - -### Forge a Foundation of AI-Ready Data - -The quality of an AI system is directly proportional to the quality of its data. By leveraging the [**Mia-Platform Fast Data**](/products/fast_data/what_is_fast_data.md), you are able to prepare and serve a continuous stream of reliable data, which is effectively aligned, contextually governed and continuously qualified. This ensures that your AI models operate with information that is secure, compliant by design, and always up-to-date, forming a foundation of unbiased, trustworthy data for any intelligent application. - -### Orchestrate Intelligent Agent & Multi-Agent Systems - -Moving beyond single-shot prompts, Mia-Platform enables the design, coordination and monitoring of complex workflows using [**Flow Manager**](/runtime-components/plugins/flow-manager-service/10_overview.md) or with custom implementation where multiple AI agents collaborate to execute distributed tasks. This allows for the creation of sophisticated systems that can solve multifaceted business problems by breaking them down into smaller, manageable steps handled by specialized agents. - -### Achieve Digital Sovereignty with Self-Hosted LLMs - -For organizations that require absolute control over their data and intellectual property, Mia-Platform supports the deployment and management of LLMs within your own private infrastructure. This approach to digital sovereignty ensures that sensitive information never leaves your trusted environment, meeting the strictest security and compliance requirements. - -### AI-Powered Software Development Lifecycle (SDLC) - -Mia-Platform also integrates AI to enhance the entire development process. The [**AI-Powered SDLC Tool**](/runtime-components/applications/quality-assistant/10_overview.md#ai-powered-sdlc-tool) accelerates development and improves the quality of assets by offering AI-driven requirement evaluation, test coverage estimation, and compliance checks against industry standards. Furthermore, the [**AI-Compliance for Data Catalog**](/runtime-components/applications/data-catalog-ai-compliance/10_overview.md#getting-started) enables even non-technical roles to explore and understand data catalog metadata by means of natural language interactions with an AI Assistant, ultimately simplifying audits and compliance tasks. diff --git a/docs/getting-started/use-cases/application-development.md b/docs/getting-started/use-cases/application-development.md deleted file mode 100644 index b57a58c4b7..0000000000 --- a/docs/getting-started/use-cases/application-development.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: application-development -title: Application Development -sidebar_label: Application Development ---- - -# Application Development - -Traditionally, application development has faced significant delays and friction because of sparse assets and documentation, inadequate tools, and the strong need to rely on other teams. Mia-Platform features a self-service, AI-native ecosystem that turns this slow and fragmented process into a streamlined, intelligent workflow. Modern software creation must cope with dilated times, poor resource allocation and underlying complexities, which hinder innovation and prevent developers from focusing on business logic. Mia-Platform addresses these issues by providing developers with a unified environment and opinionated guidance ("golden paths") to build, manage and deploy scalable, reusable, and high-performance cloud-native applications with unprecedented speed and efficiency. - -The entire end-to-end lifecycle of an application—from initial design and configuration to deployment and monitoring—is managed with full autonomy and security through the [**Mia-Platform Console**](/products/console/overview-dev-suite.md). - -## A Self-Service, Composable Experience - -Composability is the approach that shapes Mia-Platform's own idea of application development. It is enabled by a rich and ever-expanding [**Software Catalog**](/products/console/software-catalog/overview.md). This centralized catalog provides developers with ready-to-use, standardized assets, eliminating bottlenecks and redundancies. Abiding by predefined compliance guardrails, development teams can accelerate product creation by composing brand new solutions or reusing existing services from a variety of well-defined building blocks: - -* [**Plugins**](/runtime-components/plugins/mia-platform-plugins.md)**:** Ready-to-use microservices, typically packaged as Docker images with predefined configurations, designed to solve specific runtime needs and integrate seamlessly into your projects. - -* [**Templates**](/runtime-components/templates/mia_templates.md)**:** Base repositories that serve as a starting point for creating new microservices. They provide developers with direct access to the codebase, ensuring compliance with best practices from day one. - -* [**Examples**](/runtime-components/examples/mia_examples.md)**:** Similar to templates, examples offer sample code addressing specific use-cases, often with more features already implemented to help developers familiarize themselves with the development environment. - -* [**Applications**](/runtime-components/applications/mia_applications.md)**:** Pre-configured bundles of resources—including microservices, endpoints, CRUD collections, and public variables—that can be instantiated with a few clicks to set up complex, working systems rapidly. - -## Building Blocks of a Cloud-Native Application - -Developers can use the Mia-Platform Console to easily design and configure all the fundamental components of a modern digital product in a powerful low-code and no-code environment. - -* [**Microservices**](/products/console/api-console/api-design/services.md)**:** As the core of any application, microservices can be created in seconds from the Marketplace or from an existing Docker image. The Console provides full control over their configuration, including environment variables, resource limits, and runtime probes. - -* [**Endpoints**](/products/console/api-console/api-design/endpoints.md)**:** Services are exposed securely and consistently through an API Gateway. Developers can define endpoints, manage routing, and configure security policies such as authentication and authorization with fine-grained control. - -* [**CRUDs**](/products/console/api-console/api-design/crud_advanced.md)**:** For data-centric services, developers can automatically generate REST APIs for Create, Read, Update, and Delete operations on a MongoDB collection without writing any code. This drastically speeds up the creation of services that need to interact with persistent data. - -* [**Microfrontend Composer**](/products/microfrontend-composer/what-is.md)**:** For building user interfaces, such as backoffices or complex dashboards, the Microfrontend Composer allows developers to design and orchestrate applications using low-code functionalities. It enables the composition of custom pages with web components that can read and write data in real-time. - -## The Development Lifecycle: From Design to Deployment - -Mia-Platform industrializes the entire software development lifecycle, ensuring governance and quality at every stage. - -* **Declarative, Manifest-Driven Configuration:** Every component in the Software Catalog, whether it's a plugin, template, or application, is defined by a declarative [**manifest**](/products/console/software-catalog/items-manifest/overview.md). This manifest is a JSON representation of the component's data and resources, ensuring that all assets are standardized, version-controlled, and managed as code. - -* **Unified Design and Configuration:** All aspects of an application's architecture are configured within the [**Design Area**](/products/console/api-console/api-design/overview.md) of the Console. This provides a single source of truth for microservices, endpoints, data models, and public variables, abstracting away the underlying complexity. - -* **Automated Deployment:** Once the application is designed and configured, it can be deployed to any multi-cloud or on-premise environment with a few clicks. The Console automates the deployment process, allowing developers to release new versions quickly and safely while monitoring resource usage and performance in real-time. diff --git a/docs/getting-started/use-cases/cloud-operations.md b/docs/getting-started/use-cases/cloud-operations.md deleted file mode 100644 index 792135215f..0000000000 --- a/docs/getting-started/use-cases/cloud-operations.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: cloud-operations -title: Cloud Operations -sidebar_label: Cloud Operations ---- - -# Cloud Operations - -Cloud Operations encompass the practices and tools required to manage, monitor, and optimize complex multi-cloud and hybrid environments. The primary challenge is taming the inherent chaos of distributed systems, controlling operational overhead, enforcing security consistently, and optimizing costs without stifling innovation. Mia-Platform addresses these challenges by providing a centralized command center that masters cloud-native infrastructure, embedding best practices for security, reliability, and efficiency by default. - -This approach transforms cloud infrastructure from a mere cost center into a strategic asset, enabling teams to manage complexity with ease, fortify their security posture, and drive both financial and environmental sustainability. - -## Core Pillars of Cloud Operations with Mia-Platform - -Mia-Platform empowers operations teams with a suite of tools and methodologies designed to provide full command over the cloud environment. - -### Infrastructure as Code (IaC) for Consistency - -Mia-Platform champions the Infrastructure as Code (IaC) paradigm, allowing teams to manage and provision their entire infrastructure through machine-readable configurations. This ensures that every deployment is repeatable, scalable, and version-controlled. - -* [**Infrastructure Projects**](/products/console/project-configuration/infrastructure-project.md)**:** A dedicated project type designed for Operations teams to define, version, and deploy infrastructure resources (like Kubernetes clusters, databases, or cloud storage) using tools such as Terraform or OpenTofu. This provides a consistent and controlled workflow for infrastructure changes. - -* [**Custom Resources**](/products/console/design-your-projects/custom-resources/custom-resources.md)**:** Extend the Console's capabilities by defining any custom infrastructure object—from Kubernetes CRDs to serverless functions—as configuration-as-code elements, ensuring they are managed within the same governed lifecycle. - -### Multi & Hybrid Cloud Fleet Command - -Mia-Platform allows you to single-handedly control and orchestrate resources across multiple cloud providers, on-premises environments, and even across a combination of both. - -* [**Cluster Management**](/products/console/company-configuration/clusters-management/connect-and-manage-cluster.mdx)**:** Connect and manage any Kubernetes cluster, whether it's on a major cloud provider (GKE, EKS, AKS) or on-premise. This unified view simplifies the management of distributed infrastructure and enables true hybrid and multi-cloud flexibility. - -### End-to-End Observability - -Gaining deep, actionable insights into the health, performance, and security of your platform and applications is critical. Mia-Platform turns data into decisive operational intelligence and strategic decision-making. - -* [**Integrated Monitoring and Logging**](/products/console/monitoring/introduction.md)**:** The **Runtime Area** of the Console provides a real-time view of all deployed resources, including pods, deployments, and services. It offers direct access to logs, events, and resource metrics. - -* [**Customizable Dashboards**](/products/console/monitoring/dashboard.md)**:** Integrate and display dashboards from monitoring tools like Grafana and Kibana directly within the Console, providing a centralized view of application performance and system health. - -* [**Alerting and Probes**](/products/console/api-console/api-design/microservice-runtime-resources.md)**:** Configure liveness and readiness probes for your services to ensure Kubernetes can effectively manage their lifecycle, and set up alerting rules in tools like Grafana to be notified of issues proactively. - -### Embedded Security and Guardrails - -Security is not an afterthought but is embedded into the fabric of the platform. Mia-Platform enables the deployment of automated policies and controls that enforce security best practices system-wide. - -* [**Automated Security Measures**](/requirements/installation-guidelines/console/paas/security-measures.md)**:** The platform enforces security by default with features like TLS encryption, centralized authentication and authorization flows, and vulnerability management. - -* [**Fine-Grained Access Control**](/products/console/api-console/api-design/authorization.md)**:** Utilize **Rönd**, a lightweight sidecar, to distribute security policy enforcement throughout your application, ensuring that access to sensitive data and operations is strictly controlled. - -### Cloud Economics and Sustainability (FinOps & GreenOps) - -Take command of your cloud spend and drive environmental sustainability by reducing the carbon footprint of your operations. - -* [**Resource Optimization**](/products/console/tutorials/set-requests-limits-of-a-microservice.mdx)**:** The Console provides tools to set and monitor CPU and memory requests, including limits for each microservice, eventually preventing resource waste while optimizing costs. - -* [**Automated Environment Shutdown with Kube-Green**](/requirements/installation-guidelines/console/paas/tools/kube-green.md)**:** Reduce the CO2 footprint of your clusters by automatically shutting down non-production environments (e.g., development, testing) during non-working hours, significantly cutting down on energy consumption and costs. - -By adopting these Cloud Operations practices with Mia-Platform, organizations can achieve a state of operational excellence, managing complexity with confidence and transforming their infrastructure into a powerful engine for innovation. diff --git a/docs/getting-started/use-cases/data-integration.md b/docs/getting-started/use-cases/data-integration.md deleted file mode 100644 index 53d922be6b..0000000000 --- a/docs/getting-started/use-cases/data-integration.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -id: data-integration -title: Data Integration -sidebar_label: Data Integration ---- - -# Data Integration - -Mia-Platform achieves Data Integration with an architectural approach named [**Data Fabric**](/products/fast_data/what_is_fast_data.md), i.e. a cutting-edge solution designed to address common challenges related to data, such as fragmentation, tight coupling, legacy system bottlenecks, and the need for access to real-time information. The primary goal is to decouple data from disparate sources, known as **Systems of Record (SoRs)**, and make it available 24/7, for any digital channel or application. This is achieved by creating a high-performance, consolidated data layer that provides a unified, 360-degree view of business entities. - -Mia-Platform's approach combines the principles of **Data Mesh** and **Data Fabric**, enabling organizations to manage the entire data lifecycle, from collection to exposure, with agility and governance. - -## The Core Challenge: Overcoming Legacy Constraints - -Modern enterprises often struggle to innovate because their critical data is locked within legacy systems. These systems are frequently non-scalable, difficult to query, and become a significant bottleneck, leading to issues such as: - -* **Increased response times** for applications trying to access data. - -* **High load and resource consumption** on source systems, impacting their primary functions. - -* **Data inconsistency** across different channels and applications. - -* **Lack of 24/7 data availability**, with system maintenance or downtime directly affecting business operations. - -Directly querying and aggregating data from these systems on-demand is inefficient and hinders the ability to deliver seamless, real-time digital experiences. - -## Mia-Platform's Solution: The Fast Data Architecture - -To solve these challenges, Mia-Platform provides [**Fast Data**](/products/fast_data/what_is_fast_data.md), a suite of highly configurable, event-driven components that industrialize the process of data integration. The architecture is designed to create a persistent, low-latency data layer that is always available and easy to consume. - -### Building Blocks of Data Integration - -The data integration process in Mia-Platform is built upon a few key concepts and components: - -1. [**Connectors and Change Data Capture (CDC)**](/products/fast_data/concepts/the_basics.md#change-data-capture-cdc)**:** The process begins with ingesting data from the Systems of Record. This is typically achieved using CDC connectors, which capture changes (creations, updates, deletions) in the source databases in near real-time and stream them as events into an event streaming platform like Apache Kafka. This event-driven approach ensures that legacy systems are only touched when data actually changes, effectively offloading them. - -2. [**Projections**](/products/fast_data/concepts/the_basics.md#projection)**:** Once the data events are in Kafka, they are consumed by services like the [**Real-Time Updater**](/products/fast_data/realtime_updater.md). This service is responsible for creating **Projections**, which are standardized, cleaned, and filtered representations of the source data. Projections contain only the fields relevant to the business domain and are stored in a highly scalable NoSQL database like MongoDB. This step ensures data standardization, as different source formats can be cast into a consistent model. - -3. [**Single Views**](/products/fast_data/concepts/the_basics.md#single-view-sv)**:** The ultimate goal of the integration process is to create **Single Views**. A Single View is a pre-aggregated document that combines data from multiple Projections to provide a holistic, 360-degree view of a business entity (e.g., a customer, a product, an order). The [**Single View Creator**](/products/fast_data/single_view_creator.md) service is responsible for this aggregation. Because the data is aggregated on write (i.e., as soon as a related Projection changes) rather than on read, read operations on Single Views are exceptionally fast and efficient. - -### The Data Flow - -The typical data integration flow is as follows: - -* A change occurs in a System of Record. - -* A CDC connector captures this change and produces an event on a Kafka topic. - -* The Real-Time Updater consumes the event, applies any necessary transformations (casting), and updates the corresponding Projection document in MongoDB. - -* The update to the Projection triggers the Single View Creator, which re-aggregates the relevant Single View, ensuring it always reflects the latest data. - -* The updated Single View is now available to be consumed by any application or API, providing a consistent, real-time view of the data. - -## Key Benefits of Mia-Platform's Data Integration - -* **Legacy System Offloading:** Reduces the load on critical source systems by moving read traffic to the highly scalable Single View layer. - -* **24/7 Data Availability:** The Data Fabric provides a persistent data layer that remains available even if source systems are down for maintenance. - -* **Real-Time Data Access:** The event-driven architecture ensures that data is synchronized and aggregated in near real-time, enabling reactive and data-intensive applications. - -* **Data Standardization and Governance:** Data from various sources is transformed into a consistent, governed model, simplifying consumption and ensuring data quality. - -* **Accelerated API and Application Development:** With data readily available in a pre-aggregated and easy-to-consume format, developers can build new APIs and applications much faster, as the complexity of data aggregation is handled by the platform. diff --git a/docs/getting-started/use-cases/platform-engineering.md b/docs/getting-started/use-cases/platform-engineering.md deleted file mode 100644 index f0de94a9c2..0000000000 --- a/docs/getting-started/use-cases/platform-engineering.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: platform-engineering -title: Platform Engineering -sidebar_label: Platform Engineering ---- - -# Platform Engineering - -Platform Engineering is the discipline of designing, building, and maintaining self-service toolchains and workflows that enable development teams to build and deliver software. At its core there is the [**Internal Developer Platform (IDP)**](/getting-started/mia-platform-overview.md), a foundational ecosystem that acts as a centralized hub with self-service access to tools and services, and embedded best-practices, recommendations and guardrails for developers. This allows to release applications faster, more reliably, and with greater autonomy. By treating the platform as a product and developers as its customers, Platform Engineering optimizes the whole software development lifecycle (SDLC), reduces cognitive load, and enforces governance without sacrificing speed. - -This approach evolved from DevOps principles, aiming to solve the complexities of modern cloud-native environments. While DevOps focuses on the cultural and methodological fusion of development and operations, Platform Engineering provides the tangible infrastructure and automated pathways to make those principles a reality. - -## Core Principles of Platform Engineering with Mia-Platform - -Mia-Platform is an AI-Native Developer Platform Foundation that empowers organizations to scale agile and Platform Engineering practices, drive automation and software reuse, streamline data delivery and harness the full potential of AI. - -### Self-Service and Developer Autonomy - -A key goal of Platform Engineering is to empower developers with tools and procedures that compress the SDLC, thus enabling faster value generation. Mia-Platform achieves this by offering a [self-service platform](/products/console/overview-dev-suite.md) where development teams can independently manage the entire lifecycle of their applications. This includes: - -* **Creating and configuring environments** for testing and deployment. -* **Developing microservices** with [standardized, pre-configured CI/CD pipelines](/products/console/deploy/overview.md). -* **Accessing essential resources** like [logging and monitoring](/products/console/monitoring/introduction.md) and infrastructure components without opening tickets or waiting for other teams. - -This self-service model eliminates organizational bottlenecks, reduces friction, and allows developers to focus on writing code and delivering business value. - -### Golden Paths and Standardization - -Platform Engineering, through Internal Developer Platforms (IDPs), encompasses well-defined, built-in workflows, i.e. best practices, recommendations, and security measures for creating and deploying software. Mia-Platform promotes and facilitates the creation of these "golden paths", "paved roads" and "guardrails" through: - -* [**Project Templates**](/products/console/company-configuration/project-blueprint.md)**:** New projects can be started in a few clicks, inheriting pre-configured settings, tools, and CI/CD pipelines. This ensures consistency and adherence to best practices from day one. -* **Reusable Components:** A [software catalog of plugins, templates, and applications](/runtime-components/overview_marketplace.md) accelerates development and promotes the reuse of proven solutions across the organization. -* **Standardized Deployment:** By leveraging a [GitOps methodology](/products/console/deploy/overview.md) and offering integrations with various CI/CD tools like GitLab CI, GitHub Actions, and Jenkins, Mia-Platform ensures a consistent and automated deployment process. - -### Abstraction of Complexity - -Modern cloud-native architectures, often based on Kubernetes, can be overwhelmingly complex. Platform Engineering aims to abstract this complexity from developers. Mia-Platform provides an intuitive user interface and a set of automated tools that manage the underlying infrastructure, allowing developers to: - -* **Manage microservice configurations** without needing deep Kubernetes expertise. -* **Securely expose APIs** through a managed [API Gateway](/runtime-components/plugins/api-gateway/10_overview.md). -* **Monitor application performance and health** via integrated [observability tools](/products/console/monitoring/introduction.md). - -By reducing the cognitive load on developers, Mia-Platform enables them to be more productive and innovative. - -## Building Your Internal Developer Platform (IDP) - -Mia-Platform serves as the foundation for building a robust IDP tailored to your organization's specific needs. An IDP built with Mia-Platform centralizes all necessary tools and resources, providing a unified and cohesive developer experience. Key components include: - -* **A Centralized Console:** A single point of control for designing, deploying, and monitoring applications and infrastructure. -* **An Internal Developer Portal:** The interactive, intelligent interface that allows developers to access platform tools, resources, documentation and services in self-service fashion. -* **A Software Catalog:** A comprehensive registry of all available software components, services, APIs, and microservices within the platform. It helps developers discover and reuse existing assets, but it also feeds AI with contextual knowledge. -* **Automated CI/CD Pipelines:** Integrated and standardized pipelines for continuous integration and delivery. -* **Observability Tools:** Built-in features for monitoring, logging, and tracing. -* **Secure API Management:** Tools for exposing, securing, and managing APIs. - -## Key Benefits - -Adopting a Platform Engineering approach with Mia-Platform delivers significant benefits across the organization: - -* **Increased Developer Productivity:** By providing self-service tools and automating repetitive tasks, developers can focus more on programming and less on infrastructure, leading to a significant reduction in time-to-market. -* **Improved Governance and Security:** Centralized management and standardized templates ensure that all projects adhere to corporate security policies and best practices from the design phase. -* **Enhanced Reliability and Resilience:** Automated deployment pipelines and integrated monitoring tools help identify issues early and ensure the stability of applications in production. -* **Reduced Operational Costs:** Automation, resource optimization, and the reuse of components lead to lower maintenance and operational costs. -* **Greater Accountability:** By providing visibility and traceability throughout the entire DevOps cycle, it becomes easier to manage and monitor the evolution of projects and resource usage. diff --git a/docs/products/console/project-configuration/img/add-infrastructure-component-azure.png b/docs/products/console/project-configuration/img/add-infrastructure-component-azure.png deleted file mode 100644 index 22a554fd08..0000000000 Binary files a/docs/products/console/project-configuration/img/add-infrastructure-component-azure.png and /dev/null differ diff --git a/docs/products/console/project-configuration/img/add-infrastructure-component-gitlab.png b/docs/products/console/project-configuration/img/add-infrastructure-component-gitlab.png deleted file mode 100644 index 306cb8d3ac..0000000000 Binary files a/docs/products/console/project-configuration/img/add-infrastructure-component-gitlab.png and /dev/null differ diff --git a/docs/products/console/project-configuration/img/infrastructure-project-deploy-history.png b/docs/products/console/project-configuration/img/infrastructure-project-deploy-history.png deleted file mode 100644 index 000e6dda98..0000000000 Binary files a/docs/products/console/project-configuration/img/infrastructure-project-deploy-history.png and /dev/null differ diff --git a/docs/products/console/project-configuration/img/infrastructure-project-selection.png b/docs/products/console/project-configuration/img/infrastructure-project-selection.png deleted file mode 100644 index ba34b9a2c9..0000000000 Binary files a/docs/products/console/project-configuration/img/infrastructure-project-selection.png and /dev/null differ diff --git a/docs/products/console/project-configuration/img/pipeline-webhook-warning.png b/docs/products/console/project-configuration/img/pipeline-webhook-warning.png deleted file mode 100644 index 625adcfab3..0000000000 Binary files a/docs/products/console/project-configuration/img/pipeline-webhook-warning.png and /dev/null differ diff --git a/docs/products/console/project-configuration/img/webhook-manual-creation.png b/docs/products/console/project-configuration/img/webhook-manual-creation.png deleted file mode 100644 index db5c5f95c5..0000000000 Binary files a/docs/products/console/project-configuration/img/webhook-manual-creation.png and /dev/null differ diff --git a/docs/products/console/project-configuration/index.md b/docs/products/console/project-configuration/index.md index 64f965c6bf..634ee13239 100644 --- a/docs/products/console/project-configuration/index.md +++ b/docs/products/console/project-configuration/index.md @@ -11,7 +11,10 @@ Within the platform's hierarchy, a "Project" sits beneath a "Company", allowing ## Project types -There are two different Project types, supported in Console: +Console supports the following Project type: - [Application Projects](/products/console/project-configuration/application-project.md): meant for software products development and release -- [Infrastructure Projects](/products/console/project-configuration/infrastructure-project.md): meant for operations teams, leveraging IaC for infrastructure provisioning \ No newline at end of file + +:::note +**Infrastructure Projects** have been deprecated starting from v15.0.0 and can no longer be used. Refer to the [v15.0.0 release notes](/release-notes/v15.0.0) for more information. +::: \ No newline at end of file diff --git a/docs/products/console/project-configuration/infrastructure-project.md b/docs/products/console/project-configuration/infrastructure-project.md deleted file mode 100644 index 01a212515b..0000000000 --- a/docs/products/console/project-configuration/infrastructure-project.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -id: infrastructure-project -title: Infrastructure Projects -sidebar_label: Infrastructure Projects -sidebar_order: 2 ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -**Infrastructure Projects** are a dedicated Project type in the Console for provisioning and managing infrastructure, following the *Infrastructure as Code* (IaC) paradigm. - -They are designed primarily for **Operations teams**, who can use them to define, version, and deploy infrastructure resources while ensuring consistency, transparency, and control over infrastructure changes. - -For example, DevOps teams can use Infrastructure Projects to group all repositories that use tools like [Terraform](https://www.hashicorp.com/en/products/terraform), [OpenTofu](https://opentofu.org), [Microsoft Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep), or others to manage resources. - -By consolidating these repositories, Infrastructure Projects simplify the release and monitoring process. They allow you to deploy a component and follow a two-part process: a validation phase (e.g., the `plan` phase in a Terraform pipeline), where you can review proposed changes and decide whether to proceed, and an execution phase (e.g., the `apply` phase in a Terraform pipeline), where the changes are actually applied. - -These Projects are distinct from traditional [Application Projects](/products/console/project-configuration/application-project.md) as they are specifically designed to manage infrastructure resources, enabling better control, automation, and governance in the context of IaC. They can be connected to multiple repositories containing code and scripts to deploy resources in your infrastructure, providing the ability to deploy quickly with a review of the affected resources. - -:::info -Infrastructure Projects are currently a [**BETA** feature](/release-notes/info/version_policy#feature-preview-and-beta) and are under active development. - -At this time, they only support **GitLab** and **Azure DevOps** repositories with a specific pipeline configuration. Support for other providers will be added in future Console releases. You can find out more in the [technical limitations](#technical-limitations) section below. - -If you want to share your feedback, you can head to the [Community discussion post](https://github.com/mia-platform/community/discussions/612). -::: - -## Creating an Infrastructure Project - -When creating a new Project in your Company, you can select the **Infrastructure** type. -This option unlocks a dedicated setup flow and enables the creation of a Project tailored to infrastructure workflows. - -![Infrastructure Project selection](./img/infrastructure-project-selection.png) - -## Managing Infrastructure Components - -Each Infrastructure Project includes a specific section for managing **infrastructure components**. - -:::info -Currently, it is possible to add components from scratch, referencing existing repositories in the provider of the project. - -In the near future components will be available in the [Software Catalog](/products/console/software-catalog/overview.md), to quickly install components simplifying the configuration and allowing to share -these configurations with other users. -::: - -To create a new infrastructure component from scratch, you need to provide several information, which depends on the type of provider of the project. - - - -If you have a project using GitLab as a provider, these are the information that are required to add a component: - -- **Name**: The name of the component. -- **Repository URL**: The URL of the Git repository where the component's code is hosted. This is used to provide a reference to the user. -- **Branch/tag Name**: The Git branch, tag, or commit that the deployment pipeline will run on. -- **Repository Project ID**: The project ID associated with the Git repository. This is actually used to interact with the Git Provider. - -![Add Infrastructure Component](./img/add-infrastructure-component-gitlab.png) - -As example: - -- **Repository URL**: `https://my.gitlab.host/some/repo` -- **Branch/tag name**: `main` -- **Repository Project ID**: `some/repo` - -:::info -As a _Repository Project ID_, you can use the relative path of the repository or the numeric identifier that you can find in the _Settings_ section of the repository. -::: - - - - -If you have a project using Azure DevOps as a provider, these are the information that are required to add a component: - -- **Name**: The name of the component. -- **Repository URL**: The URL of the Git repository where the component's code is hosted. This is used to provide a reference to the user. -- **Branch/tag Name**: The Git branch, tag, or commit that the deployment pipeline will run on. -- **Repository Organization Name**: The name of the Organization that contains the repository. -- **Repository Project Name**: The name of the repository that contains the code to be deployed. -- **Repository Pipeline ID**: As Azure DevOps allows to configure different pipelines, this is the numeric identifier of the pipeline configured - -![Add Infrastructure Component](./img/add-infrastructure-component-azure.png) - -As example: - -- **Repository URL**: `https://dev.azure.com/my-organization/my-project` -- **Branch/tag name**: `main` -- **Repository Organization Name**: `my-organization` -- **Repository Project Name**: `my-project` -- **Repository Pipeline ID**: `1` - -:::info -The _Repository Pipeline ID_ is not the name of the pipeline, but the identifier that can be found in the settings of the pipeline itself. - -You can alternatively find it by navigating into your pipeline page: on the address bar the `definitionId` value is the pipeline identifier. -::: - - - - -## Deploying your Infrastructure - -From within your Project, you can manage the deployment flow of your infrastructure components by: - -- Running a **plan** to preview proposed infrastructure changes -- Executing an **apply** to confirm and release your infrastructure changes - -This enables control and consistency in your infrastructure. - -### Deploy History - -The **Deploy History** page is useful to better understand which actions have been executed for each infrastructure component of your Project. -In particular this view traces which component has been deployed, together with some additional information. - -![Infrastructure project deploy history](img/infrastructure-project-deploy-history.png) - -#### Pipeline Webhook - -In order to correctly fill up the Deploy History view, an Infrastructure Component must have a webhook associated to its repository on the git Provider. - -The webhook is automatically created upon the Infrastructure Component creation. However, in case the webhook creation fails, a warning message will inform to manually retry the webhook creation from the Infrastructure Components Overview page. - -![Pipeline webhook warning message](img/pipeline-webhook-warning.png) - -If an Infrastructure Component is missing the related webhook on the git Provider, the Component will show highlighted to inform of this issue. On the right side of the Component row, a dedicated action appears to manually retry the webhook creation. - -![Manually create webhook](img/webhook-manual-creation.png) - -## Runtime Visibility - -This feature is currently in [BETA](/release-notes/info/version_policy#feature-preview-and-beta), so the visualization of runtime resources is not natively implemented. - -To get the infrastructure components generated after deployment for each project, you can generate an [Infrastructure Component Runtime Software Catalog item type](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md) on the software catalog from the same pipeline via [miactl](/products/console/software-catalog/items-management/miactl.md). - -Subsequently, this information can be retrieved either by using the Marketplace API or by creating a [Composer extension](/products/console/company-configuration/extensions.md#add-new-extension). - -:::info -To retrieve the information of the available [Infrastructure Component Runtime Software Catalog item type](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md), you can use the following software catalog endpoint and filter by the project of interest: - -```shell -curl -X GET \ - -H "Authorization: Bearer " \ - '/api/marketplace?tenantId=&types=infrastructure-component-runtime' -``` - -::: - -## Access and Permissions - -Currently, all members of a Company can view Infrastructure Projects. -However, only users with the role of **Project Administrator** or **Company Owner** are allowed to perform changes within them. - -## Technical limitations - -As mentioned above, there are still some technical limitations that repositories must conform to in order for Infrastructure Projects to work. - -:::note -All of the following limitations will be soon resolved -::: - -- the repository must be on one of the following: - - _GitLab_ and use _GitLab CI_ - - the GitLab CI pipeline must be composed of two separate jobs named `plan` and `apply` - - _Azure_ and use _Azure Pipelines_ - - the Azure pipeline must be composed of three stages: the first stage has to be named `plan`, the second stage must be a `ManualApproval`, and the thirs stage must be named `apply` -- creation from Marketplace is not supported yet, so you need to create your repository beforehand diff --git a/docs/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md b/docs/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md index 0d7de87f26..06c0ad0567 100644 --- a/docs/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md +++ b/docs/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md @@ -14,8 +14,7 @@ import SchemaViewer from "../snippets/schema_viewer.mdx"; Infrastructure Component Runtime are available starting from the v14 of the Mia-Platform Console. ::: -Infrastructure Component Runtime items are meant to be used in the context of an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md) -to be able to collect [runtime data](/products/console/project-configuration/infrastructure-project.md#runtime-visibility) for visualization within Console. +Infrastructure Component Runtime items are meant to collect runtime data of the infrastructure components deployed by your pipelines, for visualization within Console. To [create or edit](/products/console/software-catalog/items-management/overview.md) an infrastructure Component Runtime item, you need to provide a [manifest](/products/console/software-catalog/items-manifest/overview.md), whose `resources` property should adhere to the following JSON schema. diff --git a/docs/products/console/tutorials/configure-new-company.md b/docs/products/console/tutorials/configure-new-company.md index 0a3c438458..5e8a63137b 100644 --- a/docs/products/console/tutorials/configure-new-company.md +++ b/docs/products/console/tutorials/configure-new-company.md @@ -40,10 +40,6 @@ The configuration process may vary slightly for other providers or cluster types The first step is to connect a Kubernetes cluster. This cluster will be the runtime environment where your applications are deployed and managed. The platform does not create a new cluster but connects to an **existing and pre-configured one** under your management. -:::info -The Console also allows you to create new infrastructure, including clusters, through the [**Infrastructure Project**](/products/console/project-configuration/infrastructure-project.md) feature. However, for the purpose of this onboarding tutorial, we will assume that a pre-configured cluster already exists. -::: - ### Connect a new cluster Inside your Company, navigate to **Infrastructure** > **Clusters** and click **New cluster connection**. diff --git a/docs/products/console/tutorials/create-scorecards.md b/docs/products/console/tutorials/create-scorecards.md index efbf3743dc..e32fa2a097 100644 --- a/docs/products/console/tutorials/create-scorecards.md +++ b/docs/products/console/tutorials/create-scorecards.md @@ -44,7 +44,7 @@ To follow this tutorial, you'll need: The first step is to configure the **Integration Connector Agent**. -For detailed instructions on how to set up the agent and configure scraping for different cloud providers, follow the [official service documentation](/runtime-components/plugins/integration-connector-agent/10_overview.md) and this [tutorial](/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx). +For detailed instructions on how to set up the agent and configure scraping for different cloud providers, follow the [official service documentation](/runtime-components/plugins/integration-connector-agent/10_overview.md). For the purpose of our tutorial, we will configure the **Integration Connector Agent** to interact with an *Azure subscription* and scrape information from **Azure Cloud** and **Azure DevOps**. @@ -74,7 +74,7 @@ Finally, you will also need: All of this information will be saved as secret variables within your Console project. Once you have gathered this data and saved it as secret variables in the project, you can proceed with initializing the **Integration Connector Agent** service from the Marketplace and configuring it. -For the initial setup and basic configuration, please refer to this [documentation](/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx). +For the initial setup and basic configuration, please refer to the [Integration Connector Agent documentation](/runtime-components/plugins/integration-connector-agent/10_overview.md). For this tutorial, you will need to configure the `config.json` ConfigMap as follows: diff --git a/docs/products/console/tutorials/infrastructure-project/create-project-configuration.md b/docs/products/console/tutorials/infrastructure-project/create-project-configuration.md deleted file mode 100644 index cbe53fd144..0000000000 --- a/docs/products/console/tutorials/infrastructure-project/create-project-configuration.md +++ /dev/null @@ -1,421 +0,0 @@ ---- -id: create-project-configuration -title: Create Infrastructure Project -sidebar_label: Create Infrastructure Project -sidebar_order: 1 ---- - - -# Infrastructure Project How To - -## Introduction -The "Infrastructure Project" is a new type of project that allows centralized management of infrastructure resources. -This type of project is exclusively dedicated to managing infrastructure resources and offers specific functionalities for creating, deploying, and managing these resources. - -## Creating a Infrastructure Project - -![IMG 1](./img/1.png) - -From v14 it is possible to create a new type of Project called "Infrastructure Project". -To create a new project, simply access the Console, enter a specific Company, and click on "Create Project". - -![IMG 2](./img/2.png) - -In the General step, under "Project type", select the "Infrastructure" option. - -This choice modifies the standard project creation flow, omitting the Environments step. Unlike traditional Application Projects, an Infrastructure project is not based on a single central repository. Instead, configuration occurs at the group level (or folder level, for providers like GitLab that support this structure). This group serves as a logical container for all repositories associated with the infrastructure project you are creating. You will still be able to configure the visibility of this group. - -![IMG 3](./img/3.png) - -The newly created project will differ from standard ones, as it will only have functionalities dedicated to managing infrastructure resources. -This means, for example, that the Design section (among others) will not be present, and the sidebar menu will only include entries relevant to this type of project. - -Specifically, the available console sections will be: -- Overview: where you can manage Settings, Variables, IAM, and Components, which allow management of infrastructure components. -- Deploy: which will contain a list of initialized Infrastructure Components available for deployment. - -![IMG 4](./img/4.png) - -The Deploy section is very different from the standard one; here, there is no branch selection, environment choice, deploy button, or last deploy information. -Instead, it contains a list of Infrastructure Components initialized in this project that can be deployed. - -## Creating a New Infrastructure Resource - -![IMG 5](./img/5.png) - -In the Overview section, there is a "Components" page that allows management of Infrastructure Components. - -By clicking the "Add Infrastructure" button, currently the only available option is to create a new resource from scratch. - -In the future, it will be possible to create a new resource from a Marketplace of ready-to-use infrastructure components. - -![IMG 6](./img/6.png) - -In the resource creation screen, the following must be specified: -- Resource name: the name to assign to the resource -- Repository URL: the git repository containing the Terraform/OpenTofu code of the resource -- Git ref name: the branch in the git repository where the Terraform/OpenTofu code is located -- Repository project ID: the project ID of the git repository - -## Repository example Cloud Storage Bucket - -In the following sections, we will provide an example of a git repository containing Terraform/OpenTofu code for creating a Google Cloud Storage bucket. - -:::info -These are example snippets. Always adapt them to your specific requirements, thoroughly validate all settings (especially variables and secrets), and remember that many effective solutions can be designed differently. -::: - - -Cloud Storage Bucket - - -``` -# Specify the Google Cloud provider -provider "google" { - project = "my-gcp-project-123" # Example GCP project ID - region = "europe-west3" # Example default region -} - -# Create a Google Cloud Storage bucket -resource "google_storage_bucket" "demo_bucket" { - name = "tf-demo-bucket-xyz" # Example unique global bucket name - location = "EUROPE-WEST3" # Example bucket location (region) - storage_class = "NEARLINE" # Example storage class - - # Enable or disable object versioning - versioning { - enabled = true # Enable versioning to keep object history - } - - # Lifecycle rule to transition or delete old objects - lifecycle_rule { - action { - type = "SetStorageClass" # Transition objects to a cheaper storage class - storage_class = "COLDLINE" - } - condition { - age = 30 # Apply transition after objects are older than 30 days - } - } -} -``` - - - - -## Example of a terraform code for creating a GKE Cluster in Google - -In the following sections, we will provide an example of a git repository containing terraform code for creating a GKE Cluster in Google. - -:::info -These are example snippets. Always adapt them to your specific requirements, thoroughly validate all settings (especially variables and secrets), and remember that many effective solutions can be designed differently. -::: - - - -GKE Cluster - - -``` -# Configure the Google Cloud provider provider -provider "google" { - project = "my-gcp-project-123" # Replace with your GCP project ID - region = "europe-west3" # Default region for resources -} - -# Create a GKE cluster without the default node pool -resource "google_container_cluster" "demo_gke" { - name = "tf-demo-gke-cluster" # Cluster name - location = "europe-west3" # Cluster location (region or zone) - remove_default_node_pool = true # We’ll create a custom node pool below - - networking { - network = "default" # Use the default VPC; for a custom network, reference a google_compute_network resource - } - - # Enable Kubernetes API services - addons_config { - http_load_balancing {} - horizontal_pod_autoscaling {} - } -} - -# Create a dedicated node pool for the cluster -resource "google_container_node_pool" "demo_nodes" { - name = "tf-demo-node-pool" - cluster = google_container_cluster.demo_gke.name - location = google_container_cluster.demo_gke.location - node_count = 3 # Number of VM instances in this pool - - node_config { - machine_type = "e2-medium" # VM size - oauth_scopes = [ - "https://www.googleapis.com/auth/cloud-platform", # Full access to GCP APIs (consider narrower scopes for production) - ] - labels = { - env = "demo" - } - tags = ["k8s-node"] - } - - # Auto-upgrade and auto-repair for node instances - management { - auto_upgrade = true - auto_repair = true - } -} - -``` - - - - -## Example of a terraform code for creating a database MongoDB Atlas - -In the following sections, we will provide an example of a git repository containing terraform code for creating a MongoDB Atlas database. - -:::info -These are example snippets. Always adapt them to your specific requirements, thoroughly validate all settings (especially variables and secrets), and remember that many effective solutions can be designed differently. -::: - - -MongoDB Atlas - - -``` -## Configure the MongoDB Atlas provider -provider "mongodbatlas" { - # IMPORTANT: Replace with your actual API keys. - # For better security, consider using environment variables: - # export MONGODB_ATLAS_PUBLIC_KEY="your_public_key" - # export MONGODB_ATLAS_PRIVATE_KEY="your_private_key" - public_key = "" # Your Atlas API public key - private_key = "" # Your Atlas API private key -} - -# Create an Atlas Project -resource "mongodbatlas_project" "demo_project" { - name = "tf-demo-project" # Logical name of your project - # IMPORTANT: Replace with your actual Atlas Organization ID. - # For better security, consider using environment variables: - # export MONGODB_ATLAS_ORG_ID="your_org_id" - org_id = "" # Your Atlas Organization ID -} - -# Create an Atlas MongoDB cluster -resource "mongodbatlas_cluster" "demo_cluster" { - project_id = mongodbatlas_project.demo_project.id - name = "tf-demo-cluster" # Unique cluster name - provider_name = "AWS" # Cloud provider for the cluster (e.g., AWS, GCP, AZURE) - provider_region_name = "EU_CENTRAL_1" # Region (e.g., EU_CENTRAL_1 for Frankfurt on AWS) - provider_instance_size_name = "M10" # Cluster tier (e.g., M10, M20, M30) - backup_enabled = true # Enable continuous backups - - # (Optional) Specify advanced settings - replication_factor = 3 # Number of nodes in replica set - disk_size_gb = 20 # Storage per node - auto_scaling_disk_gb_enabled = true # Enable disk auto-scaling - - # For M10 and higher tiers, auto_scaling_compute_enabled might also be desired for compute scaling - # auto_scaling_compute_enabled = true - # provider_auto_scaling_compute_min_instance_size = "M10" - # provider_auto_scaling_compute_max_instance_size = "M20" -} - -# Create a database user for your application -resource "mongodbatlas_database_user" "app_user" { - username = "tf_app_user" - # IMPORTANT: Replace with a strong, unique password. DO NOT commit this in plain text. - # Consider using environment variables or a secrets manager. - password = "" - project_id = mongodbatlas_project.demo_project.id - roles { - role_name = "readWrite" - database_name = "admin" # Consider limiting to a specific database for production - } - auth_database_name = "admin" # The authentication database for the user - labels = { - env = "demo" - } -} - -``` - - - -## Deploying the Infrastructure Resource - -![IMG 7](./img/7.png) - -From the Deploy section, you can deploy infrastructure resources. - -Inside, you can see a table listing the created infrastructure resources, with their name and git repository. - -The "Start Plan" button performs a plan operation on the resource, which analyzes the terraform code in the repository and shows what would happen if the described changes were applied. - -The plan essentially informs what will be created, modified, or destroyed in case of applying the resource. - -![IMG 8](./img/8.png) - -Once the plan is executed, its result will show the changes that will occur if the resource is applied. - -If the plan is successful, the resource can be deployed by clicking the "Apply" button. - -## Example of GitLab CI Pipeline to Deploy the Resources - -Of course, the GitLab CI pipeline is essential for deploying the resources. In the following sections, we will provide an example of a GitLab CI pipeline that can be used to deploy the resources. - -:::info -These are example snippets. Always adapt them to your specific requirements, thoroughly validate all settings (especially CI/CD variables and secrets), and remember that many effective solutions can be designed differently. -::: - - -Pipeline - - -``` -# GitLab CI/CD OpenTofu Pipeline: Your Lean Starting Point -# -# Hey there! This pipeline is your foundation for automating OpenTofu with GitLab. -# We're covering the essentials: validating your code, planning changes, and -# applying them safely. -# -# Before you dive in, a few key things you'll need to tailor: -# -# 1. OpenTofu Version: Find `image: ghcr.io/opentofu/opentofu:1.8.2` and set your team's version. -# 2. Cloud Provider Authentication: This is crucial! Look for the `CRITICAL: Cloud Provider Authentication` -# section in `before_script`. You'll need to add your specific cloud login steps there. -# 3. .opentofu.rc (Optional): If you use a custom `.opentofu.rc` for things like private provider -# registries, you can load it using the `TF_CONFIG_RC_CONTENT` CI/CD variable. -# 4. Target Workspace: We use `TF_WORKSPACE` (defaulting to "default"). Set this as a CI/CD -# variable in GitLab to switch between environments like 'dev', 'staging', or 'production'. - -workflow: - rules: - - if: $CI_COMMIT_BRANCH - - if: $CI_MERGE_REQUEST_ID - -default: - image: ghcr.io/opentofu/opentofu:1.8.2 # SET YOUR PREFERRED OPENTOFU VERSION HERE - - before_script: - - | - if [ -n "${TF_CONFIG_RC_CONTENT}" ]; then - echo "${TF_CONFIG_RC_CONTENT}" > "${HOME}/.opentofu.rc" # Changed to .opentofu.rc - echo "INFO: OpenTofu CLI configuration (.opentofu.rc) applied from CI/CD variable." # Changed message - fi - - | - echo "INFO: Preparing for cloud provider authentication..." - # --- YOUR AUTHENTICATION SCRIPT GOES HERE --- - # Example for Google Cloud using a Service Account JSON key: - # if [ -n "${GCP_SA_KEY_JSON}" ]; then - # echo "${GCP_SA_KEY_JSON}" > /tmp/gcp-sa-key.json - # export GOOGLE_APPLICATION_CREDENTIALS="/tmp/gcp-sa-key.json" - # echo "INFO: GCP authentication configured." - # else - # echo "ERROR: GCP_SA_KEY_JSON CI/CD variable not set. Cloud operations will likely fail." - # exit 1 - # fi - # --- END OF YOUR AUTHENTICATION SCRIPT --- - -variables: - TF_IN_AUTOMATION: "true" - TF_WORKSPACE: "default" - GIT_DEPTH: 10 - -.opentofu_cache: &opentofu_cache_definition # Changed cache name - cache: - key: "${CI_PROJECT_ID}-${CI_COMMIT_REF_SLUG}-${TF_WORKSPACE}-opentofu" # Changed cache key name - paths: - - .opentofu # Changed path - - .opentofu.lock.hcl # Changed path - policy: pull-push - -stages: - - validate - - plan - - apply - -validate: - stage: validate - extends: .opentofu_cache # Changed extends - script: - - tofu init -reconfigure -input=false -no-color # Changed 'terraform' to 'tofu' - # You can insert additional static analysis or linter scripts here before `fmt` and `validate`. - # Example: tfsec . --no-color - - tofu fmt -check -recursive -diff -no-color # Changed 'terraform' to 'tofu' - - tofu validate -no-color # Changed 'terraform' to 'tofu' - rules: - - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' - -plan: - stage: plan - extends: .opentofu_cache # Changed extends - script: - - tofu init -reconfigure -input=false -no-color # Changed 'terraform' to 'tofu' - - | - # Ensure the target workspace exists - if ! tofu workspace select "${TF_WORKSPACE}" -no-color; then # Changed 'terraform' to 'tofu' - tofu workspace new "${TF_WORKSPACE}" -no-color # Changed 'terraform' to 'tofu' - fi - # Here you could add scripts to dynamically generate .tfvars files or other preparations. - # Example: ./scripts/generate-tfvars.sh > environment.auto.tfvars - - tofu plan -out=tfplan -input=false -no-color # Changed 'terraform' to 'tofu' - artifacts: - paths: - - tfplan - expire_in: 1 day - rules: - - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' - -apply: - stage: apply - extends: .opentofu_cache # Changed extends - script: - - tofu init -reconfigure -input=false -no-color # Changed 'terraform' to 'tofu' - - tofu workspace select "${TF_WORKSPACE}" -no-color # Changed 'terraform' to 'tofu' - # Custom pre-apply commands (e.g., notifications, last policy controls) - # Example: ./scripts/notify-pre-apply.sh - - tofu apply -auto-approve "tfplan" -input=false -no-color # Changed 'terraform' to 'tofu' - # Custom post-apply commands (e.g., CMDB updates, notifications) - # Example: ./scripts/run-smoke-tests.sh - dependencies: - - plan - rules: - - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' - when: manual - allow_failure: false - -``` - - - - -## Infrastructure Resource Repository - -As already mentioned, the infrastructure resource repository is a git repository that contains the terraform code of the resource and the pipelines needed to deploy it. - -Some key files in your repository are: -- main.tf: the main terraform file, which contains the resource definition and variables required for deployment. -- .gitlab-ci.yml: the GitLab pipeline configuration file, which contains the necessary pipelines to deploy the resource. -- scripts (folder): contains utility scripts necessary for the proper functioning of the project in the console. - -### Scripts folder utility - -The scripts folder can contains utility scripts that are used in the GitLab CI pipeline to perform various tasks, such as: - -* Automate GitLab interactions: Programmatically trigger pipelines, monitor job statuses (like "plan" and "apply"), and fetch logs. -* Simplify Terraform output analysis: Scripts can display "plan" logs directly in the Console. This is crucial for reviewing proposed infrastructure changes before confirming an "apply". -* Enable a controlled deployment workflow: After reviewing the plan, the deployment automation prompts the user for confirmation before proceeding with applying changes, ensuring a deliberate and informed deployment process. -* Centralize configuration and utilities: This includes managing API tokens, initializing Terraform with the correct backend settings, and providing reusable utility functions and type definitions. - -## Troubleshooting - -If you encounter issues during the deployment process, consider the following steps: - -- Ensure your Git repository is accessible and contains valid Terraform code. -- Check if the Git ref (branch or tag) exists and is spelled correctly. -- Review the output of the plan for any potential conflicts or errors. -- Confirm that the .gitlab-ci.yml includes all required jobs for the deployment process. diff --git a/docs/products/console/tutorials/infrastructure-project/img/1.png b/docs/products/console/tutorials/infrastructure-project/img/1.png deleted file mode 100644 index ffb5c6c0ca..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/1.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/2.png b/docs/products/console/tutorials/infrastructure-project/img/2.png deleted file mode 100644 index 02b259302d..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/2.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/3.png b/docs/products/console/tutorials/infrastructure-project/img/3.png deleted file mode 100644 index 08ba197cad..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/3.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/4.png b/docs/products/console/tutorials/infrastructure-project/img/4.png deleted file mode 100644 index 520e874568..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/4.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/5.png b/docs/products/console/tutorials/infrastructure-project/img/5.png deleted file mode 100644 index 3e42747e54..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/5.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/6.png b/docs/products/console/tutorials/infrastructure-project/img/6.png deleted file mode 100644 index 808b170fe0..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/6.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/7.png b/docs/products/console/tutorials/infrastructure-project/img/7.png deleted file mode 100644 index 520e874568..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/7.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/8.png b/docs/products/console/tutorials/infrastructure-project/img/8.png deleted file mode 100644 index 067aee6c8c..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/8.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-add-column-advanced.png b/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-add-column-advanced.png deleted file mode 100644 index a3fa3a33cc..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-add-column-advanced.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-advanced-tenantid.png b/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-advanced-tenantid.png deleted file mode 100644 index dc73a55569..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-advanced-tenantid.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-runtime-tab.png b/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-runtime-tab.png deleted file mode 100644 index b39813dc3c..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-runtime-tab.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation.png b/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation.png deleted file mode 100644 index 4790f82581..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-architecture.png b/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-architecture.png deleted file mode 100644 index fd4b26a58a..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-architecture.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-data-pipeline.png b/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-data-pipeline.png deleted file mode 100644 index 77944266d5..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-data-pipeline.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-design-example.png b/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-design-example.png deleted file mode 100644 index 2d57928604..0000000000 Binary files a/docs/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-design-example.png and /dev/null differ diff --git a/docs/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx b/docs/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx deleted file mode 100644 index e6286c0fd8..0000000000 --- a/docs/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx +++ /dev/null @@ -1,549 +0,0 @@ ---- -id: visualize-infrastructure-project-components-runtime-data-in-console -title: View Infrastructure Runtime Data In Console -sidebar_label: View Infrastructure Project Runtime ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -This tutorial will show you how to collect runtime data from your cloud provider and make it available to your final user in Console. - -The tutorial assumes you have the following prerequisites in place: - -- you have created an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md#creating-an-infrastructure-project) -- you have access to an [Application Project](/products/console/project-configuration/application-project.md) where you can create new microservices - -## Architectural overview - -The objective of this tutorial is to: - -- use the Integration Connector Agent to collect runtime data from your cloud provider and save it within the Mia-Platform Catalog -- display the runtime data in the Console using Platforge Composer-based extensions - -Data will be processed by the Integration Connector Agent following an event-driven approach, -which means that the agent will listen to events coming from the Cloud Provider and process them to update the runtime data in the Catalog. - -To receive events from the Cloud Provider, we will create a set of resources in the Cloud Provider first (such as a Pub/Sub topic in GCP, an EventBridge rule in AWS, or an EventHub in Azure), -then we will configure the Integration Connector Agent to listen to these events and process them. - -Therefore, to reach this goal, we will have to set up the following components: - -- set up the Cloud Provider to send events -- configure the Integration Connector Agent to listen to these events and save them in the Catalog -- create a Platforge Composer-based extension to visualize the data in the Console - -![Architectural overview](./img/visualize-infra-ica-architecture.png) - -### Set up Cloud Provider integration - -As mentioned above, we will need to create some resources in the Cloud Provider in order to receive events from it. - -Each Cloud Provider has its own way to send events, so you will have to follow the specific instructions for your Cloud Provider. - -:::info -To set up the Cloud Provider resources that will send events to your Integration Connector Agent instance, we have prepared a set of Terraform modules that will assist you, -you can find them in the [GitHub Mia-Platform Terraform Integration Connector Agent](https://github.com/mia-platform/terraform-integration-connector-agent) repository. -::: - - - -You will need to: - -- create a new CloudTrail -- create a new SQS queue that will be used to receive events by the Integration Connector Agent -- create a new EventBridge rule that will listen to the CloudTrail events and send them to the SQS queue - -Create your terraform module using the following code snippet: - -```go -module "aws" { - source = "github.com/mia-platform/terraform-integration-connector-agent//modules/aws" - - cloudtrail_name = "awesome-cloudtrail-name" - cloudtrail_bucket_name = "awesome-bucket-name" - - eventbridge_rule_name = "awesome-rule-name" - sqs_queue_name = "awesome-queue-name" -} -``` - -:::tip -To provision the resources you can use an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md), just like you would do with any other terraform module. - -You can also simply run - -```bash -terraform init -terraform plan -terraform apply -``` - -Check out the full example in the [repository example directory](https://github.com/mia-platform/terraform-integration-connector-agent/tree/main/examples/aws). -::: - -:::info -Find out more about the specific steps to create these resources in the [Integration Connector Agent documentation](/runtime-components/plugins/integration-connector-agent/use-cases/infrastructure-import/20_aws_infrastructure_import.md). -::: - - - - -You will need to: - -- enable the Cloud Asset Management API -- create a Pub/Sub topic that will be used to receive events by the Integration Connector Agent -- create a feed to send events from the Asset Management API to the Pub/Sub topic - -Create your terraform module using the following code snippet: - -```go -module "gcp" { - source = "github.com/mia-platform/terraform-integration-connector-agent//modules/google" - - pubsub_topic_name = "awesome-topic-name" - cloud_asset_feed_id = "awesome-feed-id" -} -``` - -:::tip -To provision the resources you can use an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md), just like you would do with any other terraform module. - -You can also simply run - -```bash -terraform init -terraform plan -terraform apply -``` - -Check out the full example in the [repository example directory](https://github.com/mia-platform/terraform-integration-connector-agent/tree/main/examples/gcp). -::: - -:::info -Find out more about the specific steps to create these resources in the [Integration Connector Agent documentation](/runtime-components/plugins/integration-connector-agent/use-cases/infrastructure-import/10_gcp_infrastructure_import.md). -::: - - - - - -You will need to: - -- create a new eventhub -- create a monitor diagnostic settings for exporting administrative log to the created eventhub -- create a storage account with a blob container - -Create your terraform module using the following code snippet: - -```go -module "azure" { - source = "github.com/mia-platform/terraform-integration-connector-agent//modules/azurerm" - - resource_group = "awesome-resource-group" - activity_log_diagnostic_setting_name = "awesome-diagnostic-setting-name" - - eventhub_namespace_name = "awesome-eventhub-namespace" - eventhub_name = "awesome-eventhub-name" - - eventhub_checkpoint_storage_name = "awesome-storage-account-name" -} -``` - -:::tip -To provision the resources you can use an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md), just like you would do with any other terraform module. - -You can also simply run - -```bash -terraform init -terraform plan -terraform apply -``` - -Check out the full example in the [repository example directory](https://github.com/mia-platform/terraform-integration-connector-agent/tree/main/examples/azure). -::: - -:::info -Find out more about the specific steps to create these resources in the [Integration Connector Agent documentation](/runtime-components/plugins/integration-connector-agent/use-cases/infrastructure-import/30_azure_infrastructure_import.md). -::: - - - - -### Configure the Integration Connector Agent - -Now that we have configured the Cloud Provider, we can configure the Integration Connector Agent to listen to the events coming from the Cloud Provider and save them in the Catalog. - -To do so, you can create a new microservice in your Project starting from the [Integration Connector Agent](/runtime-components/plugins/integration-connector-agent/10_overview.md) plugin. - -![Created Integration Connector Agent based microservice in design section](./img/visualize-infra-ica-design-example.png) - -Now that the Integration Connector Agent microservice is created, we can configure the data pipeline that will be used to process the events coming from the Cloud Provider and save them in the Catalog. - -The Data Pipeline will be configured using already available Integration Connector Agent components, and it will be defined -by a specific [source](/runtime-components/plugins/integration-connector-agent/sources/10_overview.md), -a set of [processors](/runtime-components/plugins/integration-connector-agent/processors/10_overview.md), -and a [sink](/runtime-components/plugins/integration-connector-agent/sinks/10_overview.md) that handles the data processing. - -![Data Pipeline visualization](./img/visualize-infra-ica-data-pipeline.png) - -The components that we will use in the Data Pipeline are: - -- Vendor-specific source: there are three different sources depending on the Cloud Provider you are using: - - [`aws-cloudtrail-sqs`](/runtime-components/plugins/integration-connector-agent/sources/50_aws_cloudtrail_sqs.md) for AWS - - [`gcp-cloud-asset-pubsub`](/runtime-components/plugins/integration-connector-agent/sources/30_gcp_pubsub_asset_inventory.md) for GCP - - [`azure-event-hub`](/runtime-components/plugins/integration-connector-agent/sources/40_azure_activity_log_event_hub.md) for Azure - - All of them will listen to the events coming from the Cloud Provider and produce events that will be processed by the Integration Connector Agent. - Additionally, they also provide a webhook that can be used to trigger a full import. -- [`cloud-vendor-aggregator` processor](/runtime-components/plugins/integration-connector-agent/processors/40_cloud_vendor_aggregator.md): -this component will aggregate the events coming from the Cloud Provider and produce a single event for each resource -- [`mapper` processor](/runtime-components/plugins/integration-connector-agent/processors/20_mapper.md): this component will map the event produced by the [`cloud-vendor-aggregator` processor](/runtime-components/plugins/integration-connector-agent/processors/40_cloud_vendor_aggregator.md) -to a format that complies with the [`infrastructure-component-runtime`](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md) item type in the Catalog. -- [`console-catalog` sink](/runtime-components/plugins/integration-connector-agent/sinks/15_console-catalog.md): this sink will save the event in the Catalog, -using the [`infrastructure-component-runtime`](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md) item type - -:::info -We are saving the items using the [`infrastructure-component-runtime`](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md) item type, -which is a specific item type used to store runtime data for infrastructure components. - -You can find more information about this item type in the [Catalog documentation](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md). -::: - - - - - -```json -{ - "integrations": [ - { - "source": { - "type": "aws-cloudtrail-sqs", - "queueUrl": "https://sqs.REGION.amazonaws.com/ACCOUNT_ID/awesome-queue-name", - "region": "REGION", - "accessKeyId": "{{AWS_ACCESS_KEY_ID}}", - "secretAccessKey": { "fromEnv": "AWS_SECRET_ACCESS_KEY" }, - "webhookPath": "/aws" - }, - "pipelines": [ - { - "processors": [ - { - "type": "cloud-vendor-aggregator", - "cloudVendorName": "aws", - "authOptions": { - "accessKeyId": "{{AWS_ACCESS_KEY_ID}}", - "secretAccessKey": { "fromEnv": "AWS_SECRET_ACCESS_KEY" } - } - }, - { - "type": "mapper", - "outputEvent": { - "name": "{{name}}", - "runtimeData": { - "name": "{{name}}", - "type": "{{type}}", - "provider": "{{provider}}", - "location": "{{location}}", - "relationships": "{{relationships}}", - "tags": "{{tags}}", - "timestamp": "{{timestamp}}" - } - } - } - ], - "sinks": [ - { - "type": "console-catalog", - "url": "https://your-console-url.com", - "tenantId": "TENANT_ID", - "clientId": "CLIENT_ID", - "clientSecret": { "fromEnv": "CONSOLE_SERVICE_ACCOUNT_CLIENT_SECRET" }, - "itemType": "infrastructure-component-runtime", - "itemNameTemplate": "{{name}} ({{runtimeData.provider}})" - } - ] - } - ] - } - ] -} -``` - - - - - -```json -{ - "integrations": [ - { - "source": { - "type": "gcp-inventory-pubsub", - "projectId": "GCP_PROJECT_ID", - "topicName": "awesome-topic-name", - "subscriptionId": "GCP_PUBSUB_SUBSCRIPTION_ID", - "ackDeadlineSeconds": 15, - "credentialsJson": { "fromEnv": "GCP_CREDENTIALS_JSON" }, - "webhookPath": "/gcp" - }, - "pipelines": [ - { - "processors": [ - { - "type": "cloud-vendor-aggregator", - "cloudVendorName": "gcp", - "authOptions": { - "credentialsJson": { "fromEnv": "GCP_CREDENTIALS_JSON" } - } - }, - { - "type": "mapper", - "outputEvent": { - "name": "{{name}}", - "runtimeData": { - "name": "{{name}}", - "type": "{{type}}", - "provider": "{{provider}}", - "location": "{{location}}", - "relationships": "{{relationships}}", - "tags": "{{tags}}", - "timestamp": "{{timestamp}}" - } - } - } - ], - "sinks": [ - { - "type": "console-catalog", - "url": "https://your-console-url.com", - "tenantId": "TENANT_ID", - "clientId": "CLIENT_ID", - "clientSecret": { "fromEnv": "CONSOLE_SERVICE_ACCOUNT_CLIENT_SECRET" }, - "itemType": "infrastructure-component-runtime", - "itemNameTemplate": "{{name}} ({{runtimeData.provider}})" - } - ] - } - ] - } - ] -} -``` - - - - - -```json -{ - "integrations": [ - { - "source": { - "type": "azure-activity-log-event-hub", - "subscriptionId": "AZURE_SUBSCRIPTION_ID", - "eventHubNamespace": "awesome-eventhub-namespace", - "eventHubName": "awesome-eventhub-name", - "checkpointStorageAccountName": "awesome-storage-account-name", - "checkpointStorageContainerName": "awesome-storage-container-name", - "tenantId": "AZURE_TENANT_ID", - "clientId": { "fromEnv": "AZURE_CLIENT_ID" }, - "clientSecret": { "fromEnv": "AZURE_CLIENT_SECRET" }, - "webhookPath": "/azure" - }, - "pipelines": [ - { - "processors": [ - { - "type": "cloud-vendor-aggregator", - "cloudVendorName": "azure", - "authOptions": { - "tenantId": "AZURE_TENANT_ID", - "clientId": { "fromEnv": "AZURE_CLIENT_ID" }, - "clientSecret":{ "fromEnv": "AZURE_CLIENT_SECRET" } - } - }, - { - "type": "mapper", - "outputEvent": { - "name": "{{name}}", - "runtimeData": { - "name": "{{name}}", - "type": "{{type}}", - "provider": "{{provider}}", - "location": "{{location}}", - "relationships": "{{relationships}}", - "tags": "{{tags}}", - "timestamp": "{{timestamp}}" - } - } - } - ], - "sinks": [ - { - "type": "console-catalog", - "url": "https://your-console-url.com", - "tenantId": "CONSOLE_TENANT_ID", - "clientId": "CLIENT_ID", - "clientSecret": { "fromEnv": "CONSOLE_SERVICE_ACCOUNT_CLIENT_SECRET" }, - "itemType": "infrastructure-component-runtime", - "itemNameTemplate": "{{name}} ({{runtimeData.provider}})" - } - ] - } - ] - } - ] -} -``` - - - - -### Composer page - -Now that we have configured everything needed to gather runtime data and push it to the Catalog, we can create a Composer page to visualize the data in the Console. - -You can create a new [Composer page Extension](/products/console/company-configuration/extensions.md) in your Company using the *Infrastructure Component Runtime Catalog Table* template. - -![Create composer extension modal highlighting Infrastructure Component Runtime Catalog Table template](./img/visualize-infra-composer-extension-creation.png) - -:::caution -The *Infrastructure Component Runtime Catalog Table* template is meant to consume resources from the Catalog of a specific tenant, -therefore you will have to set the `tenantId` filter in order for the page to work properly. - -You **MUST** set the filter value in the `Runtime` Tab filters settings, -you can do this via UI or by manually editing the Advanced configuration: - - - - -- click on `Tabs` in the layout page left sidebar -- in the right sidebar, under Content, press `Edit property` -- this will open a modal where you can see the list of the available Tabs, select `Runtime` -- now press the `Edit property` button in the *filters* sections -- you should now see the preset filters (see the screenshot below), one being `tenantId` with a placeholder value, change it according to your actual Company ID - -![Runtime Tab filters](./img/visualize-infra-composer-extension-creation-runtime-tab.png) - - - - -Switch to the Advanced tab and search for the `YOUR_TENANT_ID` placeholder string to change it. - -![Advanced configuration of Runtime Tab filters](./img/visualize-infra-composer-extension-creation-advanced-tenantid.png) - - - -::: - -#### Add custom columns - -The asset data contained by catalog items contains several pieces of information that are only displayed in a Modal. - -You can add custom columns to the table by adding a new field in the `dataSchema` property via the Advanced configuration. - -For example, if you want to add a column for the `runtimeData.location` field, you can add the following code in the `dataSchema` property: - -```json -{ - // ... other data schema properties, - "resLocation": { - "type": "string", - "label": "Location", - "order": 20, - "formOptions": { - "readOnly": true, - "hidden": true - }, - "visualizationOptions": { - "tag": "div", - "properties": { - "innerHTML": "{{args.[1].resources.runtimeData.location}}" - }, - "sortable": false - } - } - // ... -} -``` - -![Add Column](./img/visualize-infra-composer-extension-add-column-advanced.png) - -### Extend asset data - -Since we are using the `cloud-vendor-aggregator` Integration Connector Agent Processor the data contained within the event is the -[Asset defined by the processor itself](/runtime-components/plugins/integration-connector-agent/processors/40_cloud_vendor_aggregator.md#processor-overview). - -In certain cases, you may want to enrich the data with additional information, such as information relevant to -the same infrastructure component but coming from a different tool (e.g. a monitoring tool that provides additional information about the infrastructure component). - -In these cases you can build a custom [RPC Processor](/runtime-components/plugins/integration-connector-agent/processors/30_rpc_plugin.md) that will act within the -Integration Connector Agent data pipeline and enrich the data with additional information. - -:::tip -For such a use case consider using the [Integration Connector Agent RPC Plugin Processor Template](https://github.com/mia-platform-marketplace/integration-connector-agent-processor) -to create a new repository containing all the necessary files to build a custom Integration Connector agent image -already paired with a custom RPC Plugin Processor. -::: - -In short your Processor implementation could be something like: - -```go -package main -import ( - "context" - - "github.com/mia-platform/integration-connector-agent/entities" -) - -type Asset struct { - Name string `json:"name"` - Type string `json:"type"` - Provider string `json:"provider"` - Location string `json:"location"` - Relationships []string `json:"relationships"` - Tags map[string]string `json:"tags"` - RawData []byte `json:"rawData"` - Timestamp time.Time `json:"timestamp"` -} - -type AssetWithCustomData struct { - Asset - MyCustomField string `json:"myCustomField"` -} - -type MyProcessor struct { - // Add any fields you need for your plugin -} - -func (p *MyProcessor) Init(config []byte) error { - return nil -} - -func (p *MyProcessor) Process(input entities.PipelineEvent) (entities.PipelineEvent, error) { - originalData := input.Data() - - var originalAsset Asset - if err := json.Unmarshal(originalData, &originalAsset); err != nil { - g.logger.WithError(err).Error("Failed to unmarshal original asset data") - return input, err - } - - newAsset := AssetWithCustomData{ - Asset: originalAsset, - MyCustomField: "This is a custom field", - } - newPayload, err := json.Marshal(newAsset) - if err != nil { - g.logger.WithError(err).Error("Failed to marshal new asset data") - return nil, err - } - - output := input.Clone() - output.WithData(newPayload) - return output, nil -} -``` diff --git a/docs/products/mia-platform-suite/rbac_management.md b/docs/products/mia-platform-suite/rbac_management.md index 4ba01d3b95..1983e07b2b 100644 --- a/docs/products/mia-platform-suite/rbac_management.md +++ b/docs/products/mia-platform-suite/rbac_management.md @@ -23,6 +23,7 @@ Mia-Platform's RBAC system is a centralized service designed for granular access - **Super Admin** — a global administrative role (*...authz:Super Admin*) with full privileges to manage the entire platform. - **Organization Admin** — an administrative role (*...organization-Super Admin:\*) with full privileges limited to a specific organization. - **Tenant Admin** — an administrative role with full privileges limited to a specific tenant. +- **Keycloak Admin** — an identity-management role, distinct from Super Admin/Organization Admin, that manages users at the organization level directly from the organization's dedicated Keycloak console (e.g., adding or removing users from the organization). - **Scope** — defines the extent of a permission: it can be global ('/') or restricted to a specific path (e.g., */\*). - **Decision helper** — a function (*helpers.decision(input)* in *authz/helpers/acl_context.rego*) that evaluates policies and generates the final decision, attaching the *x-mia-acl-context* header. - **Allowed resource actions** — a list of URN permissions assigned to a principal's role within *input.rbac.roles[]*. @@ -141,7 +142,7 @@ In this v15 release, Catalog RBAC management has the following constraints: - **Roles**: cannot be created, modified, or deleted via UX. The available roles are fixed and correspond to those defined in the [Permission Matrix](#permission-matrix) above. - **Groups**: can be created. Groups are the only entity that admins can define in this version, to combine users under a shared set of role assignments. - **Users**: cannot be created. Users can only be **assigned** to existing roles and groups. -- **Permissions**: not yet customizable in this phase permissions are tied to roles as defined in the matrix and cannot be edited individually. +- **Permissions**: not yet customizable in this phase — permissions are tied to roles as defined in the matrix and cannot be edited individually. - **Group scope**: the only scope that can currently be assigned to a group is the **entire tenant**; scoping a group to a specific path or sub-resource is not yet available. ## Detail views diff --git a/docs/solutions/ai-agent-lifecycle/ai-agent-lifecycle-overview.md b/docs/solutions/ai-agent-lifecycle/ai-agent-lifecycle-overview.md deleted file mode 100644 index 47a3e8d50c..0000000000 --- a/docs/solutions/ai-agent-lifecycle/ai-agent-lifecycle-overview.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: ai-agent-lifecycle-overview -title: AI Agent Lifecycle -sidebar_label: AI Agent Lifecycle ---- - -# AI Agent Lifecycle: From Prototyping to Enterprise-Grade Orchestration - -AI Agents are autonomous systems capable of understanding, reasoning, and acting to achieve specific goals. From customer support chatbots powered by Retrieval-Augmented Generation (RAG) to complex, multi-agent workflows that automate business processes, these systems are transforming how companies operate and innovate. However, building, deploying, and managing the lifecycle of AI agents presents a unique set of challenges. - -## The Challenges of the AI Agent Lifecycle - -Developing and operationalizing AI agents goes far beyond simply connecting to an LLM API. Organizations face significant hurdles in: - -* **Complex Setup and Integration**: Building the foundational infrastructure for an AI agent—including data ingestion pipelines, vector databases, frontend interfaces, and secure API exposure—is a complex and time-consuming task. -* **Data Management and Synchronization**: For RAG-based agents, keeping the knowledge base up-to-date with the latest information requires robust data ingestion and embedding generation processes. -* **Orchestration of Multi-Agent Systems**: Many advanced use cases require multiple specialized agents to collaborate. Orchestrating these interactions, managing state, and handling failures in a distributed system is a major architectural challenge. -* **Governance, Security, and Observability**: As AI agents become critical components of business processes, it's essential to govern their behavior, secure their access to data, and monitor their performance and operational health. -* **Lack of Standardization**: Without a unified platform, different teams may build agents using disparate technologies and approaches, leading to a fragmented and difficult-to-maintain AI ecosystem. - -## The Mia-Platform Solution: a Unified Platform for Building and Managing AI Agents - -**Mia-Platform** provides an integrated solution to manage the entire lifecycle of AI agents, from rapid prototyping to the orchestration and governance of complex, enterprise-grade systems. The end-to-end AI agent lifecycle management ensures context-aware applications that remain compliant and are easier to integrate into existing solutions, ultimately accelerating the time-to-market. - -### Rapidly Build RAG Applications with Marketplace Templates - -Get a head start on building conversational AI agents with ready-to-use components from the **Marketplace**. -* **AI RAG Chat Application**: This application provides a complete, production-ready stack for a RAG-based chatbot. It includes the **RAG Chatbot API** for handling data ingestion (from web pages or files) and generating responses, a React-based frontend, and an **API Gateway** for secure exposure. -* **Customizable Templates**: For more advanced use cases, start with the **AI RAG Chat Template**, which provides the full source code. This allows you to customize every aspect of the agent, from the data chunking strategy to the LLM interaction logic, while still benefiting from a standardized foundation. - -### Orchestrate Complex Workflows with the Flow Manager - -For multi-agent systems, the **Flow Manager Service** acts as a powerful orchestration engine. -* **Design Complex Agent Interactions**: Use the no-code **Flow Manager Configurator** to visually design how multiple agents collaborate to complete a task. Define the sequence of operations, handle branching logic, and manage state transitions in a clear, finite state machine model. -* **Decoupled and Resilient Architecture**: Agents (implemented as microservices) are decoupled via a message broker like Kafka. The Flow Manager sends commands to agents and listens for their response events, creating a resilient system that can handle failures and retries gracefully. - -### Govern and Monitor with the Console - -Treat your AI agents as first-class citizens of your software ecosystem. **Mia-Platform Console** provides the tools to manage their entire lifecycle. -* **Unified Deployment and Management**: Deploy and manage your AI agents just like any other microservice. Configure their resources, environment variables, and endpoints from a single, intuitive interface. -* **Runtime Observability**: Use the **Runtime Area** to monitor the health of your agents, stream their logs in real-time, and troubleshoot issues quickly. -* **Security and Governance**: Apply the same robust governance and security policies to your AI agents as you do to the rest of your applications, including **IAM** for access control and centralized API security through the **API Gateway**. - -### Leverage Platform Data with Mia-Assistant - -Mia-Platform not only helps you build external-facing AI agents but also uses AI to improve the platform experience itself. -* **Mia-Assistant**: An AI-powered assistant integrated into the Console that uses data from your **Software Catalog** and runtime environments to answer questions, perform actions (like debugging or deploying), and provide insights into your platform. - -Mia-Platform offers a standardized, integrated and scalable platform that empowers organizations to move beyond simple AI experiments. You can build, manage and govern a robust ecosystem of AI agents that drive real business value. - diff --git a/docs/solutions/ai-agent-lifecycle/building-custom-ai-agent.md b/docs/solutions/ai-agent-lifecycle/building-custom-ai-agent.md deleted file mode 100644 index 5307969c2b..0000000000 --- a/docs/solutions/ai-agent-lifecycle/building-custom-ai-agent.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: building-custom-ai-agent -title: Building a Custom AI Agent and Managing its Full Lifecycle -sidebar_label: Building a Custom AI Agent ---- - -### The Scenario - -A legal tech firm wants to build a highly specialized RAG (Retrieval-Augmented Generation) agent for its lawyers. The agent needs to answer complex legal questions based on a proprietary knowledge base of internal case files, legal documents, and contracts, which are stored in various formats (PDFs, DOCX, and text files). - -### The Challenge - -* **Custom Data Sources**: The knowledge base is not a public website. The agent needs to ingest data from secure, internal file systems and databases. -* **Specialized Data Processing**: Legal documents require a specific data chunking strategy. Simple paragraph-based splitting is not effective. The firm needs to implement a custom logic that understands legal clauses and document structure. -* **Governance and Security**: The data is highly confidential. The agent must be deployed in a secure environment, and access to its configuration and data ingestion APIs must be strictly controlled. -* **Full Lifecycle Management**: The firm needs to manage the agent like any other production application, including versioning, monitoring, logging, and CI/CD. - -### The Solution with Mia-Platform - -The team decides that a pre-built plugin is not flexible enough for their needs. They choose to use the **AI RAG Chat Template** from the **Marketplace** to get a head start, and then use the full power of **Mia-Platform Console** to customize and govern the agent. - -1. **Starting from the Template**: The team creates a new microservice from the "AI RAG Chat Template". This provides them with a Git repository containing a fully functional RAG application's source code, including the backend API and data ingestion logic. - -2. **Customizing the Data Ingestion Logic**: - * The developers clone the repository and modify the data ingestion part of the service. They replace the default web scraper with custom code that connects to their internal document management system. - * They implement a sophisticated data chunking algorithm that splits documents based on legal sections and clauses, ensuring that the context provided to the LLM is always relevant. - * They modify the `/api/embeddings/generateFromFile` endpoint to handle their specific file formats and apply the custom logic. - -3. **Deploying as a Standard Microservice**: The custom agent is a standard microservice within their Mia-Platform project. They manage its entire configuration through the Console's **Design Area**: - * They configure **environment variables** to securely connect to their internal systems. - * They set **CPU and memory requests and limits** to ensure the agent has the resources it needs. - * They configure **health probes** (`/-/healthz`, `/-/readyz`) to allow Kubernetes to manage the agent's health. - -4. **Implementing Governance and Security**: - * **Access Control**: Using the **IAM Portal**, they define who can manage the agent's configuration. Only `Senior Developers` are allowed to modify the service's settings. - * **API Security**: The data ingestion endpoint is secured. In the **Endpoints** section, they configure it to require an **API Key** and a specific **User Group Permission**, ensuring that only authorized internal processes can add new documents to the knowledge base. - -5. **Monitoring and Observability**: Once deployed, the Operations team uses the **Runtime Area** to monitor the agent. They can stream its logs in real-time to check the status of data ingestion jobs, monitor its resource consumption, and troubleshoot any issues. - -### The Outcome - -* **Highly Specialized Solution**: The firm successfully built an AI agent tailored to its unique needs, with custom data connectors and processing logic that would have been impossible with an off-the-shelf solution. -* **Full Development Control**: Starting from a template gave them a significant head start, but they retained full control over the source code, allowing for deep customization and future evolution. -* **Enterprise-Grade Governance**: The AI agent is not a standalone, ungoverned application. It is a fully managed component of their software ecosystem, subject to the same security, deployment, and monitoring standards as all their other microservices. -* **Complete Lifecycle Management**: The team manages the agent's entire lifecycle through the Console, from development and deployment to monitoring and maintenance, ensuring a robust and reliable service for their users. - -This use case demonstrates that Mia-Platform is not just a platform for building agents with pre-built components, but is a comprehensive ecosystem for developing, deploying and governing custom, mission-critical and task-specific AI applications. diff --git a/docs/solutions/ai-agent-lifecycle/leveraging-software-catalog-with-mia-assistant.md b/docs/solutions/ai-agent-lifecycle/leveraging-software-catalog-with-mia-assistant.md deleted file mode 100644 index a0b3d88312..0000000000 --- a/docs/solutions/ai-agent-lifecycle/leveraging-software-catalog-with-mia-assistant.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: leveraging-software-catalog-with-mia-assistant -title: Leveraging the Software Catalog with Mia-Assistant -sidebar_label: Leveraging Software Catalog with Mia-Assistant ---- - -### The Scenario - -An organization has fully embraced Mia-Platform, managing dozens of projects, hundreds of microservices, and a complex cloud infrastructure. As the platform scales, developers and operators find it increasingly difficult to find information and troubleshoot issues efficiently. - -### The Challenge - -* **Information Overload**: Finding specific information—like the owner of a service, its current version in production, or its resource consumption—requires navigating through multiple pages in the Console or querying different systems. -* **High Cognitive Load for Troubleshooting**: When an issue occurs, an operator needs to manually correlate information from different sources. For example, to debug a failing pod, they might need to check its logs, its deployment configuration, recent commits in its Git repository, and the status of its dependencies. -* **Onboarding Complexity**: New team members are overwhelmed by the amount of information and struggle to understand the architecture and dependencies of the systems they are working on. -* **Need for Actionable Insights**: The platform generates a vast amount of data, but turning that data into actionable insights (e.g., identifying optimization opportunities or potential risks) is a manual and time-consuming process. - -### The Solution with Mia-Platform - -The company enables the **AI features** of Mia-Platform Console, turning its platform into an intelligent system that can be queried and managed through natural language. - -1. **Enriching the Software Catalog with Real-Time Data**: The journey begins with data. The team configures the **Integration Connector Agent** to automatically scrape data from their cloud providers (like Azure) and DevOps tools (like GitLab). This data is used to enrich the **Software Catalog**, turning it from a static list of components into a dynamic, real-time representation of their entire software ecosystem. The catalog now knows about every deployed resource, its runtime status, its configuration, and its relationships with other components. - -2. **Enabling AI Capabilities**: In the **Company Settings**, a Company Owner enables the **AI Settings**. This grants **Mia-Assistant**, the AI-powered assistant within the Console, secure access to the enriched data from the Software Catalog and the project configurations. - -3. **Interacting with the Platform via Mia-Assistant**: Now, developers and operators can use Mia-Assistant to get immediate answers and perform actions: - * **A developer** preparing for a release can ask: `"@mia show me the DORA metrics for the checkout project in the last 30 days."` Mia-Assistant queries the platform data and provides an instant report on deployment frequency and change failure rate. - * **An operator** investigating an alert can use the `/debug` command: `"/debug the payment service in production, are there any errors in the logs?"` Mia-Assistant fetches the latest logs from the `payment-service` pod, analyzes them for error patterns, and provides a summary of its findings, often suggesting a root cause. - * **A new team member** trying to understand the architecture can ask: `"@mia what services does the order-service depend on?"` The assistant uses the relationship data in the catalog to provide a clear dependency graph. - * **A platform engineer** can even perform actions: `"@mia deploy the latest version of the user-profile service to the staging environment."` After a confirmation prompt, Mia-Assistant can trigger the deployment pipeline. - -### The Outcome - -* **Drastically Reduced Time to Information**: Team members no longer waste time hunting for information. They get immediate, context-aware answers to their questions through a simple, conversational interface. -* **Accelerated Troubleshooting**: The `/debug` command has become the first step in any troubleshooting process. It automates the initial data gathering and analysis, allowing operators to identify the root cause of issues much faster. -* **Democratized Platform Knowledge**: The institutional knowledge about the platform is no longer confined to a few senior engineers. Anyone can now query the system and get the information they need, which has significantly improved onboarding and collaboration. -* **From Data to Actionable Intelligence**: The platform is no longer just a system for managing configurations; it's an intelligent partner that helps teams make better decisions. Mia-Assistant turns raw data into actionable insights, proactively highlighting risks and suggesting improvements. - -By integrating AI at its core, Mia-Platform Console transforms the developer and operator experience, moving from a traditional UI-based interaction to a conversational, intelligent, and highly efficient way of managing the entire software lifecycle. diff --git a/docs/solutions/ai-agent-lifecycle/orchestrating-multi-agent-ai-workflows.md b/docs/solutions/ai-agent-lifecycle/orchestrating-multi-agent-ai-workflows.md deleted file mode 100644 index 7d868959d3..0000000000 --- a/docs/solutions/ai-agent-lifecycle/orchestrating-multi-agent-ai-workflows.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: orchestrating-multi-agent-ai-workflows -title: Orchestrating Multi-Agent AI Workflows with Mia-Platform Flow Manager -sidebar_label: Orchestrating Multi-Agent AI Workflows ---- - -### The Scenario - -An insurance company wants to automate its claims processing workflow. The process is complex and requires several distinct steps, each with its own specialized logic, making it unsuitable for a single monolithic AI agent. - -### The Challenge - -* **Complex, Multi-Step Process**: A claim process involves: - 1. **Document Analysis**: Extracting information from a submitted claim form (PDF). - 2. **Fraud Detection**: Analyzing the extracted data against historical patterns to flag suspicious claims. - 3. **Policy Verification**: Checking the customer's policy to ensure the claim is valid and covered. - 4. **Customer Communication**: Notifying the customer of the outcome (approved, rejected, or needs more information). -* **Need for Specialized Agents**: Each step requires a different type of expertise. A single LLM or agent would struggle to perform all these tasks optimally. The company needs a system of specialized agents that can collaborate. -* **Resilience and Error Handling**: The process must be resilient. If one agent fails (e.g., the fraud detection service is temporarily unavailable), the entire workflow shouldn't fail irreversibly. The system needs a way to manage state and handle retries or compensation logic. -* **Lack of Orchestration**: Simply having the agents call each other directly (choreography) would create a brittle, tightly coupled system that is hard to debug and maintain. The company needs a central orchestrator. - -### The Solution with Mia-Platform - -The company decides to model the workflow as a saga and use the **Flow Manager Service** to orchestrate a team of specialized AI agents. - -1. **Implementing Specialized AI Agents**: The AI team develops several microservices, each acting as a specialized agent: - * `Document-Analyzer-Agent`: Uses OCR and an LLM to extract structured data from PDFs. - * `Fraud-Detector-Agent`: A machine learning model that scores a claim's fraud risk. - * `Policy-Verifier-Agent`: A rule-based service that checks the claim against the policy database. - * `Notification-Agent`: A service that sends emails to customers. - Each agent is deployed as a standard microservice in the Mia-Platform Console. - -2. **Designing the Workflow with the Flow Manager**: The team uses the **Flow Manager Configurator**, a no-code graphical tool, to design the entire workflow as a finite state machine. - * They define states like `ClaimReceived`, `DocumentAnalyzed`, `FraudCheckComplete`, `ClaimApproved`, `ClaimRejected`. - * For each state transition, they define the **command** to be sent to an agent and the **events** that agent can produce as a response. For example, from the `DocumentAnalyzed` state, the Flow Manager sends a `DetectFraud` command to the `Fraud-Detector-Agent`. - -3. **Decoupled Communication via Kafka**: The Flow Manager and the agents communicate asynchronously via **Kafka**. The Flow Manager publishes commands, and the agents consume them. After processing a command, an agent publishes an event (e.g., `FraudDetected` or `NoFraudDetected`), which the Flow Manager consumes to move the saga to the next state. - -4. **State Persistency and Visibility**: The Flow Manager is configured to persist the state of each claim's saga in a **CRUD** collection. This provides a complete, real-time audit trail. A support agent can, at any time, look up a claim ID and see its exact status in the workflow. - -### The Outcome - -* **Robust and Scalable Automation**: The company has successfully automated a complex, mission-critical business process. The decoupled, event-driven architecture is highly scalable and resilient. -* **Centralized Orchestration and Visibility**: The entire business logic for the workflow is centralized and visualized in the Flow Manager. It's easy for both business analysts and developers to understand and modify the process. If a step fails, it's immediately visible in the saga's state. -* **Specialized and Maintainable Agents**: Each AI agent is a small, focused microservice that does one thing well. This makes them easy to develop, test, and maintain independently. The company can upgrade the fraud detection model without affecting any other part of the system. -* **Foundation for Hyperautomation**: This multi-agent system becomes the foundation for further automation. New agents (e.g., for sentiment analysis on customer emails) can be easily added to the workflow by simply updating the Flow Manager configuration, and they can cooperate and communicate autonomously. - -By using the Flow Manager as an AI agent orchestrator, the company was able to move beyond simple chatbots and implement a sophisticated, resilient, and manageable multi-agent system that automates a core business process. diff --git a/docs/solutions/ai-agent-lifecycle/prototyping-rag-application.md b/docs/solutions/ai-agent-lifecycle/prototyping-rag-application.md deleted file mode 100644 index d17dc8a7f9..0000000000 --- a/docs/solutions/ai-agent-lifecycle/prototyping-rag-application.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: prototyping-rag-application -title: Prototyping a RAG Application in Minutes -sidebar_label: Prototyping a RAG Application ---- - -### The Scenario - -A software company wants to reduce the load on its human support agents by providing a 24/7 chatbot that can answer common questions from users. The source of knowledge for the chatbot is the company's existing public documentation website. - -### The Challenge - -* **Time to Market**: The company wants to validate the idea quickly and needs a working prototype in a matter of days, not months. Building the entire RAG (Retrieval-Augmented Generation) pipeline from scratch is not feasible. -* **Technical Complexity**: The team is skilled in web development but has limited experience with AI/ML infrastructure, such as managing vector databases, generating embeddings, and orchestrating LLM calls. -* **User Interface**: They need a simple and intuitive chat interface for users to interact with the agent, but they don't want to spend significant time on frontend development. -* **Integration**: The final solution needs to be securely exposed via an API and integrated into their main website. - -### The Solution with Mia-Platform - -The team uses the **AI RAG Chat** application from the **Mia-Platform Marketplace** to create and deploy a fully functional RAG chatbot in a few simple steps. - -1. **Installing the RAG Application**: From the **Applications** section in the Design Area, the team searches for and creates the "AI RAG Chat" application. With a few clicks, the wizard automatically sets up all the necessary components in their project: - * The **RAG Chatbot API**: A pre-built microservice that handles all the backend logic. - * The **AI RAG Template Chat**: A React-based frontend providing the chat UI. - * An **API Gateway** with pre-configured endpoints to expose both the frontend and the backend API. - -2. **Configuring the Service**: The team navigates to the `rag-chatbot-api` microservice in the Console. - * They configure the **Environment Variables** with their `MONGODB_CLUSTER_URI` (for the vector database) and their `OPENAI_API_KEY`. These are stored as secure project variables. - * They edit the service's **ConfigMap** to specify the LLM and embedding models they want to use (e.g., `gpt-4o-mini` and `text-embedding-3-small`) and the details of their MongoDB collection. - -3. **Ingesting the Knowledge Base**: The team doesn't need to write any data ingestion scripts. They use the **API Portal** to access the APIs exposed by the `rag-chatbot-api` service. - * They make a single `POST` request to the `/api/embeddings/generate` endpoint. - * In the request body, they provide the URL of their documentation website. - The service automatically starts the web scraping process: it crawls the website, extracts the text content, splits it into chunks, generates embeddings using the OpenAI API, and stores them in the MongoDB Atlas vector database. - -4. **Deploying and Testing**: The team saves the configuration and deploys the project. Immediately after the deployment is complete, the chatbot is live and accessible at the project's main URL. They can start asking questions related to their documentation and receive accurate, context-aware answers. - -### The Outcome - -* **Prototype in Minutes**: The team had a fully functional, end-to-end RAG application up and running in less than an hour, a process that would have taken weeks or months if built from scratch. -* **Zero AI/ML Infrastructure Management**: The team didn't have to worry about the complexities of setting up a vector database, managing embedding pipelines, or orchestrating LLM calls. The Marketplace application abstracted all of this away. -* **Seamless Integration**: The solution came with a ready-to-use frontend and was securely exposed via the API Gateway, making it easy to integrate into their existing web properties. -* **Easy to Customize and Evolve**: While the initial prototype was built with a no-code approach, the team has the option to switch to the **AI RAG Chat Template**, which provides the full source code, allowing them to customize and extend the agent's capabilities in the future. - -The AI RAG Chat application from the Marketplace provided the team with an incredible accelerator, enabling them to rapidly validate their idea and deliver a valuable AI-powered solution to their users with minimal effort. diff --git a/docs/solutions/application-development/accelerating-frontend-development.md b/docs/solutions/application-development/accelerating-frontend-development.md deleted file mode 100644 index ead9763265..0000000000 --- a/docs/solutions/application-development/accelerating-frontend-development.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: accelerating-frontend-development -title: Accelerating Frontend Development with Microfrontend Composer -sidebar_label: Accelerating Frontend Development ---- - -### The Scenario - -A company needs to develop a new internal backoffice application for managing its product catalog. The application must be ready in a few weeks and must provide a modern and intuitive user experience for the operators. The development team is small and doesn't have deep expertise in all the latest frontend frameworks. - -### The Challenge - -* **Tight Deadlines**: The time-to-market is extremely short, making it impossible to develop the entire frontend from scratch. -* **Complex Requirements**: The backoffice needs to include functionalities like a searchable product table, forms for creating and editing products, data visualization dashboards, and user management. -* **Need for Consistency**: The UI must be consistent across all pages, but achieving this with custom development is time-consuming. -* **Integration with Existing Services**: The frontend needs to communicate with an existing CRUD service that exposes the product data. - -### The Solution with Mia-Platform - -The development team decides to use **Mia-Platform Microfrontend Composer** to build the backoffice application through a composable approach, leveraging the no-code/low-code capabilities of the platform. - -1. **Application Setup**: The team starts by creating the **Microfrontend Composer Toolkit** application from the Marketplace. This instantly sets up the necessary services, including the `micro-lc` frontend orchestrator and the webserver to serve the application. - -2. **Creating the Main Page with a Table**: Using the **Page Composer**, the team creates the main page of the backoffice. - * They choose the "Base table" template, which provides a pre-configured page with a table, search bar, and buttons for creating new items. - * In the **Connectors & Adapters** section, they connect the page to the existing `products` CRUD endpoint. They use the "Generate Schema" feature to automatically infer the data structure and configure the table columns. - -3. **Configuring Forms for Data Entry**: The template already includes a **Form Modal**. The team customizes the form by: - * Modifying the `dataSchema` to define which fields are editable and which are required. - * Setting up validation rules directly in the schema to ensure data integrity (e.g., price must be a positive number). - -4. **Adding a Details Page with Cards**: To view the details of a single product, the team creates a new page using the "Show info/details page" template. - * This template uses **Card** components to display information in a clear and organized way. - * They configure a `bk-url-parameters-adapter` to read the product ID from the URL, so the page dynamically fetches and displays the data for the selected product. - * Finally, they add a "Detail" button to each row of the main table that navigates to this new page, passing the product ID in the URL. - -5. **Applying Consistent Styling**: The team customizes the overall look and feel of the application by configuring the **Layout** in the Microfrontend Composer. They set the company logo, choose the primary color to match the corporate branding, and define the structure of the navigation menu. - -### The Outcome - -* **Rapid Development**: The entire backoffice application was built and deployed in a matter of days, not weeks. The no-code/low-code approach allowed the team to focus on the user experience rather than on writing boilerplate code. -* **High-Quality and Consistent UI**: By using the pre-built components from the **Back-kit** library, the team created a modern, responsive, and consistent user interface without needing deep frontend expertise. -* **Easy Integration**: Connecting the frontend to the backend CRUD service was a matter of simple configuration, thanks to the integrated components like the `CRUD Client`. -* **Empowered Team**: The development team was able to deliver a complex application on time, demonstrating that composability drastically streamlines application design and configuration. - -Mia-Platform Microfrontend Composer allowed the team to transform a complex requirement into a fully functional application quickly, proving that modern, high-quality frontends can be built with agility and efficiency. diff --git a/docs/solutions/application-development/application-development-overview.md b/docs/solutions/application-development/application-development-overview.md deleted file mode 100644 index 11309227dc..0000000000 --- a/docs/solutions/application-development/application-development-overview.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: application-development-overview -title: Application Development Overview -sidebar_label: Application Development Overview ---- - -# Application Development: Accelerate the Creation of Cloud-Native Applications - -In a market that demands continuous and rapid innovation, the ability to quickly develop, deploy, and iterate on applications is a critical competitive advantage. Modern application development, especially in a cloud-native context, requires tools that not only speed up coding but also ensure quality, security, and scalability from day one. - -## The Challenges of Modern Application Development - -Development teams often face obstacles that slow down the entire software lifecycle and compromise the final quality of the product: - -* **Repetitive and Low-Value Work**: Developers spend a significant amount of time writing boilerplate code for common functionalities like creating REST APIs for data, managing authentication, or orchestrating processes, instead of focusing on the unique business logic that creates value. -* **Complex Frontend Development**: Building modern, modular, and consistent user interfaces is complex. Integrating different frontend components and ensuring a seamless user experience requires specialized skills and significant effort. -* **Integration with Legacy Systems**: Many organizations rely on existing systems. Exposing data from these systems through modern and secure APIs is often a complex and time-consuming process. -* **Managing Complex Distributed Transactions**: In a microservices architecture, ensuring data consistency across multiple services during a business process (like an e-commerce order) is a major challenge that, if not handled correctly, can lead to data corruption. -* **Lack of Secure and Standardized Exposure**: Exposing APIs securely, managing traffic, and applying consistent authentication and authorization policies for each new service is a repetitive and error-prone task. - -## The Mia-Platform Solution: a Composition-based Approach - -**Mia-Platform Console** provides a suite of tools and ready-to-use building blocks that enable an approach based on **composability and reuse**. Instead of building everything from scratch, developers can assemble applications using pre-built, secure, and scalable components, drastically accelerating the time-to-market. - -### Accelerate Frontend Development with Microfrontend Composer - -The **Microfrontend Composer** is a powerful tool for creating modern user interfaces in a no-code/low-code fashion. Developers can: -* **Visually Compose Pages**: Assemble complex pages by dragging and dropping components from the **Back-kit** library, which includes tables, forms, buttons, and charts. -* **Integrate Any Microfrontend**: Incorporate microfrontends built with any technology (React, Angular, Vue) or even legacy applications via iFrame, creating a consistent and integrated user experience. -* **Build Custom Backoffices in Minutes**: Create data management interfaces and internal tools quickly, connecting them directly to your data sources. - -### Create REST APIs on Your Data in Minutes - -With Mia-Platform, you don't need to write code to create CRUD (Create, Read, Update, Delete) APIs on your data. -* **CRUD Service**: A ready-to-use plugin that automatically exposes REST APIs on any MongoDB collection. Simply define your data model in the Console, and the service will handle the API creation, including pagination, filtering, and sorting. -* **Database and Legacy System Integration**: Connect to existing databases or legacy systems and use the CRUD Service to expose their data through a modern and secure API layer, without modifying the original systems. - -### Orchestrate Complex Processes with the Flow Manager - -For managing distributed transactions and complex business processes, Mia-Platform offers the **Flow Manager Service**. -* **Saga Pattern Orchestration**: Visually design and manage complex sagas that coordinate multiple microservices. The Flow Manager handles state management, error handling, and compensation logic, ensuring data consistency even in the event of failures. -* **Decouple Your Microservices**: Avoid direct and fragile communication between services. The Flow Manager acts as a central orchestrator, making the architecture more resilient and easier to maintain. - -### Secure and Govern Your APIs with an API Gateway - -Every endpoint created in Mia-Platform Console is automatically exposed through an **API Gateway**, which provides a centralized point of control for security and traffic management. -* **Centralized Security**: Apply authentication and authorization policies consistently across all your APIs. Integrate with external Identity Providers (IdP) or use static API keys. -* **API Lifecycle Management**: Manage traffic, apply rate limiting, and get a clear view of how your APIs are being used through the **API Portal**, which provides auto-generated and interactive documentation. - -By adopting Mia-Platform's composition-based approach, development teams can stop reinventing the wheel and focus on what truly matters: generating value and delivering innovative features to their users, faster and more securely. diff --git a/docs/solutions/application-development/building-rest-api.md b/docs/solutions/application-development/building-rest-api.md deleted file mode 100644 index 3045e5d86d..0000000000 --- a/docs/solutions/application-development/building-rest-api.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: building-rest-api -title: Building a REST API on Top of a Legacy Database -sidebar_label: Building a REST API ---- - -### The Scenario - -A retail company has a legacy MongoDB database that contains all of its product inventory information. A new mobile application needs to access this data to show product availability to customers. The development team needs to create a modern, secure, and scalable REST API to expose this data, but they don't have the time or resources to write a dedicated microservice from scratch. - -### The Challenge - -* **Time Constraints**: The project has a very tight deadline, and writing, testing, and deploying a new API layer would take several weeks. -* **Lack of Expertise**: The team primarily consists of frontend developers and lacks deep expertise in backend development and API design best practices. -* **Need for Standard API Features**: The API must support standard features like pagination, filtering, sorting, and projection to be efficient for the mobile app. Implementing these from scratch is complex. -* **Security Requirements**: The data is sensitive, so the API must be secured, and access must be controlled. - -### The Solution with Mia-Platform - -The team decides to use **Mia-Platform Console** to create a secure and fully functional REST API without writing a single line of code. - -1. **Connecting the Database**: First, the team configures the connection to the legacy MongoDB database. They create a **secret variable** in the project's environment settings containing the MongoDB connection string. This ensures that the credentials are kept secure. - -2. **Creating the CRUD Service**: From the **Marketplace**, they add the **CRUD Service** plugin to their project. In the service's environment variables, they reference the MongoDB connection string variable they just created. The CRUD Service is a ready-to-use component that automatically handles the logic for interacting with a MongoDB database. - -3. **Defining the Data Model (CRUD Collection)**: In the **MongoDB CRUD** section of the Design Area, the team defines a new "CRUD Collection" named `products`. - * Instead of manually defining all the fields, they use the **"Import fields from data sample"** feature. They provide a small JSON file with an example of a product document from their legacy database. - * The Console automatically infers the data schema, including field names and types (string, number, boolean, etc.). The team quickly reviews and confirms the schema. - -4. **Exposing the REST API (Endpoint)**: In the **Endpoints** section, they create a new endpoint: - * **Base Path**: `/products` - * **Type**: `CRUD` - * **CRUD Base Path**: They select the `/products` internal endpoint exposed by the CRUD Service. - -5. **Securing the Endpoint**: In the endpoint's security settings, they check the **"Authentication required"** box and define a **User Group Permission** (e.g., `groups.mobile_app`) to ensure that only authenticated clients belonging to the correct group can access the API. - -6. **Deploying the Solution**: The team saves the configuration and deploys the project. - -### The Outcome - -* **API Ready in Minutes**: In less than an hour, the team had a fully functional, production-ready REST API exposing their legacy data. There was no need for backend coding, which would have taken weeks. -* **Rich Features Out-of-the-Box**: The API automatically supports: - * **GET `/products/`**: To list all products, with support for pagination (`_l`, `_sk`), filtering (`_q`), sorting (`_s`), and projection (`_p`). - * **GET `/products/:id`**: To retrieve a single product. - * **POST `/products/`**: To create a new product. - * **PATCH `/products/:id`**: To update a product. - * **DELETE `/products/:id`**: To delete a product. -* **Secure by Design**: The endpoint is protected by the API Gateway and the Authorization Service, ensuring that only authorized requests can access the data. -* **Empowered Frontend Team**: The frontend developers were unblocked immediately and could start developing the mobile app against a real, well-documented API (available in the **API Portal**). - -Mia-Platform Console, with its powerful no-code/low-code components like the CRUD Service, allowed the team to overcome their lack of backend expertise and deliver a critical API on a tight schedule, demonstrating how abstracting common patterns can dramatically accelerate development. diff --git a/docs/solutions/application-development/orchestrating-complex-business-processes.md b/docs/solutions/application-development/orchestrating-complex-business-processes.md deleted file mode 100644 index 839a76fc0f..0000000000 --- a/docs/solutions/application-development/orchestrating-complex-business-processes.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: orchestrating-complex-business-processes -title: Orchestrating Complex Business Processes with Flow Manager -sidebar_label: Orchestrating Complex Business Processes ---- - -### The Scenario - -An e-commerce company is building a new order processing system. The process is complex and involves multiple microservices: one for checking inventory, one for processing payments, and one for arranging shipments. If any of these steps fail, the entire transaction must be rolled back to maintain data consistency. - -### The Challenge - -* **Distributed Transaction Management**: Coordinating actions across multiple services is hard. A simple direct communication (choreography) approach, where services call each other, would create a fragile and tightly coupled system, often called a "distributed monolith". -* **Data Consistency**: If the payment is successful but the shipment fails, how do you handle the refund? Ensuring data consistency across different databases (inventory, payments, shipments) is a major challenge. -* **Error Handling and Compensation**: The system needs robust error handling. For every action, a corresponding "compensation" action (or rollback) must be defined and triggered in case of failure. Managing this logic within each service is complex and duplicates effort. -* **Lack of Visibility**: With a choreographed approach, it's very difficult to understand the overall state of an order. Where did it fail? Why? Diagnosing and debugging problems becomes a nightmare. - -### The Solution with Mia-Platform - -The development team decides to implement the **Saga Pattern** using the **Flow Manager Service**, an orchestration engine available in the Mia-Platform Marketplace. - -1. **Designing the Saga as a Finite State Machine**: First, the team uses the **Flow Manager Configurator**, a no-code graphical interface in the Console, to design the entire order process as a finite state machine. They define the states: - * `OrderCreated` (initial state) - * `InventoryChecked` - * `PaymentProcessed` - * `OrderShipped` (final success state) - * `OrderFailed` (final failure state) - -2. **Defining Commands and Events**: For each state transition, they define **commands** (actions to be performed by other services) and **events** (outcomes of those actions). - * From `OrderCreated`, the Flow Manager sends a `CheckInventory` command. - * The Inventory Service processes the command and responds with either an `InventoryCheckOK` or `InventoryCheckKO` event. - * Based on the event, the Flow Manager moves the saga to the next state (`InventoryChecked` or `OrderFailed`). This logic is repeated for the payment and shipment steps. - -3. **Configuring the Communication Protocol**: The team configures the Flow Manager to communicate with the other microservices via **Kafka**. This creates a decoupled and resilient architecture. The Flow Manager publishes commands on a `commands-topic`, and listens for events on an `events-topic`. - -4. **Implementing the Microservices**: The existing microservices (Inventory, Payment, Shipment) are slightly modified to: - * Consume commands from the Kafka topic. - * Perform their business logic. - * Produce the corresponding outcome event back to the events topic. - They don't need to know anything about the overall process; they just do their job and report the result. - -5. **Persistency and Visibility**: The Flow Manager is configured to use a **CRUD** collection to persist the state of each saga instance. This means that at any time, the team can query the CRUD to know the exact state of a specific order, providing complete visibility into the process. - -### The Outcome - -* **Decoupled and Resilient Architecture**: The microservices are completely decoupled. The Flow Manager is the single source of truth for the process, making the system easier to understand, maintain, and evolve. If a service is temporarily down, the saga remains in its current state, and can be resumed later. -* **Guaranteed Data Consistency**: The Saga pattern ensures that the process is either completed successfully or fully rolled back. The Flow Manager handles the compensation logic (e.g., sending a `RefundPayment` command if the shipment fails), guaranteeing that the system never ends up in an inconsistent state. -* **Centralized Logic and Visibility**: The entire business process is defined and visualized in one place—the Flow Manager Configurator. This makes it easy for both technical and business stakeholders to understand and modify the flow. Debugging becomes simple, as the state of each order is persisted and auditable. -* **Accelerated Development**: The developers of the individual microservices didn't have to worry about the complexity of the overall transaction. They focused solely on their domain logic, leading to faster development and higher quality code. - -The Flow Manager Service allowed the team to tame the complexity of distributed transactions, delivering a robust and reliable order processing system while maintaining a loosely coupled and scalable microservices architecture. diff --git a/docs/solutions/cloud-operations/cloud-operations-overview.md b/docs/solutions/cloud-operations/cloud-operations-overview.md deleted file mode 100644 index 0121e7dfa7..0000000000 --- a/docs/solutions/cloud-operations/cloud-operations-overview.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: cloud-operations-overview -title: Cloud Operations Overview -sidebar_label: Cloud Operations Overview ---- - -# Cloud Operations: Simplify, Secure, and Optimize Your Cloud-Native Infrastructure - -Cloud Operations (CloudOps) encompasses the processes and practices required to manage, secure, and optimize applications and infrastructure in cloud environments. As organizations increasingly adopt multi-cloud and hybrid strategies, CloudOps teams face the challenge of maintaining reliability, controlling costs, and ensuring security across a complex and distributed landscape. - -## The Challenges of Modern Cloud Operations - -Cloud-native environments, while powerful, introduce a new set of operational challenges that can strain resources and increase risk if not managed effectively: - -* **Multi-Cloud and Hybrid Complexity**: Managing disparate environments across different cloud providers (AWS, GCP, Azure) and on-premise data centers leads to fragmented tools, inconsistent processes, and a lack of unified visibility. -* **Ensuring Reliability and Uptime**: Monitoring the health of hundreds of microservices, diagnosing failures in real-time, and ensuring high availability requires advanced observability and rapid troubleshooting capabilities. -* **Cost Optimization**: Without a clear understanding of resource consumption, organizations risk over-provisioning infrastructure, leading to significant and unnecessary cloud spending. Fine-tuning resource requests and limits is a continuous and complex task. -* **Security and Compliance**: Securing a distributed infrastructure, managing access credentials, and ensuring that all deployments comply with security policies is a constant battle. Traditional, manual deployment methods can introduce vulnerabilities. -* **Manual and Error-Prone Deployments**: Relying on custom scripts and manual processes for deployment is not scalable, is prone to human error, and lacks a proper audit trail, making it difficult to meet compliance requirements. - -## The Mia-Platform Solution: a Centralized Control Plane for Your Infrastructure - -**Mia-Platform Console** acts as a unified control plane, providing CloudOps teams with the tools they need to manage the entire operational lifecycle of their cloud-native applications from a single interface. It empowers Ops teams to automate processes, improve security, and optimize costs, all while providing a stable and reliable platform for developers. - -### Unify Multi-Cloud and Hybrid Management - -The Console allows you to connect and manage all your Kubernetes clusters, regardless of where they are running. -* **Centralized Cluster Management**: Add, monitor, and manage clusters from different cloud providers (GKE, EKS, AKS) and on-premise environments from a single dashboard. This provides a unified view of your entire infrastructure. -* **Standardized Deployments**: Deploy applications consistently across any cluster using standardized **Project Blueprints** and CI/CD pipelines, eliminating configuration drift between environments. - -### Proactive Monitoring and Real-Time Troubleshooting - -The **Runtime Area** of the Console offers deep visibility into the health and performance of your deployed applications. -* **Live Pod Monitoring**: View the real-time status of all pods, check their CPU and memory usage, and identify issues like crashes or restarts instantly. -* **Centralized Log Aggregation**: Access and stream logs from any container without needing to use `kubectl` or access the cluster directly. This drastically speeds up troubleshooting. -* **Integrated Dashboards**: Embed your existing Grafana or Kibana dashboards directly into the Console, providing a single pane of glass for both application metrics and operational health. - -### Optimize Resource Usage and Costs - -Mia-Platform provides the tools to right-size your applications and avoid wasted cloud spend. -* **Resource Request & Limit Management**: Easily configure CPU and memory requests and limits for each microservice through a simple UI, preventing resource contention and over-provisioning. -* **Automated Scaling**: Configure **Horizontal Pod Autoscaler (HPA)** to automatically scale your services based on CPU usage, ensuring you only use the resources you need to handle the current load. - -### Adopt a Secure GitOps Deployment Strategy - -Move away from risky, manual deployments by adopting a modern, pull-based GitOps workflow with the **Enhanced Project Workflow**. -* **Git as the Single Source of Truth**: The desired state of your infrastructure and applications is declared in a Git repository. Tools like ArgoCD or Flux can be used to automatically synchronize the cluster's state with the repository. -* **Enhanced Security**: A GitOps approach minimizes the need for direct cluster access. Changes are made through pull requests, providing a clear and auditable workflow. This reduces the attack surface and prevents unauthorized changes. -* **Reliable and Auditable Deployments**: Every change is version-controlled in Git, creating an immutable audit trail. Rolling back to a previous state is as simple as reverting a commit. - -With Mia-Platform Console, CloudOps teams can transition from being reactive firefighters to proactive enablers, building a secure, reliable, and cost-efficient platform that accelerates the entire organization. diff --git a/docs/solutions/cloud-operations/monitoring-and-troubleshooting-runtime.md b/docs/solutions/cloud-operations/monitoring-and-troubleshooting-runtime.md deleted file mode 100644 index 39ffb9b0f7..0000000000 --- a/docs/solutions/cloud-operations/monitoring-and-troubleshooting-runtime.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: monitoring-and-troubleshooting-runtime -title: Monitoring and Troubleshooting Runtime with Mia-Platform Console -sidebar_label: Monitoring and Troubleshooting Runtime ---- - -### The Scenario - -An online retail platform experiences intermittent performance issues during peak traffic hours. The CloudOps team struggles to quickly identify the root cause because they have to manually sift through logs from multiple microservices and correlate events across different systems. - -### The Challenge - -* **Reactive Troubleshooting**: Problems are often reported by users before the Ops team is even aware of them. The team lacks a proactive way to monitor the health of the system. -* **Slow Root Cause Analysis**: When an issue occurs, the team has to SSH into different machines or use multiple `kubectl` commands to get logs from various pods. This process is slow, cumbersome, and requires deep Kubernetes expertise. -* **Information Silos**: Metrics are in one system (Grafana), logs are in another (ELK stack), and Kubernetes events are accessed via the command line. Correlating information between these systems is a manual and time-consuming task. -* **High Mean Time to Resolution (MTTR)**: The combination of these factors leads to a high MTTR, meaning services stay degraded for longer, impacting customer experience and revenue. - -### The Solution with Mia-Platform - -The CloudOps team starts leveraging the **Runtime Area** of **Mia-Platform Console** as their primary tool for monitoring and troubleshooting. - -1. **Centralized Health Dashboard**: The team uses the **Pods** view in the Runtime Area as their main health dashboard. They can see at a glance the status of every pod in a specific environment. The color-coded status indicators (e.g., `OK`, `Warning`) immediately draw their attention to pods that are in a crash loop, pending, or have containers that are not ready. - -2. **Real-Time Log Streaming**: During a period of high traffic, they notice a pod for the `payment-service` turning to a `Warning` state due to frequent restarts. Instead of using `kubectl`, the operator simply clicks on the pod's name directly in the Console. - * They navigate to the **Logs** tab and can immediately stream the logs from the failing container. They discover a recurring `OutOfMemory` error in the logs. - -3. **Inspecting Pod Events**: To understand why the pod is being killed, they switch to the **Events** tab for that pod. They see a series of events from the Kubernetes scheduler indicating that the pod was terminated due to exceeding its memory limit. - -4. **Rapid Remediation**: Having identified the root cause in minutes, the team takes immediate action. - * They navigate back to the **Design Area** of the Console. - * They find the `payment-service` microservice and go to its configuration. - * They increase the **Memory Limit** for the service from `150Mi` to `300Mi`. - * They save the configuration and trigger a deploy to the production environment. - -5. **Verifying the Fix**: After the deploy is complete, they return to the **Runtime Area**. They see the new `payment-service` pod running in a healthy `OK` state. They continue to monitor its resource usage and confirm that the `OutOfMemory` errors have stopped. - -### The Outcome - -* **Drastically Reduced MTTR**: The team was able to identify, diagnose, and resolve a production issue in under 15 minutes, a process that previously could have taken hours. -* **Proactive Monitoring**: The centralized dashboard allowed them to spot the issue as it was happening, before it caused a major outage. -* **Democratized Troubleshooting**: Even junior operators who are not `kubectl` experts can now effectively troubleshoot issues. All the necessary information (pod status, logs, events) is available in an intuitive UI. -* **Integrated Workflow**: The team seamlessly moved from monitoring (Runtime Area) to configuration management (Design Area) and back, all within the same platform, creating a highly efficient feedback loop. - -The Runtime Area of Mia-Platform Console has become the mission control center for the CloudOps team, empowering them to ensure the reliability and performance of their applications proactively and efficiently. diff --git a/docs/solutions/cloud-operations/simplifying-multi-cloud-management.md b/docs/solutions/cloud-operations/simplifying-multi-cloud-management.md deleted file mode 100644 index acdf085579..0000000000 --- a/docs/solutions/cloud-operations/simplifying-multi-cloud-management.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: simplifying-multi-cloud-management -title: Simplifying Multi-Cloud Management with Mia-Platform Console -sidebar_label: Simplifying Multi-Cloud Management ---- - -### The Scenario - -An international corporation has a hybrid cloud strategy. Their production workloads are split between a managed Kubernetes service on AWS (EKS) for scalability and an on-premise Kubernetes cluster for data-sensitive applications. The CloudOps team struggles to manage these two distinct environments. - -### The Challenge - -* **Tool Sprawl**: The team uses different sets of tools and scripts to deploy and monitor applications on EKS versus the on-premise cluster, leading to duplicated effort and increased complexity. -* **Inconsistent Configurations**: Applications deployed on-premise often have slightly different configurations than those on EKS (e.g., for networking or storage), leading to "it works on my cloud" problems and making it difficult to move workloads between environments. -* **Lack of Unified Visibility**: To check the health of the entire system, operators have to switch between different dashboards and terminals (AWS Console, Lens, custom scripts), making it impossible to get a holistic, real-time view. -* **Complex Access Management**: Managing user access and permissions for two separate environments is cumbersome and error-prone, increasing the security risk. - -### The Solution with Mia-Platform - -The CloudOps team adopts **Mia-Platform Console** as a centralized control plane to manage both their AWS and on-premise clusters. - -1. **Connecting All Clusters to the Console**: From the **Clusters** section at the Company level, the team connects both the EKS and the on-premise Kubernetes clusters. They provide the necessary credentials (like service account tokens) for each cluster, and the Console establishes a secure connection. Now, both clusters are visible and manageable from a single interface. - -2. **Standardizing Environments Across Clusters**: In the **Project Blueprint**, they define the company's standard environments (e.g., `Development`, `Staging`, `Production`). They then map these logical environments to the physical clusters: - * `Development` and `Staging` environments are configured to deploy on a specific namespace in the on-premise cluster. - * The `Production` environment is configured to deploy on the EKS cluster in AWS. - -3. **Unified Deployment Process**: The development teams now use a single, consistent process to deploy their applications, regardless of the target cluster. When they trigger a deploy from the Console to the `Production` environment, the pipeline automatically uses the correct credentials and context for the EKS cluster. When they deploy to `Development`, the same pipeline targets the on-premise cluster. This eliminates configuration drift. - -4. **Centralized Monitoring and Observability**: The Ops team uses the **Runtime Area** in the Console to monitor both environments. They can switch between the `Production` (EKS) and `Development` (on-premise) environments with a single click, viewing pod status, streaming logs, and checking resource usage in a unified way. They also embed their Grafana dashboards, which collect metrics from both clusters, directly into the Console's **Dashboard** section. - -### The Outcome - -* **Single Pane of Glass**: The CloudOps team now manages their entire hybrid infrastructure from one place. They have a unified view of all their clusters, namespaces, and applications, drastically reducing operational complexity. -* **Consistent and Portable Workloads**: Since deployments are standardized, applications can be moved between the on-premise and cloud environments with minimal changes, providing true workload portability. -* **Improved Troubleshooting Speed**: When an issue arises, the team doesn't waste time figuring out which tool to use. They go directly to the Console's Runtime Area, select the environment, and start debugging immediately, whether the problem is in the cloud or on-premise. -* **Simplified Governance**: Access control is managed centrally through the Console's IAM, ensuring that user permissions are applied consistently across all connected clusters. Automated policies and controls guarantee security and compliance best practices by design. - -Mia-Platform Console has provided the organization with a powerful abstraction layer over their hybrid infrastructure, enabling teams to take full advantage of multi-cloud without the associated operational overhead. diff --git a/docs/solutions/data-integration/create-real-time-data-aggregation.md b/docs/solutions/data-integration/create-real-time-data-aggregation.md deleted file mode 100644 index 8359442613..0000000000 --- a/docs/solutions/data-integration/create-real-time-data-aggregation.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: create-real-time-data-aggregation -title: Create a Real-Time Data Aggregation with Fast Data Single Views -sidebar_label: Create Real-Time Data Aggregation ---- - -### The Scenario - -A multi-brand retail company has its customer data spread across multiple, disconnected systems. This fragmentation makes it impossible to have a unified understanding of their customers' behavior and preferences. - -### The Challenge - -* **Data Silos**: - * Customer personal information (name, email) is in a **Salesforce CRM**. - * Order history is in an **e-commerce platform**. - * Product browsing history and marketing preferences are in a **HubSpot marketing automation tool**. - * Development team activities and product releases are tracked in **GitHub repositories**. - * Customer support tickets and issue tracking data are stored in **Jira Service Management**. - * Cloud infrastructure logs and security events are scattered across **AWS CloudTrail** and **Azure Activity Logs**. -* **Inconsistent Customer Experience**: When a customer calls support, the agent doesn't have a complete view of their recent orders or marketing interactions, leading to a frustrating and disjointed experience. -* **Ineffective Marketing Campaigns**: The marketing team cannot create personalized campaigns because they cannot segment customers based on their combined purchase and browsing history. -* **Slow Batch Processes**: The company has a nightly batch process that tries to unify this data in a data warehouse, but the information is always stale by up to 24 hours, making real-time personalization impossible. - -### The Solution with Mia-Platform - -The company leverages **Integration Connector Agent** and **Fast Data Engine 2.0** to create a unified, real-time customer 360° view. - -1. **External Data Ingestion**: **Integration Connector Agent** connects to GitHub, Jira, AWS CloudTrail, and Azure Activity Logs, synchronizing development activities, support tickets, and infrastructure events directly into MongoDB collections. - -2. **Real-Time Data Capture**: **Mongezium CDC** captures changes from all data sources (CRM, e-commerce, marketing platforms, and external systems) and streams them to Kafka topics with high performance. - -3. **Data Transformation and Aggregation**: **Farm Data** combines multiple data streams into a unified customer profile, while **Stream Processor** enriches and transforms data using JavaScript logic. - -4. **Unified Single View Creation**: **Kango** persists the aggregated customer data to MongoDB, creating the `customer_sv` collection with complete 360° customer profiles that include traditional business data plus development activities, support interactions, and infrastructure insights. - -5. **API Exposure**: Modern REST APIs expose the unified customer single view, providing millisecond response times for applications requiring complete customer context. - -### The Outcome - -* **Comprehensive 360° Customer View**: The company now has a single, real-time view combining traditional customer data with technical and operational insights. A document in the `customer_sv` collection might look like this: - ```json - { - "email": "jane.doe@example.com", - "name": "Jane Doe", - "crm_info": { ... }, - "order_history": [ { ... }, { ... } ], - "marketing_preferences": { ... }, - "support_tickets": [ { ... } ], - "product_interactions": { ... } - } - ``` -* **Personalized Customer Experience**: The new customer support portal, built with **Microfrontend Composer**, calls the `/customers-sv` endpoint. When a customer calls, the support agent instantly sees their complete history, enabling personalized and efficient service. -* **Targeted and Effective Marketing**: The marketing team can now run highly targeted campaigns. For example, they can create a segment of customers who have viewed a specific product category but have not made a purchase in the last 30 days. -* **Foundation for New Applications**: The `customer_sv` becomes a valuable asset for the entire company. New applications, like a recommendation engine or a loyalty program app, can be built quickly on top of this reliable and real-time data source. - -By leveraging Fast Data Single Views, the company broke down its data silos and transformed its fragmented data into a strategic asset, that is to say unified business data as a product. Single Views are easily discoverable, reusable and governed across all layers of the organization, enabling a new level of personalization and operational efficiency. diff --git a/docs/solutions/data-integration/data-integration-overview.md b/docs/solutions/data-integration/data-integration-overview.md deleted file mode 100644 index 36b1dfa06b..0000000000 --- a/docs/solutions/data-integration/data-integration-overview.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -id: data-integration-overview -title: Data Integration Overview -sidebar_label: Data Integration Overview ---- - -# Data Integration: Unlock and Unify Your Data in Real-Time - -Data Integration is the process of combining data from different sources to provide users with a unified, single view of that data. In modern enterprise architectures, data is often fragmented across various systems of record (SoRs), databases, and third-party applications. This creates data silos that hinder innovation, slow down decision-making, and make it difficult to build cohesive customer experiences. - -## The Challenges of Modern Data Integration - -As companies evolve, they face significant hurdles in making their data accessible, scalable, and consistent across the organization: - -* **Legacy System Bottlenecks**: Many critical business systems (like ERPs, mainframes, or legacy databases) were not designed for the high-volume, low-latency read requests of modern web and mobile applications. Direct queries can easily overload these systems, causing performance degradation and even outages. -* **Data Silos**: Customer, product, and operational data is often scattered across multiple applications (CRM, e-commerce, marketing platforms). Creating a unified view requires complex and fragile point-to-point integrations, which are typically slow batch processes. -* **Lack of Real-Time Insights**: Traditional data integration methods often rely on nightly ETL (Extract, Transform, Load) jobs. This means that business decisions and customer-facing applications are based on data that is up to 24 hours old, which is unacceptable in today's fast-paced market. -* **High Development Cost for Data Access**: For every new application that needs data, developers often have to build custom integration logic, which is time-consuming, duplicates effort, and increases the maintenance burden. - -## The Modern Solution: Integration Connector Agent and Fast Data Engine 2.0 - -**Mia-Platform** addresses these data integration challenges through two complementary technologies: the **Integration Connector Agent** for external data ingestion and the **Fast Data Engine 2.0** for high-performance real-time processing. - -### External Data Ingestion with Integration Connector Agent - -The **Integration Connector Agent** connects to external sources and synchronizes changes between various systems and MongoDB. It supports multiple data sources including GitHub, Jira, Google Cloud Platform, AWS CloudTrail, and Azure Activity Logs. The agent processes data through configurable pipelines and delivers it to MongoDB collections, creating a unified entry point for external data. - -### Real-Time Processing with Fast Data Engine 2.0 - -**Fast Data Engine 2.0** revolutionizes data processing through four specialized workloads that replace traditional monolithic components: - -* **Mongezium CDC**: Captures changes from MongoDB collections and streams them to Kafka topics with high performance and fault tolerance. -* **Stream Processor**: Transforms data using secure JavaScript sandbox environments, supporting both stateless and stateful processing. -* **Farm Data**: Aggregates multiple data streams into one, structured data product. -* **Kango**: Persists processed data from Kafka to MongoDB with optimized throughput and transaction support. - -### Unified Real-Time Data Architecture - -This integrated approach creates a seamless data flow: external sources feed into MongoDB via Integration Connector Agent, changes are captured by Mongezium CDC, data is transformed through Stream Processor, aggregated by Farm Data, and persisted by Kango. The result is a unified, real-time data architecture that eliminates silos and enables immediate insights across all connected systems. - -## Unleashing Business Value from Unified Data - -Once your data integration architecture is in place and single views are persistently stored through Kango, the real business value begins to emerge. The unified, real-time data becomes the foundation for multiple high-impact use cases across the organization. - -### Dashboard and Analytics - -With consolidated single views, building **real-time dashboards** becomes straightforward and performant: - -* **Executive Dashboards**: Create comprehensive views of business KPIs that update in real-time, combining data from sales, marketing, operations, and financial systems. -* **Operational Monitoring**: Build dashboards that monitor system health, transaction volumes, and user behavior patterns with live data updates. -* **Customer 360 Views**: Present unified customer profiles that aggregate data from CRM, e-commerce, support tickets, and interaction history. - -### Machine Learning and AI Integration - -The structured, real-time single views provide the perfect data foundation for **machine learning workflows**: - -* **Feature Engineering**: Use consistently formatted data from multiple sources as features for ML models without complex preprocessing. -* **Real-Time Predictions**: Feed live data directly into ML inference pipelines for dynamic recommendations, fraud detection, or predictive maintenance. -* **Model Training**: Leverage historical single view data for training models with complete, unified datasets rather than fragmented sources. - -### Business Intelligence and Reporting - -Transform decision-making capabilities with **comprehensive BI solutions**: - -* **Cross-Functional Reports**: Generate reports that span multiple business areas by leveraging the unified data model. -* **Trend Analysis**: Perform historical analysis on consistent data structures that maintain referential integrity across all source systems. -* **Data Warehousing**: Export single views to data warehouses for complex OLAP operations and long-term analytical storage. - -### Backoffice Applications - -Empower internal teams with **purpose-built backoffice tools**: - -* **Customer Support Portals**: Build internal tools that provide support agents with complete customer context from multiple touchpoints. -* **Operations Management**: Create administrative interfaces for managing products, orders, and customer data with real-time visibility. -* **Compliance and Auditing**: Develop tools that track data lineage and provide audit trails across all integrated systems. - -### Third-Party Application Integration - -Serve external partners and applications through **standardized data APIs**: - -* **Partner Portals**: Provide external partners with real-time access to relevant business data through secure API endpoints. -* **Mobile Applications**: Power mobile apps with consistent, up-to-date information from the unified data layer. -* **Microservices Architecture**: Support distributed microservices with reliable, real-time data access patterns. - -### Lightweight, On-Demand Aggregation with MongoDB Views - -For simpler use cases that don't require the full power of an event-driven architecture, Mia-Platform Console also supports the creation of **MongoDB Views**: - -* **On-the-Fly Aggregation**: A MongoDB View is a virtual collection whose content is defined by a MongoDB aggregation pipeline that can join data from multiple collections at query time. -* **Simplicity and Speed**: This is a perfect solution for backoffice dashboards or internal tools that need to display combined data without the overhead of creating a new persistent collection or a Fast Data pipeline. - -## Competitive Advantage Through Unified Data - -By leveraging Integration Connector Agent and Fast Data Engine 2.0, organizations can break down data silos, unlock the value of their legacy systems, and build a modern, real-time data integration architecture. The result is not just technical improvement, but a fundamental business advantage: the ability to make data-driven decisions in real-time, deliver superior customer experiences, and rapidly adapt to market changes with complete visibility across all business operations. diff --git a/docs/solutions/data-integration/scaling-legacy-system.md b/docs/solutions/data-integration/scaling-legacy-system.md deleted file mode 100644 index 91eebc8e6c..0000000000 --- a/docs/solutions/data-integration/scaling-legacy-system.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: scaling-legacy-system -title: Scaling a Legacy System of Record with Fast Data Projections -sidebar_label: Scaling a Legacy System ---- - -### The Scenario - -A large insurance company relies on a monolithic, on-premise mainframe system as its System of Record (SoR) for customer policies. This system is reliable for transactional writes but is slow and cannot handle the high volume of read requests from new digital channels, such as a customer-facing web portal and a mobile app. - -### The Challenge - -* **Performance Bottlenecks**: Every time a customer logs into the new portal to view their policy details, a query is sent directly to the mainframe. During peak hours, this high volume of read requests is causing the mainframe to slow down, affecting critical business operations. -* **High Latency for Users**: The slow response times from the SoR result in a poor user experience on the web portal and mobile app, with pages taking several seconds to load. -* **Risk of Outages**: The IT team is concerned that a sudden spike in traffic from the digital channels could overload and crash the mainframe, leading to a major business outage. -* **Development Blockers**: Developers building new features are constrained by the mainframe's limited query capabilities and slow performance, hindering innovation. - -### The Solution with Mia-Platform - -The architecture team leverages **Fast Data Engine 2.0** to create a modern, high-performance read layer that shields the mainframe from traffic spikes, implementing a CQRS (Command Query Responsibility Segregation) pattern. - -1. **Real-Time Data Capture**: **Mongezium CDC** captures all changes from the mainframe's database and streams them to Kafka topics with high throughput and fault tolerance. - -2. **Data Transformation**: **Stream Processor** transforms and enriches the policy data in real-time using secure JavaScript environments, creating optimized data structures for fast querying. - -3. **Data Persistence**: **Kango** persists the processed policy data to MongoDB collections with optimized performance, creating a denormalized, query-ready projection of the mainframe data. - -4. **API Exposure**: The MongoDB projection is exposed through modern REST APIs, providing millisecond response times for policy queries while maintaining data consistency with the source system. - -5. **Traffic Redirection**: Digital channels are redirected to query the high-performance projection layer, while write operations continue to flow to the mainframe as the authoritative source of truth. - -### The Outcome - -* **Drastic Performance Improvement**: The user-facing applications now query the highly performant MongoDB Projection. Page load times are reduced from seconds to milliseconds, significantly improving the customer experience. -* **Legacy System Protection**: The mainframe is completely shielded from high-volume read traffic. Its load is reduced to its core transactional function, eliminating the risk of performance degradation or outages caused by the new digital channels. -* **Developer Empowerment**: Developers can now build new features against a modern, flexible, and fast REST API. They can use the full power of MongoDB queries without worrying about impacting the legacy SoR. -* **Scalability and Elasticity**: The read layer can be scaled independently of the mainframe. If traffic to the portal increases, the company can simply add more replicas of the CRUD Service, ensuring the system remains responsive. - -By using Fast Data, the company successfully modernized its architecture, unlocking the data from its legacy system and enabling the development of fast, modern applications without a costly and risky "big bang" migration. diff --git a/docs/solutions/platform-engineering/automate-infrastructure-provisioning.md b/docs/solutions/platform-engineering/automate-infrastructure-provisioning.md deleted file mode 100644 index f79e6f51d6..0000000000 --- a/docs/solutions/platform-engineering/automate-infrastructure-provisioning.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: automate-infrastructure-provisioning -title: Automate Infrastructure Provisioning with Self-Service -sidebar_label: Automate Infrastructure Provisioning ---- - -### The Scenario - -In an organization that adopts a "you build it, you run it" approach, development teams are responsible for the entire lifecycle of their applications. However, when they need new infrastructure resources (like a database, a message queue, or a storage bucket), they must open a ticket for the Cloud Operations team. - -### The Challenge - -* **Slowness and Bottlenecks**: The ticket-based process is slow. A developer can wait for days to get a new database, effectively blocking the development of new features. -* **Resource Inconsistency**: Manual provisioning by the Ops team can lead to inconsistent configurations. A database might be created with different performance parameters than another, or without the correct backup policies. -* **Excessive Load on the Ops Team**: The Cloud Operations team is swamped with repetitive, low-value requests, diverting time and energy from more strategic activities like cost optimization and security improvement. -* **Lack of Self-Service**: Developers are not truly autonomous. Their speed is limited by the overreliance on another team, which hinders effective DevOps practices implementation. - -### The Solution with Mia-Platform - -The Platform Engineering team decides to create a self-service experience for infrastructure provisioning, using **Infrastructure Projects** and the **Software Catalog** of Mia-Platform Console. - -1. **Creation of an Infrastructure Project**: A new project of type **Infrastructure** is created. This project will not contain applications, but repositories with **Infrastructure as Code (IaC)**, in this case Terraform/OpenTofu. - -2. **Definition of Standard Infrastructure Components**: Within this project, the Ops/Platform team defines reusable and standardized Terraform modules for the most common resources: - * A module to create a **MongoDB Atlas** cluster with pre-configured backup policies. - * A module to create a **Google Cloud Storage Bucket** with versioning and lifecycle policies enabled. - * A module to create an **AWS SQS** queue with server-side encryption. - -3. **Publication in the Software Catalog**: Each Terraform module is "packaged" as an **Infrastructure Component** and published in the company's private **Software Catalog**. Each component has a clear manifest describing its purpose, the required input variables (e.g., `database_name`), and the resources that will be created. - -4. **Self-Service Experience for Developers**: Now, when a developer needs a new database: - * They access their **Application Project** on Mia-Platform Console. - * They go to the **Resources** section and select "Create from Marketplace". - * They search for and select the "MongoDB Atlas Cluster" component. - * They fill out a simple form with the required parameters (e.g., the database name and size). - * Upon saving and deploying, the Console triggers a pipeline (defined in the Infrastructure Project) that automatically and securely runs `terraform plan` and `terraform apply`. - -5. **Approval Workflow (Plan & Apply)**: The deployment is not immediate. The pipeline stops after the `plan`, showing the developer (or a designated approver) the exact impact of the changes. Only after approval does the pipeline proceed with the `apply`, creating the resources in the cloud provider. - -### The Outcome - -* **Speed and Agility**: Developers can provision the infrastructure they need in minutes, in total autonomy, eliminating waiting times. -* **Standardization and Security "by Default"**: All resources are created abiding by embedded best practices defined by the Ops team, who sets the standard. Security guardrails, backup, and monitoring are configured by default, drastically reducing the risk of manual errors. -* **Efficiency of the Ops Team**: The Cloud Operations team no longer handles manual requests but focuses on creating and maintaining IaC modules, a higher-value activity that scales for the entire organization. -* **Full Self-Service and Accountability**: Developers are truly end-to-end responsible for their applications, including the infrastructure they need. The process is fully tracked and governed. - -With Infrastructure Projects, Mia-Platform has extended the principles of the internal platform to infrastructure management, creating a self-service experience that accelerates development and improves collaboration between team Dev and Ops. diff --git a/docs/solutions/platform-engineering/gain-visibility-and-control-across-projects.md b/docs/solutions/platform-engineering/gain-visibility-and-control-across-projects.md deleted file mode 100644 index 257946f756..0000000000 --- a/docs/solutions/platform-engineering/gain-visibility-and-control-across-projects.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -id: gain-visibility-and-control-across-projects -title: Gain Visibility and Control Across Multiple Projects with a Centralized Dashboard -sidebar_label: Gain Visibility and Control Across Projects ---- - -### The Scenario - -A large enterprise with multiple business lines manages dozens of projects on Mia-Platform Console. Over time, it has become nearly impossible for the Platform Engineering team and security managers to get an overview of the state of the applications. - -### The Challenge - -* **Lack of Centralized Visibility**: There is no single point to answer critical questions like: "How many endpoints are publicly exposed without authentication?", "Which services are consuming an excessive amount of CPU?", "Are we using deprecated versions of a plugin?". -* **Difficulty in Enforcing Standards**: Although standards have been defined (e.g., all services must have resource limits configured), verifying their application across all projects is a manual, costly, and error-prone task. -* **Impossible Proactive Risk Identification**: Security or performance issues are discovered only after an incident has occurred, instead of being identified and resolved proactively. -* **Manual and Ineffective Reporting**: Preparing reports for management or audits requires manually collecting data from dozens of different projects, a slow and unreliable process. - -### The Solution with Mia-Platform - -The Platform Engineering team leverages the **Design Overview** of Mia-Platform Console, a Company-level feature that aggregates configuration data from all underlying projects into a single interface for a streamlined, automated developer experience. - -1. **Using Predefined Views**: Upon entering the Design Overview, the team uses the predefined views to get immediate insights: - * **Unprotected Endpoints**: In a few seconds, they identify all endpoints exposed without authentication or API key, creating a priority list for the security team. - * **CPU-intensive services / Memory-intensive services**: They analyze services with resource requests above a predefined threshold, identifying potential areas for cost optimization or performance issues. - * **Replicated services**: They check which services are horizontally scaled, useful for understanding the criticality and expected load for each component. - -2. **Creating Custom Public Views**: To go further, the team creates custom views to monitor compliance with specific company standards: - * **"Services without Log Parser" View**: They create a view filtering all microservices where the `logParser` field is set to `not collected`. This view becomes a fundamental tool for the observability team to ensure that all services produce analyzable logs. - * **"CRUD without Description" View**: They set up a filter on CRUDs where the `description` field is empty. This helps enforce internal documentation policies. - * **"Deprecated Plugin Usage" View**: They create a view that filters services based on a specific Docker image corresponding to a deprecated version of an internal plugin, facilitating migration planning. - -3. **Integration into the Governance Workflow**: These views are not just a visualization tool but become an integral part of the governance process. During weekly reviews, the Platform Engineering team analyzes the views to identify deviations from standards and assigns resolution tickets to the relevant development teams. - -### The Outcome - -* **360-Degree Visibility**: The Platform Engineering team now has a centralized, real-time dashboard on the health and compliance status of all projects, without having to access each one individually. -* **Simplified Enforcement of Standards**: It has become easy and immediate to verify if development teams are following the guidelines, transforming governance from a reactive to a proactive activity. -* **Rapid Risk Identification**: Security risks (open endpoints) and performance risks (oversized services) are identified in minutes, allowing for quick resolution before they become critical problems. -* **Automated and Reliable Reporting**: The views can be exported or shared, providing accurate and up-to-date data for management and audits, eliminating the need for manual collection. - -The Design Overview has transformed how the company governs its software ecosystem, providing the Platform Engineering team with the ultimate tool for visibility, control, and proactive management. diff --git a/docs/solutions/platform-engineering/implement-secure-governance.md b/docs/solutions/platform-engineering/implement-secure-governance.md deleted file mode 100644 index 52a5ab3ac4..0000000000 --- a/docs/solutions/platform-engineering/implement-secure-governance.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: implement-secure-governance -title: Implement Secure Governance with Granular Access Control -sidebar_label: Implement Secure Governance ---- - -### The Scenario - -A financial sector organization must ensure maximum security and compliance for its applications. However, to avoid slowing down release cycles, it wants to give development teams some autonomy while maintaining strict control over critical configurations. - -### The Challenge - -* **Risk of Unauthorized Changes**: Developers, by necessity or by mistake, could modify sensitive configurations in production environments, such as a service's Docker image, an endpoint's security policies, or resource limits. -* **Operational Bottleneck**: To mitigate the risk, the company has mandated that every change in production be approved and applied by the Ops team. This manual process creates queues and drastically slows down the time-to-market. -* **Lack of Guardrails**: Development teams have no clear guidelines on what they can and cannot modify, leading to trial and error and continuous approval requests. -* **Difficult Traceability**: It is difficult to know who changed what and when, making audit and incident response activities complex. - -### The Solution with Mia-Platform - -The Platform Engineering team decides to implement a "railroad framework", which features golden paths, paved roads and guardrails measures, by using the governance features of **Mia-Platform Console**. - -1. **Definition of Roles in IAM**: Using the **IAM Portal** at the Company level, clear roles such as `Developer`, `Senior Developer`, and `Platform Engineer` are defined. Each user is assigned a role based on their responsibilities. - -2. **Configuration of Granular Access Control Rules (Fine-Grained Access Control)**: The core of the solution lies in configuring specific rules that limit actions for each role. From the Company settings, the Platform Engineer sets the following `SaveChangesRules`: - * **Disallow Rule**: A rule is created that **prevents** the `Developer` role from modifying the `dockerImage` field for any microservice. This is a critical security measure to prevent unauthorized deployments in production. - * **Allow Rule**: A rule is configured that allows **only** the `Senior Developer` and `Platform Engineer` roles to modify the security settings of endpoints (such as `Authentication required` or `User Group Permission`). - -3. **Self-Service and Secure Workflow**: Developers continue to work autonomously in the **Design Area** of the Console. When a `Developer` attempts to save a configuration that includes a change to the Docker image, the Console **blocks the save** and displays an error message explaining the rule violation. The developer can then request the change from a `Senior Developer`, who can make it in compliance with the policies. - -4. **Audit Log for Traceability**: Every save attempt, whether successful or failed, and every configuration change are recorded in the **Audit Log**. This provides the security and compliance team with a complete and immutable trace of all activities, simplifying audits and post-incident analysis. - -### The Outcome - -* **Security Integrated into the Workflow**: Security is no longer an external manual process but is integrated directly into the development tools. Developers receive immediate feedback if they attempt an unauthorized action. -* **Elimination of Bottlenecks**: Development teams can deploy autonomously, knowing that automatic "guardrails" will prevent risky changes. The Ops team is freed from routine approval requests. -* **Clear and Automatic Governance**: Access policies are defined declaratively and applied automatically by the platform, ensuring compliance without sacrificing speed. -* **Complete Accountability**: Thanks to the Audit Log, every action is tracked and attributed, increasing responsibility and transparency within the organization. - -Mia-Platform has allowed the company to perfectly balance agility and control, creating a self-service development environment where security is a shared and automated responsibility. diff --git a/docs/solutions/platform-engineering/platform-engineering-overview.md b/docs/solutions/platform-engineering/platform-engineering-overview.md deleted file mode 100644 index 35dc583c14..0000000000 --- a/docs/solutions/platform-engineering/platform-engineering-overview.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: platform-engineering-overview -title: Platform Engineering Overview -sidebar_label: Platform Engineering Overview ---- - -# Platform Engineering: Build and Manage Your Internal Developer Platform - -Platform Engineering is a strategic approach aimed at improving the developer experience and productivity through the creation and management of an **Internal Developer Platform (IDP)**. An IDP is a set of standardized tools, processes, and "golden paths" that enable development teams to operate autonomously, quickly, and securely by abstracting the complexity of the underlying infrastructure. - -The goal is to treat the platform as an internal product, with developers as its customers, to accelerate the delivery of high-quality software. - -## The Challenges of Modern Development - -In today's cloud-native landscape, development teams face increasing complexity that can slow innovation and increase operational risk: - -* **High Cognitive Load**: Developers need to be familiar with a wide range of technologies (Kubernetes, Docker, CI/CD, monitoring), diverting their focus from business logic. -* **Lack of Standardization**: Without defined paths, each team adopts different tools and configurations, leading to a fragmented architecture that is difficult to maintain and govern. -* **Slow Onboarding Processes**: New developers take weeks to become productive as they navigate scattered documentation and complex setups. -* **Governance and Security Risks**: The lack of centralized control exposes the company to risks, with insecure configurations or unregulated access that can compromise the entire infrastructure. -* **Operational Bottlenecks**: Development teams depend on operations (Ops) teams for provisioning resources like databases or test environments, creating long waits. - -## The Mia-Platform Solution: Your Platform as a Product - -**Mia-Platform** is the AI-Native Developer Platform Foundation that enables Platform Engineering teams to build and manage a robust, secure, and customized IDP. The Console transforms the infrastructure from a complex set of tools into a coherent, self-service product to manage the entire software lifecycle. - -### Centralize and Standardize with the Software Catalog - -The **Software Catalog** is the heart of standardization. Platform teams can create and distribute reusable resources such as **Templates**, **Plugins**, and **Infrastructure Components**. This ensures that every new microservice or resource starts from a solid, approved foundation, following opinionated "golden paths." -* **Microservice Standardization**: Create templates with pre-configured logging, health checks, and CI/CD pipelines, ensuring consistency and quality. -* **Code Reuse**: Offer ready-to-use plugins (e.g., CRUD Service, Authorization Service) to accelerate development and reduce duplication. - -### Abstract Complexity with the Console - -Mia-Platform Console provides an intuitive interface that abstracts the complexity of Kubernetes. Developers interact with high-level concepts like **Microservices**, **Endpoints**, and **CRUDs**, without needing to write complex YAML manifests. -* **No-Code/Low-Code Configuration**: Define resources, environment variables, ports, and probes through a graphical interface, reducing errors and cognitive load. -* **Integrated Management**: From design to deployment, through debugging and monitoring, the entire software lifecycle is managed in a single environment. - -### Enable Self-Service for Developers - -With an IDP based on Mia-Platform, developers become autonomous. They can create new environments, deploy their services, and access logs and metrics independently, without relying on other teams. -* **On-Demand Environments**: Create development and test environments in minutes. -* **Simplified Deployment**: Release new versions of applications securely and controlled, with both **push-based (pipeline)** and **pull-based (GitOps)** strategies. - -### Apply Centralized Governance and Security - -The Console offers powerful tools for platform teams to govern access and resource usage. -* **Identity and Access Management (IAM)**: Define roles and groups with specific permissions for Companies, Projects, and Environments. -* **Fine-Grained Access Control**: Set granular rules to prevent changes to critical configurations (e.g., the Docker image in production) by unauthorized roles. -* **Audit Log**: Track every action performed on the platform to ensure accountability and compliance. -* **Security Policies with Rönd**: Integrate authorization policies directly at the microservice level, ensuring security is an intrinsic requirement, not an afterthought. - -### Gain Unprecedented Visibility - -The **Design Overview** at the Company level provides an aggregated view of all resources distributed across various projects. This allows platform teams to: -* Quickly identify unprotected endpoints. -* Monitor services with anomalous resource consumption (CPU/memory). -* Verify the consistency of configurations and compliance with corporate standards. - -By using Mia-Platform Console, Platform Engineering teams can finally build an internal platform that not only solves operational challenges but also becomes a true accelerator and value generator for the entire organization. - - diff --git a/docs/solutions/platform-engineering/standardize-microservices-development.md b/docs/solutions/platform-engineering/standardize-microservices-development.md deleted file mode 100644 index 90658df9fb..0000000000 --- a/docs/solutions/platform-engineering/standardize-microservices-development.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: standardize-microservices-development -title: Standardize Microservice Development with Custom Templates -sidebar_label: Standardize Microservice Development ---- - -### The Scenario - -A rapidly growing company is managing dozens of development teams working on different projects. Each team creates microservices independently, leading to a proliferation of heterogeneous configurations. - -### The Challenge - -* **Inconsistency**: Microservices have different structures, non-uniform logging and monitoring implementations, and CI/CD pipelines written from scratch for each project. -* **Slow Onboarding**: New developers take weeks to understand their team's specific configurations and become productive. -* **Complex Maintenance**: The lack of standards makes maintaining and updating services difficult, increasing the risk of errors in production. -* **Variable Code Quality**: There is no "golden path" for development, so the quality and security of services depend entirely on the skills of the individual team. - -### The Solution with Mia-Platform - -The Platform Engineering team decides to use **Mia-Platform Console** and the **Software Catalog** to create and distribute reusable development standards for the entire company. - -1. **Creation of a Project Blueprint**: First, the team defines a **Project Blueprint** at the Company level. This Blueprint includes pre-configured environments (e.g., Development, Production), default Git and CI/CD providers, ensuring that every new project starts from a common, approved base. - -2. **Development of a Custom Microservice Template**: Next, the team creates a **Template** for a Node.js microservice. This template is not just a "hello world," but a true application skeleton that includes: - * Standardized logging libraries (`lc39`). - * Health check endpoints (`/-/healthz`, `/-/readyz`) already implemented. - * A standard `.gitlab-ci.yml` pipeline that includes steps for linting, unit tests, and security scans. - * A basic configuration for resources (CPU and memory) and Kubernetes probes. - -3. **Publication in the Software Catalog**: The template is published in the company's private **Software Catalog**. It is clearly documented, specifying its purpose and how to use it. It is assigned the "Backend Templates" category for easy searching. - -4. **Self-Service for Developers**: Now, when a development team needs to create a new microservice, they no longer start from scratch. They access the **Microservices** section in Mia-Platform Console, select "Create from Marketplace," and find the "Node.js Standard Service" template approved by the platform team. With a few clicks, the Console: - * Creates a new Git repository by cloning the template. - * Creates the new microservice in the project with all standard configurations already applied. - -### The Outcome - -* **Consistency and Standardization**: All new Node.js microservices follow the same best practices, simplifying management and maintenance. -* **Increased Development Speed**: Teams can create and deploy a new production-ready service in minutes instead of days. -* **Accelerated Onboarding**: New developers are immediately productive, as the service structure and pipelines are already defined and familiar. -* **Quality and Security "by design"**: Security and quality practices are integrated directly into the template, reducing the risk of errors and vulnerabilities. - -Thanks to Mia-Platform, the Platform Engineering team has transformed chaos into an industrial process, providing developers with golden paths and guardrails that makes them faster, more autonomous and more secure. diff --git a/release-notes/v15.0.0.mdx b/release-notes/v15.0.0.mdx index c1523831ca..797e07949b 100644 --- a/release-notes/v15.0.0.mdx +++ b/release-notes/v15.0.0.mdx @@ -93,6 +93,18 @@ The integrated editor provides rich Helm-specific language support, making it ea To learn more about the features available in the new Charts section of the Design Area, and to understand how Git commits of chart configuration files and their deployment are handled via Kustomize, CI/CD pipelines, and MLP, please refer to the [Configure Helm Charts documentation](/docs/products/console/api-console/api-design/charts). +## Infrastructure Projects Deprecation + +:::caution +**Infrastructure Projects are deprecated as of v15.0.0 and can no longer be used.** +The feature never left its [BETA stage](/release-notes/info/version_policy#feature-preview-and-beta) and has now been discontinued. +Starting from v15.0.0 it is no longer possible to create new Infrastructure Projects. +::: + +:::note +This deprecation only affects the **Infrastructure Project** type. [Infrastructure Resources](/docs/products/console/software-catalog/items-manifest/infrastructure-resource) in the Software Catalog and the infrastructure management capabilities of Application Projects are not impacted. +::: + ## Other New Features, Improvements and Bug Fixes diff --git a/sidebars.json b/sidebars.json index f23be25670..40efba677e 100644 --- a/sidebars.json +++ b/sidebars.json @@ -67,21 +67,6 @@ } ] }, - { - "collapsed": true, - "type": "category", - "label": "Infrastructure Project", - "items": [ - { - "id": "products/console/tutorials/infrastructure-project/create-project-configuration", - "type": "doc" - }, - { - "id": "products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console", - "type": "doc" - } - ] - }, { "id": "products/console/tutorials/configure-new-company", "type": "doc" @@ -356,10 +341,6 @@ "id": "products/console/project-configuration/application-project", "type": "doc" }, - { - "id": "products/console/project-configuration/infrastructure-project", - "type": "doc" - }, { "id": "products/console/project-configuration/create-a-project", "type": "doc" diff --git a/versioned_docs/version-15.0.0/getting-started/faqs/mia-platform-console-faqs.md b/versioned_docs/version-15.0.0/getting-started/faqs/mia-platform-console-faqs.md index a0b1f78dc2..afbc6f7115 100644 --- a/versioned_docs/version-15.0.0/getting-started/faqs/mia-platform-console-faqs.md +++ b/versioned_docs/version-15.0.0/getting-started/faqs/mia-platform-console-faqs.md @@ -47,10 +47,6 @@ In the top-right corner of the Design area, click on the branch/revision name to From the branch/revision management popover in the Design area, you can select "Merge from another branch". This will open a diff editor where you can compare the configurations of the source and target branches/revisions side-by-side. You can review all changes, resolve conflicts by editing the configuration directly, and then confirm the merge. The merged configuration must then be saved. [Discover more](/products/console/api-console/api-design/merge_collaboration.md) -#### What are Infrastructure Projects? -Infrastructure Projects are a specialized project type designed for Operations teams and **platform engineers** to manage infrastructure using **Infrastructure as Code** (IaC) principles. Instead of managing applications, these projects manage infrastructure components like cloud resources (e.g., using **Terraform**) or Kubernetes operators. They support a two-phase deployment process (`plan` and `apply`) to ensure changes are reviewed before execution, providing better control over infrastructure provisioning. -[Discover more](/products/console/project-configuration/infrastructure-project.md) - #### How can I delete a Project? You can delete a Project from the **Project Settings -> Advanced** tab. Clicking the "Delete Project" button will open a confirmation modal where you must type the project's name to confirm. This action is irreversible and will remove the project from the Console, with options to also delete associated namespaces and archive the Git repository. [Discover more](/products/console/project-configuration/delete-a-project.md) @@ -221,7 +217,7 @@ Yes. You can configure a **Jenkins** instance as a **CI/CD Tool Provider** at th [Discover more](/products/console/deploy/pipeline-based/configure-jenkins.md) #### How does the Console support different cloud providers like AWS, GCP, and Azure? -Mia-Platform Console is cloud-agnostic. It interacts with any CNCF-compliant Kubernetes cluster, regardless of the underlying provider (**aws cloud computing**, **google cloud run**, etc.). You can connect clusters from GKE, EKS, or AKS. For other integrations, it supports specific providers like **aws secrets manager** or **azure key vault**. Features like **Infrastructure Projects** can manage cloud-specific resources like **aws s3** buckets or **aws fargate** services using **Terraform**. +Mia-Platform Console is cloud-agnostic. It interacts with any CNCF-compliant Kubernetes cluster, regardless of the underlying provider (**aws cloud computing**, **google cloud run**, etc.). You can connect clusters from GKE, EKS, or AKS. For other integrations, it supports specific providers like **aws secrets manager** or **azure key vault**. Cloud-specific resources like **aws s3** buckets or **aws fargate** services can be described as [Infrastructure Resources](/products/console/software-catalog/items-manifest/infrastructure-resource.md) in the Software Catalog and managed with **Terraform**. [Discover more](/products/console/company-configuration/clusters-management/overview.md) #### What are Webhooks and how can I use them? diff --git a/versioned_docs/version-15.0.0/getting-started/use-cases/ai-agent-lifecycle.md b/versioned_docs/version-15.0.0/getting-started/use-cases/ai-agent-lifecycle.md deleted file mode 100644 index 14d28c7d6e..0000000000 --- a/versioned_docs/version-15.0.0/getting-started/use-cases/ai-agent-lifecycle.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: ai-agent-lifecycle -title: AI Agent Lifecycle -sidebar_label: AI Agent Lifecycle ---- - -# AI Agent Lifecycle - -Generative AI is really promising, but the path to production is fraught with challenges. Organizations often struggle to bridge the chasm between powerful Large Language Models (LLMs) and their proprietary data, orchestrate intelligent agents, and securely govern their entire lifecycle in production environments. Mia-Platform addresses these complexities by providing a structured approach to build, orchestrate, and govern end-to-end AI-native systems as a core function of the platform. AI turns from a theoretical asset into an engine for tangible business value, allowing you to ship intelligent, context-aware, secure, and seamlessly integrated applications at speed. - -## Core Capabilities for AI-Native Systems - -Mia-Platform demystifies the adoption of Generative AI by offering a structured approach to architecting, orchestrating, and governing intelligent systems at scale. - -### Build Context-Aware RAG Applications - -A primary challenge is making general-purpose LLMs reason with private, proprietary data sources. Mia-Platform enables the development of complex [**Retrieval-Augmented Generation (RAG)**](/runtime-components/templates/ai-rag-template/10_overview_and_usage.md) applications. These systems enhance LLMs so that they can access and utilize your internal knowledge bases from both structured and unstructured data sources, returning answers that are not only accurate but also deeply contextualized to your specific business domain and are therefore valuable for you. This turns your private data into a powerful competitive differentiator. - -### Forge a Foundation of AI-Ready Data - -The quality of an AI system is directly proportional to the quality of its data. By leveraging the [**Mia-Platform Fast Data**](/products/fast_data/what_is_fast_data.md), you are able to prepare and serve a continuous stream of reliable data, which is effectively aligned, contextually governed and continuously qualified. This ensures that your AI models operate with information that is secure, compliant by design, and always up-to-date, forming a foundation of unbiased, trustworthy data for any intelligent application. - -### Orchestrate Intelligent Agent & Multi-Agent Systems - -Moving beyond single-shot prompts, Mia-Platform enables the design, coordination and monitoring of complex workflows using [**Flow Manager**](/runtime-components/plugins/flow-manager-service/10_overview.md) or with custom implementation where multiple AI agents collaborate to execute distributed tasks. This allows for the creation of sophisticated systems that can solve multifaceted business problems by breaking them down into smaller, manageable steps handled by specialized agents. - -### Achieve Digital Sovereignty with Self-Hosted LLMs - -For organizations that require absolute control over their data and intellectual property, Mia-Platform supports the deployment and management of LLMs within your own private infrastructure. This approach to digital sovereignty ensures that sensitive information never leaves your trusted environment, meeting the strictest security and compliance requirements. - -### AI-Powered Software Development Lifecycle (SDLC) - -Mia-Platform also integrates AI to enhance the entire development process. The [**AI-Powered SDLC Tool**](/runtime-components/applications/quality-assistant/10_overview.md#ai-powered-sdlc-tool) accelerates development and improves the quality of assets by offering AI-driven requirement evaluation, test coverage estimation, and compliance checks against industry standards. Furthermore, the [**AI-Compliance for Data Catalog**](/runtime-components/applications/data-catalog-ai-compliance/10_overview.md#getting-started) enables even non-technical roles to explore and understand data catalog metadata by means of natural language interactions with an AI Assistant, ultimately simplifying audits and compliance tasks. diff --git a/versioned_docs/version-15.0.0/getting-started/use-cases/application-development.md b/versioned_docs/version-15.0.0/getting-started/use-cases/application-development.md deleted file mode 100644 index b57a58c4b7..0000000000 --- a/versioned_docs/version-15.0.0/getting-started/use-cases/application-development.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: application-development -title: Application Development -sidebar_label: Application Development ---- - -# Application Development - -Traditionally, application development has faced significant delays and friction because of sparse assets and documentation, inadequate tools, and the strong need to rely on other teams. Mia-Platform features a self-service, AI-native ecosystem that turns this slow and fragmented process into a streamlined, intelligent workflow. Modern software creation must cope with dilated times, poor resource allocation and underlying complexities, which hinder innovation and prevent developers from focusing on business logic. Mia-Platform addresses these issues by providing developers with a unified environment and opinionated guidance ("golden paths") to build, manage and deploy scalable, reusable, and high-performance cloud-native applications with unprecedented speed and efficiency. - -The entire end-to-end lifecycle of an application—from initial design and configuration to deployment and monitoring—is managed with full autonomy and security through the [**Mia-Platform Console**](/products/console/overview-dev-suite.md). - -## A Self-Service, Composable Experience - -Composability is the approach that shapes Mia-Platform's own idea of application development. It is enabled by a rich and ever-expanding [**Software Catalog**](/products/console/software-catalog/overview.md). This centralized catalog provides developers with ready-to-use, standardized assets, eliminating bottlenecks and redundancies. Abiding by predefined compliance guardrails, development teams can accelerate product creation by composing brand new solutions or reusing existing services from a variety of well-defined building blocks: - -* [**Plugins**](/runtime-components/plugins/mia-platform-plugins.md)**:** Ready-to-use microservices, typically packaged as Docker images with predefined configurations, designed to solve specific runtime needs and integrate seamlessly into your projects. - -* [**Templates**](/runtime-components/templates/mia_templates.md)**:** Base repositories that serve as a starting point for creating new microservices. They provide developers with direct access to the codebase, ensuring compliance with best practices from day one. - -* [**Examples**](/runtime-components/examples/mia_examples.md)**:** Similar to templates, examples offer sample code addressing specific use-cases, often with more features already implemented to help developers familiarize themselves with the development environment. - -* [**Applications**](/runtime-components/applications/mia_applications.md)**:** Pre-configured bundles of resources—including microservices, endpoints, CRUD collections, and public variables—that can be instantiated with a few clicks to set up complex, working systems rapidly. - -## Building Blocks of a Cloud-Native Application - -Developers can use the Mia-Platform Console to easily design and configure all the fundamental components of a modern digital product in a powerful low-code and no-code environment. - -* [**Microservices**](/products/console/api-console/api-design/services.md)**:** As the core of any application, microservices can be created in seconds from the Marketplace or from an existing Docker image. The Console provides full control over their configuration, including environment variables, resource limits, and runtime probes. - -* [**Endpoints**](/products/console/api-console/api-design/endpoints.md)**:** Services are exposed securely and consistently through an API Gateway. Developers can define endpoints, manage routing, and configure security policies such as authentication and authorization with fine-grained control. - -* [**CRUDs**](/products/console/api-console/api-design/crud_advanced.md)**:** For data-centric services, developers can automatically generate REST APIs for Create, Read, Update, and Delete operations on a MongoDB collection without writing any code. This drastically speeds up the creation of services that need to interact with persistent data. - -* [**Microfrontend Composer**](/products/microfrontend-composer/what-is.md)**:** For building user interfaces, such as backoffices or complex dashboards, the Microfrontend Composer allows developers to design and orchestrate applications using low-code functionalities. It enables the composition of custom pages with web components that can read and write data in real-time. - -## The Development Lifecycle: From Design to Deployment - -Mia-Platform industrializes the entire software development lifecycle, ensuring governance and quality at every stage. - -* **Declarative, Manifest-Driven Configuration:** Every component in the Software Catalog, whether it's a plugin, template, or application, is defined by a declarative [**manifest**](/products/console/software-catalog/items-manifest/overview.md). This manifest is a JSON representation of the component's data and resources, ensuring that all assets are standardized, version-controlled, and managed as code. - -* **Unified Design and Configuration:** All aspects of an application's architecture are configured within the [**Design Area**](/products/console/api-console/api-design/overview.md) of the Console. This provides a single source of truth for microservices, endpoints, data models, and public variables, abstracting away the underlying complexity. - -* **Automated Deployment:** Once the application is designed and configured, it can be deployed to any multi-cloud or on-premise environment with a few clicks. The Console automates the deployment process, allowing developers to release new versions quickly and safely while monitoring resource usage and performance in real-time. diff --git a/versioned_docs/version-15.0.0/getting-started/use-cases/cloud-operations.md b/versioned_docs/version-15.0.0/getting-started/use-cases/cloud-operations.md deleted file mode 100644 index 792135215f..0000000000 --- a/versioned_docs/version-15.0.0/getting-started/use-cases/cloud-operations.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: cloud-operations -title: Cloud Operations -sidebar_label: Cloud Operations ---- - -# Cloud Operations - -Cloud Operations encompass the practices and tools required to manage, monitor, and optimize complex multi-cloud and hybrid environments. The primary challenge is taming the inherent chaos of distributed systems, controlling operational overhead, enforcing security consistently, and optimizing costs without stifling innovation. Mia-Platform addresses these challenges by providing a centralized command center that masters cloud-native infrastructure, embedding best practices for security, reliability, and efficiency by default. - -This approach transforms cloud infrastructure from a mere cost center into a strategic asset, enabling teams to manage complexity with ease, fortify their security posture, and drive both financial and environmental sustainability. - -## Core Pillars of Cloud Operations with Mia-Platform - -Mia-Platform empowers operations teams with a suite of tools and methodologies designed to provide full command over the cloud environment. - -### Infrastructure as Code (IaC) for Consistency - -Mia-Platform champions the Infrastructure as Code (IaC) paradigm, allowing teams to manage and provision their entire infrastructure through machine-readable configurations. This ensures that every deployment is repeatable, scalable, and version-controlled. - -* [**Infrastructure Projects**](/products/console/project-configuration/infrastructure-project.md)**:** A dedicated project type designed for Operations teams to define, version, and deploy infrastructure resources (like Kubernetes clusters, databases, or cloud storage) using tools such as Terraform or OpenTofu. This provides a consistent and controlled workflow for infrastructure changes. - -* [**Custom Resources**](/products/console/design-your-projects/custom-resources/custom-resources.md)**:** Extend the Console's capabilities by defining any custom infrastructure object—from Kubernetes CRDs to serverless functions—as configuration-as-code elements, ensuring they are managed within the same governed lifecycle. - -### Multi & Hybrid Cloud Fleet Command - -Mia-Platform allows you to single-handedly control and orchestrate resources across multiple cloud providers, on-premises environments, and even across a combination of both. - -* [**Cluster Management**](/products/console/company-configuration/clusters-management/connect-and-manage-cluster.mdx)**:** Connect and manage any Kubernetes cluster, whether it's on a major cloud provider (GKE, EKS, AKS) or on-premise. This unified view simplifies the management of distributed infrastructure and enables true hybrid and multi-cloud flexibility. - -### End-to-End Observability - -Gaining deep, actionable insights into the health, performance, and security of your platform and applications is critical. Mia-Platform turns data into decisive operational intelligence and strategic decision-making. - -* [**Integrated Monitoring and Logging**](/products/console/monitoring/introduction.md)**:** The **Runtime Area** of the Console provides a real-time view of all deployed resources, including pods, deployments, and services. It offers direct access to logs, events, and resource metrics. - -* [**Customizable Dashboards**](/products/console/monitoring/dashboard.md)**:** Integrate and display dashboards from monitoring tools like Grafana and Kibana directly within the Console, providing a centralized view of application performance and system health. - -* [**Alerting and Probes**](/products/console/api-console/api-design/microservice-runtime-resources.md)**:** Configure liveness and readiness probes for your services to ensure Kubernetes can effectively manage their lifecycle, and set up alerting rules in tools like Grafana to be notified of issues proactively. - -### Embedded Security and Guardrails - -Security is not an afterthought but is embedded into the fabric of the platform. Mia-Platform enables the deployment of automated policies and controls that enforce security best practices system-wide. - -* [**Automated Security Measures**](/requirements/installation-guidelines/console/paas/security-measures.md)**:** The platform enforces security by default with features like TLS encryption, centralized authentication and authorization flows, and vulnerability management. - -* [**Fine-Grained Access Control**](/products/console/api-console/api-design/authorization.md)**:** Utilize **Rönd**, a lightweight sidecar, to distribute security policy enforcement throughout your application, ensuring that access to sensitive data and operations is strictly controlled. - -### Cloud Economics and Sustainability (FinOps & GreenOps) - -Take command of your cloud spend and drive environmental sustainability by reducing the carbon footprint of your operations. - -* [**Resource Optimization**](/products/console/tutorials/set-requests-limits-of-a-microservice.mdx)**:** The Console provides tools to set and monitor CPU and memory requests, including limits for each microservice, eventually preventing resource waste while optimizing costs. - -* [**Automated Environment Shutdown with Kube-Green**](/requirements/installation-guidelines/console/paas/tools/kube-green.md)**:** Reduce the CO2 footprint of your clusters by automatically shutting down non-production environments (e.g., development, testing) during non-working hours, significantly cutting down on energy consumption and costs. - -By adopting these Cloud Operations practices with Mia-Platform, organizations can achieve a state of operational excellence, managing complexity with confidence and transforming their infrastructure into a powerful engine for innovation. diff --git a/versioned_docs/version-15.0.0/getting-started/use-cases/data-integration.md b/versioned_docs/version-15.0.0/getting-started/use-cases/data-integration.md deleted file mode 100644 index 53d922be6b..0000000000 --- a/versioned_docs/version-15.0.0/getting-started/use-cases/data-integration.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -id: data-integration -title: Data Integration -sidebar_label: Data Integration ---- - -# Data Integration - -Mia-Platform achieves Data Integration with an architectural approach named [**Data Fabric**](/products/fast_data/what_is_fast_data.md), i.e. a cutting-edge solution designed to address common challenges related to data, such as fragmentation, tight coupling, legacy system bottlenecks, and the need for access to real-time information. The primary goal is to decouple data from disparate sources, known as **Systems of Record (SoRs)**, and make it available 24/7, for any digital channel or application. This is achieved by creating a high-performance, consolidated data layer that provides a unified, 360-degree view of business entities. - -Mia-Platform's approach combines the principles of **Data Mesh** and **Data Fabric**, enabling organizations to manage the entire data lifecycle, from collection to exposure, with agility and governance. - -## The Core Challenge: Overcoming Legacy Constraints - -Modern enterprises often struggle to innovate because their critical data is locked within legacy systems. These systems are frequently non-scalable, difficult to query, and become a significant bottleneck, leading to issues such as: - -* **Increased response times** for applications trying to access data. - -* **High load and resource consumption** on source systems, impacting their primary functions. - -* **Data inconsistency** across different channels and applications. - -* **Lack of 24/7 data availability**, with system maintenance or downtime directly affecting business operations. - -Directly querying and aggregating data from these systems on-demand is inefficient and hinders the ability to deliver seamless, real-time digital experiences. - -## Mia-Platform's Solution: The Fast Data Architecture - -To solve these challenges, Mia-Platform provides [**Fast Data**](/products/fast_data/what_is_fast_data.md), a suite of highly configurable, event-driven components that industrialize the process of data integration. The architecture is designed to create a persistent, low-latency data layer that is always available and easy to consume. - -### Building Blocks of Data Integration - -The data integration process in Mia-Platform is built upon a few key concepts and components: - -1. [**Connectors and Change Data Capture (CDC)**](/products/fast_data/concepts/the_basics.md#change-data-capture-cdc)**:** The process begins with ingesting data from the Systems of Record. This is typically achieved using CDC connectors, which capture changes (creations, updates, deletions) in the source databases in near real-time and stream them as events into an event streaming platform like Apache Kafka. This event-driven approach ensures that legacy systems are only touched when data actually changes, effectively offloading them. - -2. [**Projections**](/products/fast_data/concepts/the_basics.md#projection)**:** Once the data events are in Kafka, they are consumed by services like the [**Real-Time Updater**](/products/fast_data/realtime_updater.md). This service is responsible for creating **Projections**, which are standardized, cleaned, and filtered representations of the source data. Projections contain only the fields relevant to the business domain and are stored in a highly scalable NoSQL database like MongoDB. This step ensures data standardization, as different source formats can be cast into a consistent model. - -3. [**Single Views**](/products/fast_data/concepts/the_basics.md#single-view-sv)**:** The ultimate goal of the integration process is to create **Single Views**. A Single View is a pre-aggregated document that combines data from multiple Projections to provide a holistic, 360-degree view of a business entity (e.g., a customer, a product, an order). The [**Single View Creator**](/products/fast_data/single_view_creator.md) service is responsible for this aggregation. Because the data is aggregated on write (i.e., as soon as a related Projection changes) rather than on read, read operations on Single Views are exceptionally fast and efficient. - -### The Data Flow - -The typical data integration flow is as follows: - -* A change occurs in a System of Record. - -* A CDC connector captures this change and produces an event on a Kafka topic. - -* The Real-Time Updater consumes the event, applies any necessary transformations (casting), and updates the corresponding Projection document in MongoDB. - -* The update to the Projection triggers the Single View Creator, which re-aggregates the relevant Single View, ensuring it always reflects the latest data. - -* The updated Single View is now available to be consumed by any application or API, providing a consistent, real-time view of the data. - -## Key Benefits of Mia-Platform's Data Integration - -* **Legacy System Offloading:** Reduces the load on critical source systems by moving read traffic to the highly scalable Single View layer. - -* **24/7 Data Availability:** The Data Fabric provides a persistent data layer that remains available even if source systems are down for maintenance. - -* **Real-Time Data Access:** The event-driven architecture ensures that data is synchronized and aggregated in near real-time, enabling reactive and data-intensive applications. - -* **Data Standardization and Governance:** Data from various sources is transformed into a consistent, governed model, simplifying consumption and ensuring data quality. - -* **Accelerated API and Application Development:** With data readily available in a pre-aggregated and easy-to-consume format, developers can build new APIs and applications much faster, as the complexity of data aggregation is handled by the platform. diff --git a/versioned_docs/version-15.0.0/getting-started/use-cases/platform-engineering.md b/versioned_docs/version-15.0.0/getting-started/use-cases/platform-engineering.md deleted file mode 100644 index f0de94a9c2..0000000000 --- a/versioned_docs/version-15.0.0/getting-started/use-cases/platform-engineering.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: platform-engineering -title: Platform Engineering -sidebar_label: Platform Engineering ---- - -# Platform Engineering - -Platform Engineering is the discipline of designing, building, and maintaining self-service toolchains and workflows that enable development teams to build and deliver software. At its core there is the [**Internal Developer Platform (IDP)**](/getting-started/mia-platform-overview.md), a foundational ecosystem that acts as a centralized hub with self-service access to tools and services, and embedded best-practices, recommendations and guardrails for developers. This allows to release applications faster, more reliably, and with greater autonomy. By treating the platform as a product and developers as its customers, Platform Engineering optimizes the whole software development lifecycle (SDLC), reduces cognitive load, and enforces governance without sacrificing speed. - -This approach evolved from DevOps principles, aiming to solve the complexities of modern cloud-native environments. While DevOps focuses on the cultural and methodological fusion of development and operations, Platform Engineering provides the tangible infrastructure and automated pathways to make those principles a reality. - -## Core Principles of Platform Engineering with Mia-Platform - -Mia-Platform is an AI-Native Developer Platform Foundation that empowers organizations to scale agile and Platform Engineering practices, drive automation and software reuse, streamline data delivery and harness the full potential of AI. - -### Self-Service and Developer Autonomy - -A key goal of Platform Engineering is to empower developers with tools and procedures that compress the SDLC, thus enabling faster value generation. Mia-Platform achieves this by offering a [self-service platform](/products/console/overview-dev-suite.md) where development teams can independently manage the entire lifecycle of their applications. This includes: - -* **Creating and configuring environments** for testing and deployment. -* **Developing microservices** with [standardized, pre-configured CI/CD pipelines](/products/console/deploy/overview.md). -* **Accessing essential resources** like [logging and monitoring](/products/console/monitoring/introduction.md) and infrastructure components without opening tickets or waiting for other teams. - -This self-service model eliminates organizational bottlenecks, reduces friction, and allows developers to focus on writing code and delivering business value. - -### Golden Paths and Standardization - -Platform Engineering, through Internal Developer Platforms (IDPs), encompasses well-defined, built-in workflows, i.e. best practices, recommendations, and security measures for creating and deploying software. Mia-Platform promotes and facilitates the creation of these "golden paths", "paved roads" and "guardrails" through: - -* [**Project Templates**](/products/console/company-configuration/project-blueprint.md)**:** New projects can be started in a few clicks, inheriting pre-configured settings, tools, and CI/CD pipelines. This ensures consistency and adherence to best practices from day one. -* **Reusable Components:** A [software catalog of plugins, templates, and applications](/runtime-components/overview_marketplace.md) accelerates development and promotes the reuse of proven solutions across the organization. -* **Standardized Deployment:** By leveraging a [GitOps methodology](/products/console/deploy/overview.md) and offering integrations with various CI/CD tools like GitLab CI, GitHub Actions, and Jenkins, Mia-Platform ensures a consistent and automated deployment process. - -### Abstraction of Complexity - -Modern cloud-native architectures, often based on Kubernetes, can be overwhelmingly complex. Platform Engineering aims to abstract this complexity from developers. Mia-Platform provides an intuitive user interface and a set of automated tools that manage the underlying infrastructure, allowing developers to: - -* **Manage microservice configurations** without needing deep Kubernetes expertise. -* **Securely expose APIs** through a managed [API Gateway](/runtime-components/plugins/api-gateway/10_overview.md). -* **Monitor application performance and health** via integrated [observability tools](/products/console/monitoring/introduction.md). - -By reducing the cognitive load on developers, Mia-Platform enables them to be more productive and innovative. - -## Building Your Internal Developer Platform (IDP) - -Mia-Platform serves as the foundation for building a robust IDP tailored to your organization's specific needs. An IDP built with Mia-Platform centralizes all necessary tools and resources, providing a unified and cohesive developer experience. Key components include: - -* **A Centralized Console:** A single point of control for designing, deploying, and monitoring applications and infrastructure. -* **An Internal Developer Portal:** The interactive, intelligent interface that allows developers to access platform tools, resources, documentation and services in self-service fashion. -* **A Software Catalog:** A comprehensive registry of all available software components, services, APIs, and microservices within the platform. It helps developers discover and reuse existing assets, but it also feeds AI with contextual knowledge. -* **Automated CI/CD Pipelines:** Integrated and standardized pipelines for continuous integration and delivery. -* **Observability Tools:** Built-in features for monitoring, logging, and tracing. -* **Secure API Management:** Tools for exposing, securing, and managing APIs. - -## Key Benefits - -Adopting a Platform Engineering approach with Mia-Platform delivers significant benefits across the organization: - -* **Increased Developer Productivity:** By providing self-service tools and automating repetitive tasks, developers can focus more on programming and less on infrastructure, leading to a significant reduction in time-to-market. -* **Improved Governance and Security:** Centralized management and standardized templates ensure that all projects adhere to corporate security policies and best practices from the design phase. -* **Enhanced Reliability and Resilience:** Automated deployment pipelines and integrated monitoring tools help identify issues early and ensure the stability of applications in production. -* **Reduced Operational Costs:** Automation, resource optimization, and the reuse of components lead to lower maintenance and operational costs. -* **Greater Accountability:** By providing visibility and traceability throughout the entire DevOps cycle, it becomes easier to manage and monitor the evolution of projects and resource usage. diff --git a/versioned_docs/version-15.0.0/products/ai-foundry/overview.md b/versioned_docs/version-15.0.0/products/ai-foundry/overview.md index 8f3b3dda86..aa0373d6fa 100644 --- a/versioned_docs/version-15.0.0/products/ai-foundry/overview.md +++ b/versioned_docs/version-15.0.0/products/ai-foundry/overview.md @@ -72,6 +72,10 @@ Tools and skills are attachable to agents from the catalog. Register external [Model Context Protocol](https://modelcontextprotocol.io/) servers to expand the tool ecosystem available to your agents. Each registered server is stored as a catalog resource and its tools are included in the available tools list. +### Programmatic access + +The AI Foundry ADK BE APIs can be called machine-to-machine using a **service account**, registered through Platform Administration — see [Registering a service account](/products/mia-platform-suite/rbac_management.md#registering-a-service-account) and [Requesting an access token](/products/mia-platform-suite/rbac_management.md#requesting-an-access-token). Unlike Catalog, calling the AI Foundry ADK BE APIs requires the token to be requested with **all three** scopes together — `mia:catalog`, `mia:ai-foundry`, and `mia:authz` — requesting `mia:ai-foundry` alone is not sufficient. + ## IDE and tooling integration You can download the following AI assets to work from your workstation: diff --git a/versioned_docs/version-15.0.0/products/console/project-configuration/img/add-infrastructure-component-azure.png b/versioned_docs/version-15.0.0/products/console/project-configuration/img/add-infrastructure-component-azure.png deleted file mode 100644 index 22a554fd08..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/project-configuration/img/add-infrastructure-component-azure.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/project-configuration/img/add-infrastructure-component-gitlab.png b/versioned_docs/version-15.0.0/products/console/project-configuration/img/add-infrastructure-component-gitlab.png deleted file mode 100644 index 306cb8d3ac..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/project-configuration/img/add-infrastructure-component-gitlab.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/project-configuration/img/infrastructure-project-deploy-history.png b/versioned_docs/version-15.0.0/products/console/project-configuration/img/infrastructure-project-deploy-history.png deleted file mode 100644 index 000e6dda98..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/project-configuration/img/infrastructure-project-deploy-history.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/project-configuration/img/infrastructure-project-selection.png b/versioned_docs/version-15.0.0/products/console/project-configuration/img/infrastructure-project-selection.png deleted file mode 100644 index ba34b9a2c9..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/project-configuration/img/infrastructure-project-selection.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/project-configuration/img/pipeline-webhook-warning.png b/versioned_docs/version-15.0.0/products/console/project-configuration/img/pipeline-webhook-warning.png deleted file mode 100644 index 625adcfab3..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/project-configuration/img/pipeline-webhook-warning.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/project-configuration/img/webhook-manual-creation.png b/versioned_docs/version-15.0.0/products/console/project-configuration/img/webhook-manual-creation.png deleted file mode 100644 index db5c5f95c5..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/project-configuration/img/webhook-manual-creation.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/project-configuration/index.md b/versioned_docs/version-15.0.0/products/console/project-configuration/index.md index 64f965c6bf..634ee13239 100644 --- a/versioned_docs/version-15.0.0/products/console/project-configuration/index.md +++ b/versioned_docs/version-15.0.0/products/console/project-configuration/index.md @@ -11,7 +11,10 @@ Within the platform's hierarchy, a "Project" sits beneath a "Company", allowing ## Project types -There are two different Project types, supported in Console: +Console supports the following Project type: - [Application Projects](/products/console/project-configuration/application-project.md): meant for software products development and release -- [Infrastructure Projects](/products/console/project-configuration/infrastructure-project.md): meant for operations teams, leveraging IaC for infrastructure provisioning \ No newline at end of file + +:::note +**Infrastructure Projects** have been deprecated starting from v15.0.0 and can no longer be used. Refer to the [v15.0.0 release notes](/release-notes/v15.0.0) for more information. +::: \ No newline at end of file diff --git a/versioned_docs/version-15.0.0/products/console/project-configuration/infrastructure-project.md b/versioned_docs/version-15.0.0/products/console/project-configuration/infrastructure-project.md deleted file mode 100644 index 01a212515b..0000000000 --- a/versioned_docs/version-15.0.0/products/console/project-configuration/infrastructure-project.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -id: infrastructure-project -title: Infrastructure Projects -sidebar_label: Infrastructure Projects -sidebar_order: 2 ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -**Infrastructure Projects** are a dedicated Project type in the Console for provisioning and managing infrastructure, following the *Infrastructure as Code* (IaC) paradigm. - -They are designed primarily for **Operations teams**, who can use them to define, version, and deploy infrastructure resources while ensuring consistency, transparency, and control over infrastructure changes. - -For example, DevOps teams can use Infrastructure Projects to group all repositories that use tools like [Terraform](https://www.hashicorp.com/en/products/terraform), [OpenTofu](https://opentofu.org), [Microsoft Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep), or others to manage resources. - -By consolidating these repositories, Infrastructure Projects simplify the release and monitoring process. They allow you to deploy a component and follow a two-part process: a validation phase (e.g., the `plan` phase in a Terraform pipeline), where you can review proposed changes and decide whether to proceed, and an execution phase (e.g., the `apply` phase in a Terraform pipeline), where the changes are actually applied. - -These Projects are distinct from traditional [Application Projects](/products/console/project-configuration/application-project.md) as they are specifically designed to manage infrastructure resources, enabling better control, automation, and governance in the context of IaC. They can be connected to multiple repositories containing code and scripts to deploy resources in your infrastructure, providing the ability to deploy quickly with a review of the affected resources. - -:::info -Infrastructure Projects are currently a [**BETA** feature](/release-notes/info/version_policy#feature-preview-and-beta) and are under active development. - -At this time, they only support **GitLab** and **Azure DevOps** repositories with a specific pipeline configuration. Support for other providers will be added in future Console releases. You can find out more in the [technical limitations](#technical-limitations) section below. - -If you want to share your feedback, you can head to the [Community discussion post](https://github.com/mia-platform/community/discussions/612). -::: - -## Creating an Infrastructure Project - -When creating a new Project in your Company, you can select the **Infrastructure** type. -This option unlocks a dedicated setup flow and enables the creation of a Project tailored to infrastructure workflows. - -![Infrastructure Project selection](./img/infrastructure-project-selection.png) - -## Managing Infrastructure Components - -Each Infrastructure Project includes a specific section for managing **infrastructure components**. - -:::info -Currently, it is possible to add components from scratch, referencing existing repositories in the provider of the project. - -In the near future components will be available in the [Software Catalog](/products/console/software-catalog/overview.md), to quickly install components simplifying the configuration and allowing to share -these configurations with other users. -::: - -To create a new infrastructure component from scratch, you need to provide several information, which depends on the type of provider of the project. - - - -If you have a project using GitLab as a provider, these are the information that are required to add a component: - -- **Name**: The name of the component. -- **Repository URL**: The URL of the Git repository where the component's code is hosted. This is used to provide a reference to the user. -- **Branch/tag Name**: The Git branch, tag, or commit that the deployment pipeline will run on. -- **Repository Project ID**: The project ID associated with the Git repository. This is actually used to interact with the Git Provider. - -![Add Infrastructure Component](./img/add-infrastructure-component-gitlab.png) - -As example: - -- **Repository URL**: `https://my.gitlab.host/some/repo` -- **Branch/tag name**: `main` -- **Repository Project ID**: `some/repo` - -:::info -As a _Repository Project ID_, you can use the relative path of the repository or the numeric identifier that you can find in the _Settings_ section of the repository. -::: - - - - -If you have a project using Azure DevOps as a provider, these are the information that are required to add a component: - -- **Name**: The name of the component. -- **Repository URL**: The URL of the Git repository where the component's code is hosted. This is used to provide a reference to the user. -- **Branch/tag Name**: The Git branch, tag, or commit that the deployment pipeline will run on. -- **Repository Organization Name**: The name of the Organization that contains the repository. -- **Repository Project Name**: The name of the repository that contains the code to be deployed. -- **Repository Pipeline ID**: As Azure DevOps allows to configure different pipelines, this is the numeric identifier of the pipeline configured - -![Add Infrastructure Component](./img/add-infrastructure-component-azure.png) - -As example: - -- **Repository URL**: `https://dev.azure.com/my-organization/my-project` -- **Branch/tag name**: `main` -- **Repository Organization Name**: `my-organization` -- **Repository Project Name**: `my-project` -- **Repository Pipeline ID**: `1` - -:::info -The _Repository Pipeline ID_ is not the name of the pipeline, but the identifier that can be found in the settings of the pipeline itself. - -You can alternatively find it by navigating into your pipeline page: on the address bar the `definitionId` value is the pipeline identifier. -::: - - - - -## Deploying your Infrastructure - -From within your Project, you can manage the deployment flow of your infrastructure components by: - -- Running a **plan** to preview proposed infrastructure changes -- Executing an **apply** to confirm and release your infrastructure changes - -This enables control and consistency in your infrastructure. - -### Deploy History - -The **Deploy History** page is useful to better understand which actions have been executed for each infrastructure component of your Project. -In particular this view traces which component has been deployed, together with some additional information. - -![Infrastructure project deploy history](img/infrastructure-project-deploy-history.png) - -#### Pipeline Webhook - -In order to correctly fill up the Deploy History view, an Infrastructure Component must have a webhook associated to its repository on the git Provider. - -The webhook is automatically created upon the Infrastructure Component creation. However, in case the webhook creation fails, a warning message will inform to manually retry the webhook creation from the Infrastructure Components Overview page. - -![Pipeline webhook warning message](img/pipeline-webhook-warning.png) - -If an Infrastructure Component is missing the related webhook on the git Provider, the Component will show highlighted to inform of this issue. On the right side of the Component row, a dedicated action appears to manually retry the webhook creation. - -![Manually create webhook](img/webhook-manual-creation.png) - -## Runtime Visibility - -This feature is currently in [BETA](/release-notes/info/version_policy#feature-preview-and-beta), so the visualization of runtime resources is not natively implemented. - -To get the infrastructure components generated after deployment for each project, you can generate an [Infrastructure Component Runtime Software Catalog item type](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md) on the software catalog from the same pipeline via [miactl](/products/console/software-catalog/items-management/miactl.md). - -Subsequently, this information can be retrieved either by using the Marketplace API or by creating a [Composer extension](/products/console/company-configuration/extensions.md#add-new-extension). - -:::info -To retrieve the information of the available [Infrastructure Component Runtime Software Catalog item type](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md), you can use the following software catalog endpoint and filter by the project of interest: - -```shell -curl -X GET \ - -H "Authorization: Bearer " \ - '/api/marketplace?tenantId=&types=infrastructure-component-runtime' -``` - -::: - -## Access and Permissions - -Currently, all members of a Company can view Infrastructure Projects. -However, only users with the role of **Project Administrator** or **Company Owner** are allowed to perform changes within them. - -## Technical limitations - -As mentioned above, there are still some technical limitations that repositories must conform to in order for Infrastructure Projects to work. - -:::note -All of the following limitations will be soon resolved -::: - -- the repository must be on one of the following: - - _GitLab_ and use _GitLab CI_ - - the GitLab CI pipeline must be composed of two separate jobs named `plan` and `apply` - - _Azure_ and use _Azure Pipelines_ - - the Azure pipeline must be composed of three stages: the first stage has to be named `plan`, the second stage must be a `ManualApproval`, and the thirs stage must be named `apply` -- creation from Marketplace is not supported yet, so you need to create your repository beforehand diff --git a/versioned_docs/version-15.0.0/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md b/versioned_docs/version-15.0.0/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md index 0d7de87f26..06c0ad0567 100644 --- a/versioned_docs/version-15.0.0/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md +++ b/versioned_docs/version-15.0.0/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md @@ -14,8 +14,7 @@ import SchemaViewer from "../snippets/schema_viewer.mdx"; Infrastructure Component Runtime are available starting from the v14 of the Mia-Platform Console. ::: -Infrastructure Component Runtime items are meant to be used in the context of an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md) -to be able to collect [runtime data](/products/console/project-configuration/infrastructure-project.md#runtime-visibility) for visualization within Console. +Infrastructure Component Runtime items are meant to collect runtime data of the infrastructure components deployed by your pipelines, for visualization within Console. To [create or edit](/products/console/software-catalog/items-management/overview.md) an infrastructure Component Runtime item, you need to provide a [manifest](/products/console/software-catalog/items-manifest/overview.md), whose `resources` property should adhere to the following JSON schema. diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/configure-new-company.md b/versioned_docs/version-15.0.0/products/console/tutorials/configure-new-company.md index 0a3c438458..5e8a63137b 100644 --- a/versioned_docs/version-15.0.0/products/console/tutorials/configure-new-company.md +++ b/versioned_docs/version-15.0.0/products/console/tutorials/configure-new-company.md @@ -40,10 +40,6 @@ The configuration process may vary slightly for other providers or cluster types The first step is to connect a Kubernetes cluster. This cluster will be the runtime environment where your applications are deployed and managed. The platform does not create a new cluster but connects to an **existing and pre-configured one** under your management. -:::info -The Console also allows you to create new infrastructure, including clusters, through the [**Infrastructure Project**](/products/console/project-configuration/infrastructure-project.md) feature. However, for the purpose of this onboarding tutorial, we will assume that a pre-configured cluster already exists. -::: - ### Connect a new cluster Inside your Company, navigate to **Infrastructure** > **Clusters** and click **New cluster connection**. diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/create-scorecards.md b/versioned_docs/version-15.0.0/products/console/tutorials/create-scorecards.md index efbf3743dc..e32fa2a097 100644 --- a/versioned_docs/version-15.0.0/products/console/tutorials/create-scorecards.md +++ b/versioned_docs/version-15.0.0/products/console/tutorials/create-scorecards.md @@ -44,7 +44,7 @@ To follow this tutorial, you'll need: The first step is to configure the **Integration Connector Agent**. -For detailed instructions on how to set up the agent and configure scraping for different cloud providers, follow the [official service documentation](/runtime-components/plugins/integration-connector-agent/10_overview.md) and this [tutorial](/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx). +For detailed instructions on how to set up the agent and configure scraping for different cloud providers, follow the [official service documentation](/runtime-components/plugins/integration-connector-agent/10_overview.md). For the purpose of our tutorial, we will configure the **Integration Connector Agent** to interact with an *Azure subscription* and scrape information from **Azure Cloud** and **Azure DevOps**. @@ -74,7 +74,7 @@ Finally, you will also need: All of this information will be saved as secret variables within your Console project. Once you have gathered this data and saved it as secret variables in the project, you can proceed with initializing the **Integration Connector Agent** service from the Marketplace and configuring it. -For the initial setup and basic configuration, please refer to this [documentation](/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx). +For the initial setup and basic configuration, please refer to the [Integration Connector Agent documentation](/runtime-components/plugins/integration-connector-agent/10_overview.md). For this tutorial, you will need to configure the `config.json` ConfigMap as follows: diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/create-project-configuration.md b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/create-project-configuration.md deleted file mode 100644 index cbe53fd144..0000000000 --- a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/create-project-configuration.md +++ /dev/null @@ -1,421 +0,0 @@ ---- -id: create-project-configuration -title: Create Infrastructure Project -sidebar_label: Create Infrastructure Project -sidebar_order: 1 ---- - - -# Infrastructure Project How To - -## Introduction -The "Infrastructure Project" is a new type of project that allows centralized management of infrastructure resources. -This type of project is exclusively dedicated to managing infrastructure resources and offers specific functionalities for creating, deploying, and managing these resources. - -## Creating a Infrastructure Project - -![IMG 1](./img/1.png) - -From v14 it is possible to create a new type of Project called "Infrastructure Project". -To create a new project, simply access the Console, enter a specific Company, and click on "Create Project". - -![IMG 2](./img/2.png) - -In the General step, under "Project type", select the "Infrastructure" option. - -This choice modifies the standard project creation flow, omitting the Environments step. Unlike traditional Application Projects, an Infrastructure project is not based on a single central repository. Instead, configuration occurs at the group level (or folder level, for providers like GitLab that support this structure). This group serves as a logical container for all repositories associated with the infrastructure project you are creating. You will still be able to configure the visibility of this group. - -![IMG 3](./img/3.png) - -The newly created project will differ from standard ones, as it will only have functionalities dedicated to managing infrastructure resources. -This means, for example, that the Design section (among others) will not be present, and the sidebar menu will only include entries relevant to this type of project. - -Specifically, the available console sections will be: -- Overview: where you can manage Settings, Variables, IAM, and Components, which allow management of infrastructure components. -- Deploy: which will contain a list of initialized Infrastructure Components available for deployment. - -![IMG 4](./img/4.png) - -The Deploy section is very different from the standard one; here, there is no branch selection, environment choice, deploy button, or last deploy information. -Instead, it contains a list of Infrastructure Components initialized in this project that can be deployed. - -## Creating a New Infrastructure Resource - -![IMG 5](./img/5.png) - -In the Overview section, there is a "Components" page that allows management of Infrastructure Components. - -By clicking the "Add Infrastructure" button, currently the only available option is to create a new resource from scratch. - -In the future, it will be possible to create a new resource from a Marketplace of ready-to-use infrastructure components. - -![IMG 6](./img/6.png) - -In the resource creation screen, the following must be specified: -- Resource name: the name to assign to the resource -- Repository URL: the git repository containing the Terraform/OpenTofu code of the resource -- Git ref name: the branch in the git repository where the Terraform/OpenTofu code is located -- Repository project ID: the project ID of the git repository - -## Repository example Cloud Storage Bucket - -In the following sections, we will provide an example of a git repository containing Terraform/OpenTofu code for creating a Google Cloud Storage bucket. - -:::info -These are example snippets. Always adapt them to your specific requirements, thoroughly validate all settings (especially variables and secrets), and remember that many effective solutions can be designed differently. -::: - - -Cloud Storage Bucket - - -``` -# Specify the Google Cloud provider -provider "google" { - project = "my-gcp-project-123" # Example GCP project ID - region = "europe-west3" # Example default region -} - -# Create a Google Cloud Storage bucket -resource "google_storage_bucket" "demo_bucket" { - name = "tf-demo-bucket-xyz" # Example unique global bucket name - location = "EUROPE-WEST3" # Example bucket location (region) - storage_class = "NEARLINE" # Example storage class - - # Enable or disable object versioning - versioning { - enabled = true # Enable versioning to keep object history - } - - # Lifecycle rule to transition or delete old objects - lifecycle_rule { - action { - type = "SetStorageClass" # Transition objects to a cheaper storage class - storage_class = "COLDLINE" - } - condition { - age = 30 # Apply transition after objects are older than 30 days - } - } -} -``` - - - - -## Example of a terraform code for creating a GKE Cluster in Google - -In the following sections, we will provide an example of a git repository containing terraform code for creating a GKE Cluster in Google. - -:::info -These are example snippets. Always adapt them to your specific requirements, thoroughly validate all settings (especially variables and secrets), and remember that many effective solutions can be designed differently. -::: - - - -GKE Cluster - - -``` -# Configure the Google Cloud provider provider -provider "google" { - project = "my-gcp-project-123" # Replace with your GCP project ID - region = "europe-west3" # Default region for resources -} - -# Create a GKE cluster without the default node pool -resource "google_container_cluster" "demo_gke" { - name = "tf-demo-gke-cluster" # Cluster name - location = "europe-west3" # Cluster location (region or zone) - remove_default_node_pool = true # We’ll create a custom node pool below - - networking { - network = "default" # Use the default VPC; for a custom network, reference a google_compute_network resource - } - - # Enable Kubernetes API services - addons_config { - http_load_balancing {} - horizontal_pod_autoscaling {} - } -} - -# Create a dedicated node pool for the cluster -resource "google_container_node_pool" "demo_nodes" { - name = "tf-demo-node-pool" - cluster = google_container_cluster.demo_gke.name - location = google_container_cluster.demo_gke.location - node_count = 3 # Number of VM instances in this pool - - node_config { - machine_type = "e2-medium" # VM size - oauth_scopes = [ - "https://www.googleapis.com/auth/cloud-platform", # Full access to GCP APIs (consider narrower scopes for production) - ] - labels = { - env = "demo" - } - tags = ["k8s-node"] - } - - # Auto-upgrade and auto-repair for node instances - management { - auto_upgrade = true - auto_repair = true - } -} - -``` - - - - -## Example of a terraform code for creating a database MongoDB Atlas - -In the following sections, we will provide an example of a git repository containing terraform code for creating a MongoDB Atlas database. - -:::info -These are example snippets. Always adapt them to your specific requirements, thoroughly validate all settings (especially variables and secrets), and remember that many effective solutions can be designed differently. -::: - - -MongoDB Atlas - - -``` -## Configure the MongoDB Atlas provider -provider "mongodbatlas" { - # IMPORTANT: Replace with your actual API keys. - # For better security, consider using environment variables: - # export MONGODB_ATLAS_PUBLIC_KEY="your_public_key" - # export MONGODB_ATLAS_PRIVATE_KEY="your_private_key" - public_key = "" # Your Atlas API public key - private_key = "" # Your Atlas API private key -} - -# Create an Atlas Project -resource "mongodbatlas_project" "demo_project" { - name = "tf-demo-project" # Logical name of your project - # IMPORTANT: Replace with your actual Atlas Organization ID. - # For better security, consider using environment variables: - # export MONGODB_ATLAS_ORG_ID="your_org_id" - org_id = "" # Your Atlas Organization ID -} - -# Create an Atlas MongoDB cluster -resource "mongodbatlas_cluster" "demo_cluster" { - project_id = mongodbatlas_project.demo_project.id - name = "tf-demo-cluster" # Unique cluster name - provider_name = "AWS" # Cloud provider for the cluster (e.g., AWS, GCP, AZURE) - provider_region_name = "EU_CENTRAL_1" # Region (e.g., EU_CENTRAL_1 for Frankfurt on AWS) - provider_instance_size_name = "M10" # Cluster tier (e.g., M10, M20, M30) - backup_enabled = true # Enable continuous backups - - # (Optional) Specify advanced settings - replication_factor = 3 # Number of nodes in replica set - disk_size_gb = 20 # Storage per node - auto_scaling_disk_gb_enabled = true # Enable disk auto-scaling - - # For M10 and higher tiers, auto_scaling_compute_enabled might also be desired for compute scaling - # auto_scaling_compute_enabled = true - # provider_auto_scaling_compute_min_instance_size = "M10" - # provider_auto_scaling_compute_max_instance_size = "M20" -} - -# Create a database user for your application -resource "mongodbatlas_database_user" "app_user" { - username = "tf_app_user" - # IMPORTANT: Replace with a strong, unique password. DO NOT commit this in plain text. - # Consider using environment variables or a secrets manager. - password = "" - project_id = mongodbatlas_project.demo_project.id - roles { - role_name = "readWrite" - database_name = "admin" # Consider limiting to a specific database for production - } - auth_database_name = "admin" # The authentication database for the user - labels = { - env = "demo" - } -} - -``` - - - -## Deploying the Infrastructure Resource - -![IMG 7](./img/7.png) - -From the Deploy section, you can deploy infrastructure resources. - -Inside, you can see a table listing the created infrastructure resources, with their name and git repository. - -The "Start Plan" button performs a plan operation on the resource, which analyzes the terraform code in the repository and shows what would happen if the described changes were applied. - -The plan essentially informs what will be created, modified, or destroyed in case of applying the resource. - -![IMG 8](./img/8.png) - -Once the plan is executed, its result will show the changes that will occur if the resource is applied. - -If the plan is successful, the resource can be deployed by clicking the "Apply" button. - -## Example of GitLab CI Pipeline to Deploy the Resources - -Of course, the GitLab CI pipeline is essential for deploying the resources. In the following sections, we will provide an example of a GitLab CI pipeline that can be used to deploy the resources. - -:::info -These are example snippets. Always adapt them to your specific requirements, thoroughly validate all settings (especially CI/CD variables and secrets), and remember that many effective solutions can be designed differently. -::: - - -Pipeline - - -``` -# GitLab CI/CD OpenTofu Pipeline: Your Lean Starting Point -# -# Hey there! This pipeline is your foundation for automating OpenTofu with GitLab. -# We're covering the essentials: validating your code, planning changes, and -# applying them safely. -# -# Before you dive in, a few key things you'll need to tailor: -# -# 1. OpenTofu Version: Find `image: ghcr.io/opentofu/opentofu:1.8.2` and set your team's version. -# 2. Cloud Provider Authentication: This is crucial! Look for the `CRITICAL: Cloud Provider Authentication` -# section in `before_script`. You'll need to add your specific cloud login steps there. -# 3. .opentofu.rc (Optional): If you use a custom `.opentofu.rc` for things like private provider -# registries, you can load it using the `TF_CONFIG_RC_CONTENT` CI/CD variable. -# 4. Target Workspace: We use `TF_WORKSPACE` (defaulting to "default"). Set this as a CI/CD -# variable in GitLab to switch between environments like 'dev', 'staging', or 'production'. - -workflow: - rules: - - if: $CI_COMMIT_BRANCH - - if: $CI_MERGE_REQUEST_ID - -default: - image: ghcr.io/opentofu/opentofu:1.8.2 # SET YOUR PREFERRED OPENTOFU VERSION HERE - - before_script: - - | - if [ -n "${TF_CONFIG_RC_CONTENT}" ]; then - echo "${TF_CONFIG_RC_CONTENT}" > "${HOME}/.opentofu.rc" # Changed to .opentofu.rc - echo "INFO: OpenTofu CLI configuration (.opentofu.rc) applied from CI/CD variable." # Changed message - fi - - | - echo "INFO: Preparing for cloud provider authentication..." - # --- YOUR AUTHENTICATION SCRIPT GOES HERE --- - # Example for Google Cloud using a Service Account JSON key: - # if [ -n "${GCP_SA_KEY_JSON}" ]; then - # echo "${GCP_SA_KEY_JSON}" > /tmp/gcp-sa-key.json - # export GOOGLE_APPLICATION_CREDENTIALS="/tmp/gcp-sa-key.json" - # echo "INFO: GCP authentication configured." - # else - # echo "ERROR: GCP_SA_KEY_JSON CI/CD variable not set. Cloud operations will likely fail." - # exit 1 - # fi - # --- END OF YOUR AUTHENTICATION SCRIPT --- - -variables: - TF_IN_AUTOMATION: "true" - TF_WORKSPACE: "default" - GIT_DEPTH: 10 - -.opentofu_cache: &opentofu_cache_definition # Changed cache name - cache: - key: "${CI_PROJECT_ID}-${CI_COMMIT_REF_SLUG}-${TF_WORKSPACE}-opentofu" # Changed cache key name - paths: - - .opentofu # Changed path - - .opentofu.lock.hcl # Changed path - policy: pull-push - -stages: - - validate - - plan - - apply - -validate: - stage: validate - extends: .opentofu_cache # Changed extends - script: - - tofu init -reconfigure -input=false -no-color # Changed 'terraform' to 'tofu' - # You can insert additional static analysis or linter scripts here before `fmt` and `validate`. - # Example: tfsec . --no-color - - tofu fmt -check -recursive -diff -no-color # Changed 'terraform' to 'tofu' - - tofu validate -no-color # Changed 'terraform' to 'tofu' - rules: - - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' - -plan: - stage: plan - extends: .opentofu_cache # Changed extends - script: - - tofu init -reconfigure -input=false -no-color # Changed 'terraform' to 'tofu' - - | - # Ensure the target workspace exists - if ! tofu workspace select "${TF_WORKSPACE}" -no-color; then # Changed 'terraform' to 'tofu' - tofu workspace new "${TF_WORKSPACE}" -no-color # Changed 'terraform' to 'tofu' - fi - # Here you could add scripts to dynamically generate .tfvars files or other preparations. - # Example: ./scripts/generate-tfvars.sh > environment.auto.tfvars - - tofu plan -out=tfplan -input=false -no-color # Changed 'terraform' to 'tofu' - artifacts: - paths: - - tfplan - expire_in: 1 day - rules: - - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' - -apply: - stage: apply - extends: .opentofu_cache # Changed extends - script: - - tofu init -reconfigure -input=false -no-color # Changed 'terraform' to 'tofu' - - tofu workspace select "${TF_WORKSPACE}" -no-color # Changed 'terraform' to 'tofu' - # Custom pre-apply commands (e.g., notifications, last policy controls) - # Example: ./scripts/notify-pre-apply.sh - - tofu apply -auto-approve "tfplan" -input=false -no-color # Changed 'terraform' to 'tofu' - # Custom post-apply commands (e.g., CMDB updates, notifications) - # Example: ./scripts/run-smoke-tests.sh - dependencies: - - plan - rules: - - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' - when: manual - allow_failure: false - -``` - - - - -## Infrastructure Resource Repository - -As already mentioned, the infrastructure resource repository is a git repository that contains the terraform code of the resource and the pipelines needed to deploy it. - -Some key files in your repository are: -- main.tf: the main terraform file, which contains the resource definition and variables required for deployment. -- .gitlab-ci.yml: the GitLab pipeline configuration file, which contains the necessary pipelines to deploy the resource. -- scripts (folder): contains utility scripts necessary for the proper functioning of the project in the console. - -### Scripts folder utility - -The scripts folder can contains utility scripts that are used in the GitLab CI pipeline to perform various tasks, such as: - -* Automate GitLab interactions: Programmatically trigger pipelines, monitor job statuses (like "plan" and "apply"), and fetch logs. -* Simplify Terraform output analysis: Scripts can display "plan" logs directly in the Console. This is crucial for reviewing proposed infrastructure changes before confirming an "apply". -* Enable a controlled deployment workflow: After reviewing the plan, the deployment automation prompts the user for confirmation before proceeding with applying changes, ensuring a deliberate and informed deployment process. -* Centralize configuration and utilities: This includes managing API tokens, initializing Terraform with the correct backend settings, and providing reusable utility functions and type definitions. - -## Troubleshooting - -If you encounter issues during the deployment process, consider the following steps: - -- Ensure your Git repository is accessible and contains valid Terraform code. -- Check if the Git ref (branch or tag) exists and is spelled correctly. -- Review the output of the plan for any potential conflicts or errors. -- Confirm that the .gitlab-ci.yml includes all required jobs for the deployment process. diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/1.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/1.png deleted file mode 100644 index ffb5c6c0ca..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/1.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/2.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/2.png deleted file mode 100644 index 02b259302d..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/2.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/3.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/3.png deleted file mode 100644 index 08ba197cad..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/3.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/4.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/4.png deleted file mode 100644 index 520e874568..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/4.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/5.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/5.png deleted file mode 100644 index 3e42747e54..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/5.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/6.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/6.png deleted file mode 100644 index 808b170fe0..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/6.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/7.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/7.png deleted file mode 100644 index 520e874568..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/7.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/8.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/8.png deleted file mode 100644 index 067aee6c8c..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/8.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-add-column-advanced.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-add-column-advanced.png deleted file mode 100644 index a3fa3a33cc..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-add-column-advanced.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-advanced-tenantid.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-advanced-tenantid.png deleted file mode 100644 index dc73a55569..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-advanced-tenantid.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-runtime-tab.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-runtime-tab.png deleted file mode 100644 index b39813dc3c..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation-runtime-tab.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation.png deleted file mode 100644 index 4790f82581..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-composer-extension-creation.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-architecture.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-architecture.png deleted file mode 100644 index fd4b26a58a..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-architecture.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-data-pipeline.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-data-pipeline.png deleted file mode 100644 index 77944266d5..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-data-pipeline.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-design-example.png b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-design-example.png deleted file mode 100644 index 2d57928604..0000000000 Binary files a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/img/visualize-infra-ica-design-example.png and /dev/null differ diff --git a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx b/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx deleted file mode 100644 index e6286c0fd8..0000000000 --- a/versioned_docs/version-15.0.0/products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console.mdx +++ /dev/null @@ -1,549 +0,0 @@ ---- -id: visualize-infrastructure-project-components-runtime-data-in-console -title: View Infrastructure Runtime Data In Console -sidebar_label: View Infrastructure Project Runtime ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -This tutorial will show you how to collect runtime data from your cloud provider and make it available to your final user in Console. - -The tutorial assumes you have the following prerequisites in place: - -- you have created an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md#creating-an-infrastructure-project) -- you have access to an [Application Project](/products/console/project-configuration/application-project.md) where you can create new microservices - -## Architectural overview - -The objective of this tutorial is to: - -- use the Integration Connector Agent to collect runtime data from your cloud provider and save it within the Mia-Platform Catalog -- display the runtime data in the Console using Platforge Composer-based extensions - -Data will be processed by the Integration Connector Agent following an event-driven approach, -which means that the agent will listen to events coming from the Cloud Provider and process them to update the runtime data in the Catalog. - -To receive events from the Cloud Provider, we will create a set of resources in the Cloud Provider first (such as a Pub/Sub topic in GCP, an EventBridge rule in AWS, or an EventHub in Azure), -then we will configure the Integration Connector Agent to listen to these events and process them. - -Therefore, to reach this goal, we will have to set up the following components: - -- set up the Cloud Provider to send events -- configure the Integration Connector Agent to listen to these events and save them in the Catalog -- create a Platforge Composer-based extension to visualize the data in the Console - -![Architectural overview](./img/visualize-infra-ica-architecture.png) - -### Set up Cloud Provider integration - -As mentioned above, we will need to create some resources in the Cloud Provider in order to receive events from it. - -Each Cloud Provider has its own way to send events, so you will have to follow the specific instructions for your Cloud Provider. - -:::info -To set up the Cloud Provider resources that will send events to your Integration Connector Agent instance, we have prepared a set of Terraform modules that will assist you, -you can find them in the [GitHub Mia-Platform Terraform Integration Connector Agent](https://github.com/mia-platform/terraform-integration-connector-agent) repository. -::: - - - -You will need to: - -- create a new CloudTrail -- create a new SQS queue that will be used to receive events by the Integration Connector Agent -- create a new EventBridge rule that will listen to the CloudTrail events and send them to the SQS queue - -Create your terraform module using the following code snippet: - -```go -module "aws" { - source = "github.com/mia-platform/terraform-integration-connector-agent//modules/aws" - - cloudtrail_name = "awesome-cloudtrail-name" - cloudtrail_bucket_name = "awesome-bucket-name" - - eventbridge_rule_name = "awesome-rule-name" - sqs_queue_name = "awesome-queue-name" -} -``` - -:::tip -To provision the resources you can use an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md), just like you would do with any other terraform module. - -You can also simply run - -```bash -terraform init -terraform plan -terraform apply -``` - -Check out the full example in the [repository example directory](https://github.com/mia-platform/terraform-integration-connector-agent/tree/main/examples/aws). -::: - -:::info -Find out more about the specific steps to create these resources in the [Integration Connector Agent documentation](/runtime-components/plugins/integration-connector-agent/use-cases/infrastructure-import/20_aws_infrastructure_import.md). -::: - - - - -You will need to: - -- enable the Cloud Asset Management API -- create a Pub/Sub topic that will be used to receive events by the Integration Connector Agent -- create a feed to send events from the Asset Management API to the Pub/Sub topic - -Create your terraform module using the following code snippet: - -```go -module "gcp" { - source = "github.com/mia-platform/terraform-integration-connector-agent//modules/google" - - pubsub_topic_name = "awesome-topic-name" - cloud_asset_feed_id = "awesome-feed-id" -} -``` - -:::tip -To provision the resources you can use an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md), just like you would do with any other terraform module. - -You can also simply run - -```bash -terraform init -terraform plan -terraform apply -``` - -Check out the full example in the [repository example directory](https://github.com/mia-platform/terraform-integration-connector-agent/tree/main/examples/gcp). -::: - -:::info -Find out more about the specific steps to create these resources in the [Integration Connector Agent documentation](/runtime-components/plugins/integration-connector-agent/use-cases/infrastructure-import/10_gcp_infrastructure_import.md). -::: - - - - - -You will need to: - -- create a new eventhub -- create a monitor diagnostic settings for exporting administrative log to the created eventhub -- create a storage account with a blob container - -Create your terraform module using the following code snippet: - -```go -module "azure" { - source = "github.com/mia-platform/terraform-integration-connector-agent//modules/azurerm" - - resource_group = "awesome-resource-group" - activity_log_diagnostic_setting_name = "awesome-diagnostic-setting-name" - - eventhub_namespace_name = "awesome-eventhub-namespace" - eventhub_name = "awesome-eventhub-name" - - eventhub_checkpoint_storage_name = "awesome-storage-account-name" -} -``` - -:::tip -To provision the resources you can use an [Infrastructure Project](/products/console/project-configuration/infrastructure-project.md), just like you would do with any other terraform module. - -You can also simply run - -```bash -terraform init -terraform plan -terraform apply -``` - -Check out the full example in the [repository example directory](https://github.com/mia-platform/terraform-integration-connector-agent/tree/main/examples/azure). -::: - -:::info -Find out more about the specific steps to create these resources in the [Integration Connector Agent documentation](/runtime-components/plugins/integration-connector-agent/use-cases/infrastructure-import/30_azure_infrastructure_import.md). -::: - - - - -### Configure the Integration Connector Agent - -Now that we have configured the Cloud Provider, we can configure the Integration Connector Agent to listen to the events coming from the Cloud Provider and save them in the Catalog. - -To do so, you can create a new microservice in your Project starting from the [Integration Connector Agent](/runtime-components/plugins/integration-connector-agent/10_overview.md) plugin. - -![Created Integration Connector Agent based microservice in design section](./img/visualize-infra-ica-design-example.png) - -Now that the Integration Connector Agent microservice is created, we can configure the data pipeline that will be used to process the events coming from the Cloud Provider and save them in the Catalog. - -The Data Pipeline will be configured using already available Integration Connector Agent components, and it will be defined -by a specific [source](/runtime-components/plugins/integration-connector-agent/sources/10_overview.md), -a set of [processors](/runtime-components/plugins/integration-connector-agent/processors/10_overview.md), -and a [sink](/runtime-components/plugins/integration-connector-agent/sinks/10_overview.md) that handles the data processing. - -![Data Pipeline visualization](./img/visualize-infra-ica-data-pipeline.png) - -The components that we will use in the Data Pipeline are: - -- Vendor-specific source: there are three different sources depending on the Cloud Provider you are using: - - [`aws-cloudtrail-sqs`](/runtime-components/plugins/integration-connector-agent/sources/50_aws_cloudtrail_sqs.md) for AWS - - [`gcp-cloud-asset-pubsub`](/runtime-components/plugins/integration-connector-agent/sources/30_gcp_pubsub_asset_inventory.md) for GCP - - [`azure-event-hub`](/runtime-components/plugins/integration-connector-agent/sources/40_azure_activity_log_event_hub.md) for Azure - - All of them will listen to the events coming from the Cloud Provider and produce events that will be processed by the Integration Connector Agent. - Additionally, they also provide a webhook that can be used to trigger a full import. -- [`cloud-vendor-aggregator` processor](/runtime-components/plugins/integration-connector-agent/processors/40_cloud_vendor_aggregator.md): -this component will aggregate the events coming from the Cloud Provider and produce a single event for each resource -- [`mapper` processor](/runtime-components/plugins/integration-connector-agent/processors/20_mapper.md): this component will map the event produced by the [`cloud-vendor-aggregator` processor](/runtime-components/plugins/integration-connector-agent/processors/40_cloud_vendor_aggregator.md) -to a format that complies with the [`infrastructure-component-runtime`](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md) item type in the Catalog. -- [`console-catalog` sink](/runtime-components/plugins/integration-connector-agent/sinks/15_console-catalog.md): this sink will save the event in the Catalog, -using the [`infrastructure-component-runtime`](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md) item type - -:::info -We are saving the items using the [`infrastructure-component-runtime`](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md) item type, -which is a specific item type used to store runtime data for infrastructure components. - -You can find more information about this item type in the [Catalog documentation](/products/console/software-catalog/items-manifest/infrastructure-component-runtime.md). -::: - - - - - -```json -{ - "integrations": [ - { - "source": { - "type": "aws-cloudtrail-sqs", - "queueUrl": "https://sqs.REGION.amazonaws.com/ACCOUNT_ID/awesome-queue-name", - "region": "REGION", - "accessKeyId": "{{AWS_ACCESS_KEY_ID}}", - "secretAccessKey": { "fromEnv": "AWS_SECRET_ACCESS_KEY" }, - "webhookPath": "/aws" - }, - "pipelines": [ - { - "processors": [ - { - "type": "cloud-vendor-aggregator", - "cloudVendorName": "aws", - "authOptions": { - "accessKeyId": "{{AWS_ACCESS_KEY_ID}}", - "secretAccessKey": { "fromEnv": "AWS_SECRET_ACCESS_KEY" } - } - }, - { - "type": "mapper", - "outputEvent": { - "name": "{{name}}", - "runtimeData": { - "name": "{{name}}", - "type": "{{type}}", - "provider": "{{provider}}", - "location": "{{location}}", - "relationships": "{{relationships}}", - "tags": "{{tags}}", - "timestamp": "{{timestamp}}" - } - } - } - ], - "sinks": [ - { - "type": "console-catalog", - "url": "https://your-console-url.com", - "tenantId": "TENANT_ID", - "clientId": "CLIENT_ID", - "clientSecret": { "fromEnv": "CONSOLE_SERVICE_ACCOUNT_CLIENT_SECRET" }, - "itemType": "infrastructure-component-runtime", - "itemNameTemplate": "{{name}} ({{runtimeData.provider}})" - } - ] - } - ] - } - ] -} -``` - - - - - -```json -{ - "integrations": [ - { - "source": { - "type": "gcp-inventory-pubsub", - "projectId": "GCP_PROJECT_ID", - "topicName": "awesome-topic-name", - "subscriptionId": "GCP_PUBSUB_SUBSCRIPTION_ID", - "ackDeadlineSeconds": 15, - "credentialsJson": { "fromEnv": "GCP_CREDENTIALS_JSON" }, - "webhookPath": "/gcp" - }, - "pipelines": [ - { - "processors": [ - { - "type": "cloud-vendor-aggregator", - "cloudVendorName": "gcp", - "authOptions": { - "credentialsJson": { "fromEnv": "GCP_CREDENTIALS_JSON" } - } - }, - { - "type": "mapper", - "outputEvent": { - "name": "{{name}}", - "runtimeData": { - "name": "{{name}}", - "type": "{{type}}", - "provider": "{{provider}}", - "location": "{{location}}", - "relationships": "{{relationships}}", - "tags": "{{tags}}", - "timestamp": "{{timestamp}}" - } - } - } - ], - "sinks": [ - { - "type": "console-catalog", - "url": "https://your-console-url.com", - "tenantId": "TENANT_ID", - "clientId": "CLIENT_ID", - "clientSecret": { "fromEnv": "CONSOLE_SERVICE_ACCOUNT_CLIENT_SECRET" }, - "itemType": "infrastructure-component-runtime", - "itemNameTemplate": "{{name}} ({{runtimeData.provider}})" - } - ] - } - ] - } - ] -} -``` - - - - - -```json -{ - "integrations": [ - { - "source": { - "type": "azure-activity-log-event-hub", - "subscriptionId": "AZURE_SUBSCRIPTION_ID", - "eventHubNamespace": "awesome-eventhub-namespace", - "eventHubName": "awesome-eventhub-name", - "checkpointStorageAccountName": "awesome-storage-account-name", - "checkpointStorageContainerName": "awesome-storage-container-name", - "tenantId": "AZURE_TENANT_ID", - "clientId": { "fromEnv": "AZURE_CLIENT_ID" }, - "clientSecret": { "fromEnv": "AZURE_CLIENT_SECRET" }, - "webhookPath": "/azure" - }, - "pipelines": [ - { - "processors": [ - { - "type": "cloud-vendor-aggregator", - "cloudVendorName": "azure", - "authOptions": { - "tenantId": "AZURE_TENANT_ID", - "clientId": { "fromEnv": "AZURE_CLIENT_ID" }, - "clientSecret":{ "fromEnv": "AZURE_CLIENT_SECRET" } - } - }, - { - "type": "mapper", - "outputEvent": { - "name": "{{name}}", - "runtimeData": { - "name": "{{name}}", - "type": "{{type}}", - "provider": "{{provider}}", - "location": "{{location}}", - "relationships": "{{relationships}}", - "tags": "{{tags}}", - "timestamp": "{{timestamp}}" - } - } - } - ], - "sinks": [ - { - "type": "console-catalog", - "url": "https://your-console-url.com", - "tenantId": "CONSOLE_TENANT_ID", - "clientId": "CLIENT_ID", - "clientSecret": { "fromEnv": "CONSOLE_SERVICE_ACCOUNT_CLIENT_SECRET" }, - "itemType": "infrastructure-component-runtime", - "itemNameTemplate": "{{name}} ({{runtimeData.provider}})" - } - ] - } - ] - } - ] -} -``` - - - - -### Composer page - -Now that we have configured everything needed to gather runtime data and push it to the Catalog, we can create a Composer page to visualize the data in the Console. - -You can create a new [Composer page Extension](/products/console/company-configuration/extensions.md) in your Company using the *Infrastructure Component Runtime Catalog Table* template. - -![Create composer extension modal highlighting Infrastructure Component Runtime Catalog Table template](./img/visualize-infra-composer-extension-creation.png) - -:::caution -The *Infrastructure Component Runtime Catalog Table* template is meant to consume resources from the Catalog of a specific tenant, -therefore you will have to set the `tenantId` filter in order for the page to work properly. - -You **MUST** set the filter value in the `Runtime` Tab filters settings, -you can do this via UI or by manually editing the Advanced configuration: - - - - -- click on `Tabs` in the layout page left sidebar -- in the right sidebar, under Content, press `Edit property` -- this will open a modal where you can see the list of the available Tabs, select `Runtime` -- now press the `Edit property` button in the *filters* sections -- you should now see the preset filters (see the screenshot below), one being `tenantId` with a placeholder value, change it according to your actual Company ID - -![Runtime Tab filters](./img/visualize-infra-composer-extension-creation-runtime-tab.png) - - - - -Switch to the Advanced tab and search for the `YOUR_TENANT_ID` placeholder string to change it. - -![Advanced configuration of Runtime Tab filters](./img/visualize-infra-composer-extension-creation-advanced-tenantid.png) - - - -::: - -#### Add custom columns - -The asset data contained by catalog items contains several pieces of information that are only displayed in a Modal. - -You can add custom columns to the table by adding a new field in the `dataSchema` property via the Advanced configuration. - -For example, if you want to add a column for the `runtimeData.location` field, you can add the following code in the `dataSchema` property: - -```json -{ - // ... other data schema properties, - "resLocation": { - "type": "string", - "label": "Location", - "order": 20, - "formOptions": { - "readOnly": true, - "hidden": true - }, - "visualizationOptions": { - "tag": "div", - "properties": { - "innerHTML": "{{args.[1].resources.runtimeData.location}}" - }, - "sortable": false - } - } - // ... -} -``` - -![Add Column](./img/visualize-infra-composer-extension-add-column-advanced.png) - -### Extend asset data - -Since we are using the `cloud-vendor-aggregator` Integration Connector Agent Processor the data contained within the event is the -[Asset defined by the processor itself](/runtime-components/plugins/integration-connector-agent/processors/40_cloud_vendor_aggregator.md#processor-overview). - -In certain cases, you may want to enrich the data with additional information, such as information relevant to -the same infrastructure component but coming from a different tool (e.g. a monitoring tool that provides additional information about the infrastructure component). - -In these cases you can build a custom [RPC Processor](/runtime-components/plugins/integration-connector-agent/processors/30_rpc_plugin.md) that will act within the -Integration Connector Agent data pipeline and enrich the data with additional information. - -:::tip -For such a use case consider using the [Integration Connector Agent RPC Plugin Processor Template](https://github.com/mia-platform-marketplace/integration-connector-agent-processor) -to create a new repository containing all the necessary files to build a custom Integration Connector agent image -already paired with a custom RPC Plugin Processor. -::: - -In short your Processor implementation could be something like: - -```go -package main -import ( - "context" - - "github.com/mia-platform/integration-connector-agent/entities" -) - -type Asset struct { - Name string `json:"name"` - Type string `json:"type"` - Provider string `json:"provider"` - Location string `json:"location"` - Relationships []string `json:"relationships"` - Tags map[string]string `json:"tags"` - RawData []byte `json:"rawData"` - Timestamp time.Time `json:"timestamp"` -} - -type AssetWithCustomData struct { - Asset - MyCustomField string `json:"myCustomField"` -} - -type MyProcessor struct { - // Add any fields you need for your plugin -} - -func (p *MyProcessor) Init(config []byte) error { - return nil -} - -func (p *MyProcessor) Process(input entities.PipelineEvent) (entities.PipelineEvent, error) { - originalData := input.Data() - - var originalAsset Asset - if err := json.Unmarshal(originalData, &originalAsset); err != nil { - g.logger.WithError(err).Error("Failed to unmarshal original asset data") - return input, err - } - - newAsset := AssetWithCustomData{ - Asset: originalAsset, - MyCustomField: "This is a custom field", - } - newPayload, err := json.Marshal(newAsset) - if err != nil { - g.logger.WithError(err).Error("Failed to marshal new asset data") - return nil, err - } - - output := input.Clone() - output.WithData(newPayload) - return output, nil -} -``` diff --git a/versioned_docs/version-15.0.0/products/mia-platform-suite/rbac_management.md b/versioned_docs/version-15.0.0/products/mia-platform-suite/rbac_management.md index c7b0890223..1983e07b2b 100644 --- a/versioned_docs/version-15.0.0/products/mia-platform-suite/rbac_management.md +++ b/versioned_docs/version-15.0.0/products/mia-platform-suite/rbac_management.md @@ -22,6 +22,7 @@ Mia-Platform's RBAC system is a centralized service designed for granular access - **Input schema** — a JSON Schema file in the *schemas/* directory that defines the structure of *input.rbac*, used for validating and type-checking policy inputs. - **Super Admin** — a global administrative role (*...authz:Super Admin*) with full privileges to manage the entire platform. - **Organization Admin** — an administrative role (*...organization-Super Admin:\*) with full privileges limited to a specific organization. +- **Tenant Admin** — an administrative role with full privileges limited to a specific tenant. - **Keycloak Admin** — an identity-management role, distinct from Super Admin/Organization Admin, that manages users at the organization level directly from the organization's dedicated Keycloak console (e.g., adding or removing users from the organization). - **Scope** — defines the extent of a permission: it can be global ('/') or restricted to a specific path (e.g., */\*). - **Decision helper** — a function (*helpers.decision(input)* in *authz/helpers/acl_context.rego*) that evaluates policies and generates the final decision, attaching the *x-mia-acl-context* header. @@ -88,10 +89,10 @@ Alice's effective permissions are the combination of these two groups' roles. Fr ## What can be managed via API - **Groups**: creation, modification, deletion; member management; role assignment to the group. -- **Users**: creation, modification, deletion, consultation. +- **Users**: creation, invitation, modification, deletion, consultation. - **Roles**: creation, modification, deletion, consultation. - **Tenant**: creation and edit of tenants, also at the individual organization level. -- **Configuration**: reading and updating an organization's settings. +- **Configuration**: reading and updating tenant's settings. - **Service accounts**: registration and deletion — see [Registering a service account](#registering-a-service-account) below. ## Permission matrix @@ -138,7 +139,7 @@ Access legend: In this v15 release, Catalog RBAC management has the following constraints: -- **Roles**: cannot be created, modified, or deleted. The available roles are fixed and correspond to those defined in the [Permission Matrix](#permission-matrix) above. +- **Roles**: cannot be created, modified, or deleted via UX. The available roles are fixed and correspond to those defined in the [Permission Matrix](#permission-matrix) above. - **Groups**: can be created. Groups are the only entity that admins can define in this version, to combine users under a shared set of role assignments. - **Users**: cannot be created. Users can only be **assigned** to existing roles and groups. - **Permissions**: not yet customizable in this phase — permissions are tied to roles as defined in the matrix and cannot be edited individually. @@ -159,7 +160,7 @@ Service accounts are the non-human identities that let external tools and pipeli ### 1. Reach the API -The registration endpoint is reachable through the api-portal published alongside your Mia Platform Suite Home instance — typically at `/documentations/api-portal/`. Only a Super Admin can complete the registration. +The registration endpoint is reachable through the api-portal published alongside your Mia-Platform Suite Home instance — typically at `/documentations/api-portal/`. Only a Super Admin can complete the registration of users in tenant by using this tool. ### 2. Generate a key pair @@ -237,7 +238,62 @@ From the api-portal, call `POST /api/service-accounts/register`, providing the s To remove a service account later, call `DELETE /api/service-accounts/{client_id}` the same way. -## Frequently asked questions +## Requesting an access token + +A registered service account has no password or client secret: it proves its identity by signing a JWT with the private key generated in [step 2](#2-generate-a-key-pair) above. This signed JWT (the *client assertion*) is presented, together with a `client_credentials` grant, to the environment's Identity Provider (Keycloak) token endpoint, which verifies the signature against the public key registered via the JWK's `kid` and, if valid, issues an access token. + +### 1. Build the client assertion + +The client assertion is a `RS256`-signed JWT (RFC 7523) with the following claims: + +| Claim | Value | +| :---- | :---- | +| `iss` | the service account's `client_id` | +| `sub` | the service account's `client_id` | +| `aud` | the token endpoint URL (see below) | +| `jti` | a unique request identifier (e.g. a UUID), preventing replay attacks | +| `iat` | the current timestamp | +| `exp` | a short expiry, e.g. `iat + 300` seconds | + +The JWT header must carry `alg: RS256` and `kid: ` — the `kid` must exactly match the one in the registered JWKS, otherwise the token endpoint cannot locate the public key to verify the signature. + +### 2. Call the token endpoint + +The token endpoint is the environment's Identity Provider (Keycloak), under the relevant realm: + +```text +https:///realms//protocol/openid-connect/token +``` + +```sh +curl -X POST "https:///realms//protocol/openid-connect/token" \ + -H "Content-Type: application/x-www-form-urlencoded" \ + --data-urlencode "grant_type=client_credentials" \ + --data-urlencode "client_id=" \ + --data-urlencode "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \ + --data-urlencode "client_assertion=" \ + --data-urlencode "scope=" +``` + +The requested `scope` must match the product(s) whose APIs the token is meant to call (e.g. `mia:catalog`, or `mia:ai-foundry`, in addition to any product-specific requirement — see each product's API documentation for the exact scopes it expects). + +:::info +**On the Mia-Platform PaaS**, the `organization:*` scope must also be included in every token request, in addition to the product-specific `mia:*` scopes (e.g. `scope=mia:catalog organization:*`). Without it, the PaaS token endpoint will not issue a usable token. +::: + +A successful response looks like: + +```json +{ + "access_token": "eyJ...", + "token_type": "Bearer", + "expires_in": 300 +} +``` + +Use the resulting `access_token` in the `Authorization: Bearer ` header of every API call. Once it expires (`expires_in`), repeat the token request. + +## FAQ ### Who is the Organization Admin and how is this role acquired? @@ -273,13 +329,3 @@ It cannot be created from the Administration interface. A Super Admin must call Currently, tenants from new products and Console tenants do not interact with each other. The same limitation applies to RBAC roles: they cannot be managed from the Administration page on the home page for one from the other. See [Accessing the Administration section](#accessing-the-administration-section) above for more details. -## Advantages of adoption - -The integration of RBAC ensures high standards of security and efficiency: - -- **Reusability**: use of predefined policy templates to accelerate the setup of organizational roles. -- **Configuration integrity**: drastic reduction of manual errors thanks to centralized governance. -- **Least privilege**: technical guarantee that each principal accesses only the minimum set of necessary resources. -- **Operational efficiency**: reduction of management times by eliminating the need for custom configurations on individual APIs. - -Overall, the RBAC model provides a scalable, secure, and maintainable authorization framework, enabling fine-grained access control while simplifying administrative operations across the platform. diff --git a/versioned_docs/version-15.0.0/requirements/installation-guidelines/catalog/connectors/00_overview.md b/versioned_docs/version-15.0.0/requirements/installation-guidelines/catalog/connectors/00_overview.md index e962b5ceb9..89a76450bf 100644 --- a/versioned_docs/version-15.0.0/requirements/installation-guidelines/catalog/connectors/00_overview.md +++ b/versioned_docs/version-15.0.0/requirements/installation-guidelines/catalog/connectors/00_overview.md @@ -36,9 +36,9 @@ Each source page lists the **data types** it exposes inside the mapping context ## Wiring `ibdm` to the Catalog -`ibdm` writes into the Catalog over HTTP, authenticating with a Client ID that must be registered in **two separate places**: a *Connector* item in the Catalog App, used purely for attribution/labeling, and a matching **service account** in Platform Administration, which is where the actual credential (a client secret or a key pair) is minted. +`ibdm` writes into the Catalog over HTTP, authenticating with a Client ID that must be registered in **two separate places**: a *Connector* item in the Catalog App, used purely for attribution/labeling, and a matching **service account** in Platform Administration, which is where the actual credential (an RSA key pair) is minted. -1. **Register a matching service account.** A Super Admin registers a service account with the *same* Client ID through Platform Administration, choosing either a client secret or an RSA key pair (for `private_key_jwt`) as its credential — see [Registering a service account](/products/mia-platform-suite/rbac_management.md#registering-a-service-account). This is the actual credential `ibdm` will authenticate with. In the case of `ibdm` wired to the catalog the needed scopes are `"scope": "service_account mia:catalog"`. +1. **Register a matching service account.** A Super Admin registers a service account with the *same* Client ID through Platform Administration, providing an RSA key pair (for `private_key_jwt`) as its credential — see [Registering a service account](/products/mia-platform-suite/rbac_management.md#registering-a-service-account). This is the actual credential `ibdm` will authenticate with. In the case of `ibdm` wired to the catalog the needed scopes are `"scope": "service_account mia:catalog"`. 2. **Add Item Ingestor role to the matching service account.** Open [Administration Section](/products/mia-platform-suite/rbac_management.md#how-it-works-in-practice) find the created service account and add the needed role `Item Ingestor`. 3. **Register the connector in the Catalog App.** Open **Configuration → Connectors → Add connector**. You will be asked for a `Name`, an optional `Title` and `Description`, a `Client ID`, and a `Provider` / `Category` for UI filtering (see the [Connectors section](/products/catalog/usage/catalog-app.md#connectors) of the Catalog App reference). This only creates the *Connector* item used to attribute ingested items — it does **not** generate any credential. 4. **Configure the destination on `ibdm`.** The endpoint is always required: @@ -47,21 +47,14 @@ Each source page lists the **data types** it exposes inside the mapping context | :------- | :---------- | | `MIA_CATALOG_ENDPOINT` | The Catalog ingestion endpoint, surfaced in the Catalog App connector form. | - `ibdm` then authenticates to the Catalog with **one of two** mechanisms. + `ibdm` itself supports two generic authentication mechanisms (client-credentials with a client secret, or private-key JWT), but **when wiring to the Catalog only private-key JWT is supported**: Catalog service accounts are registered with an RSA key pair (see step 1) and have no client secret, so `MIA_CATALOG_CLIENT_SECRET`/`MIA_CATALOG_AUTH_ENDPOINT` cannot be used against the Catalog target — those variables only apply when pointing `ibdm` at a different, client-secret-based OAuth server. - **Client-credentials (client secret).** The default flow, using the credentials pair provisioned in step 1: + Set `MIA_CATALOG_PRIVATE_KEY_PATH` together with `MIA_CATALOG_CLIENT_ID`. You must also configure at least one of `MIA_CATALOG_ISSUER`, `MIA_CATALOG_ISSUER_METADATA`, or `MIA_CATALOG_TOKEN_ENDPOINT`: | Variable | Description | | :------- | :---------- | | `MIA_CATALOG_CLIENT_ID` | Client ID provisioned for this connector. | - | `MIA_CATALOG_CLIENT_SECRET` | Client Secret provisioned for this connector. | - | `MIA_CATALOG_AUTH_ENDPOINT` *(optional)* | Override of the OAuth token endpoint. Defaults to `/oauth/token`. | - - **Private-key JWT (RFC 7523).** As an alternative to the client secret, `ibdm` can authenticate via private-key JWT client authentication. Set `MIA_CATALOG_PRIVATE_KEY_PATH` (together with `MIA_CATALOG_CLIENT_ID`) *instead of* `MIA_CATALOG_CLIENT_SECRET`. When you do, you must also configure at least one of `MIA_CATALOG_ISSUER`, `MIA_CATALOG_ISSUER_METADATA`, or `MIA_CATALOG_TOKEN_ENDPOINT`: - - | Variable | Description | - | :------- | :---------- | - | `MIA_CATALOG_PRIVATE_KEY_PATH` | Path to a PEM-encoded private key file, used with `MIA_CATALOG_CLIENT_ID` to authenticate via private-key JWT instead of a client secret. | + | `MIA_CATALOG_PRIVATE_KEY_PATH` | Path to a PEM-encoded private key file, used with `MIA_CATALOG_CLIENT_ID` to authenticate via private-key JWT. | | `MIA_CATALOG_ISSUER` | OIDC issuer URL used as both the discovery base and the expected issuer; the discovery document is looked up relative to this value. | | `MIA_CATALOG_ISSUER_METADATA` *(optional)* | Custom URL for the OIDC discovery document used to resolve the token endpoint. Defaults to a lookup relative to `MIA_CATALOG_ISSUER`. | | `MIA_CATALOG_TOKEN_ENDPOINT` *(optional)* | Custom token endpoint. When set, OIDC discovery is skipped entirely and this endpoint is used directly. | diff --git a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/ai-agent-lifecycle-overview.md b/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/ai-agent-lifecycle-overview.md deleted file mode 100644 index 47a3e8d50c..0000000000 --- a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/ai-agent-lifecycle-overview.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: ai-agent-lifecycle-overview -title: AI Agent Lifecycle -sidebar_label: AI Agent Lifecycle ---- - -# AI Agent Lifecycle: From Prototyping to Enterprise-Grade Orchestration - -AI Agents are autonomous systems capable of understanding, reasoning, and acting to achieve specific goals. From customer support chatbots powered by Retrieval-Augmented Generation (RAG) to complex, multi-agent workflows that automate business processes, these systems are transforming how companies operate and innovate. However, building, deploying, and managing the lifecycle of AI agents presents a unique set of challenges. - -## The Challenges of the AI Agent Lifecycle - -Developing and operationalizing AI agents goes far beyond simply connecting to an LLM API. Organizations face significant hurdles in: - -* **Complex Setup and Integration**: Building the foundational infrastructure for an AI agent—including data ingestion pipelines, vector databases, frontend interfaces, and secure API exposure—is a complex and time-consuming task. -* **Data Management and Synchronization**: For RAG-based agents, keeping the knowledge base up-to-date with the latest information requires robust data ingestion and embedding generation processes. -* **Orchestration of Multi-Agent Systems**: Many advanced use cases require multiple specialized agents to collaborate. Orchestrating these interactions, managing state, and handling failures in a distributed system is a major architectural challenge. -* **Governance, Security, and Observability**: As AI agents become critical components of business processes, it's essential to govern their behavior, secure their access to data, and monitor their performance and operational health. -* **Lack of Standardization**: Without a unified platform, different teams may build agents using disparate technologies and approaches, leading to a fragmented and difficult-to-maintain AI ecosystem. - -## The Mia-Platform Solution: a Unified Platform for Building and Managing AI Agents - -**Mia-Platform** provides an integrated solution to manage the entire lifecycle of AI agents, from rapid prototyping to the orchestration and governance of complex, enterprise-grade systems. The end-to-end AI agent lifecycle management ensures context-aware applications that remain compliant and are easier to integrate into existing solutions, ultimately accelerating the time-to-market. - -### Rapidly Build RAG Applications with Marketplace Templates - -Get a head start on building conversational AI agents with ready-to-use components from the **Marketplace**. -* **AI RAG Chat Application**: This application provides a complete, production-ready stack for a RAG-based chatbot. It includes the **RAG Chatbot API** for handling data ingestion (from web pages or files) and generating responses, a React-based frontend, and an **API Gateway** for secure exposure. -* **Customizable Templates**: For more advanced use cases, start with the **AI RAG Chat Template**, which provides the full source code. This allows you to customize every aspect of the agent, from the data chunking strategy to the LLM interaction logic, while still benefiting from a standardized foundation. - -### Orchestrate Complex Workflows with the Flow Manager - -For multi-agent systems, the **Flow Manager Service** acts as a powerful orchestration engine. -* **Design Complex Agent Interactions**: Use the no-code **Flow Manager Configurator** to visually design how multiple agents collaborate to complete a task. Define the sequence of operations, handle branching logic, and manage state transitions in a clear, finite state machine model. -* **Decoupled and Resilient Architecture**: Agents (implemented as microservices) are decoupled via a message broker like Kafka. The Flow Manager sends commands to agents and listens for their response events, creating a resilient system that can handle failures and retries gracefully. - -### Govern and Monitor with the Console - -Treat your AI agents as first-class citizens of your software ecosystem. **Mia-Platform Console** provides the tools to manage their entire lifecycle. -* **Unified Deployment and Management**: Deploy and manage your AI agents just like any other microservice. Configure their resources, environment variables, and endpoints from a single, intuitive interface. -* **Runtime Observability**: Use the **Runtime Area** to monitor the health of your agents, stream their logs in real-time, and troubleshoot issues quickly. -* **Security and Governance**: Apply the same robust governance and security policies to your AI agents as you do to the rest of your applications, including **IAM** for access control and centralized API security through the **API Gateway**. - -### Leverage Platform Data with Mia-Assistant - -Mia-Platform not only helps you build external-facing AI agents but also uses AI to improve the platform experience itself. -* **Mia-Assistant**: An AI-powered assistant integrated into the Console that uses data from your **Software Catalog** and runtime environments to answer questions, perform actions (like debugging or deploying), and provide insights into your platform. - -Mia-Platform offers a standardized, integrated and scalable platform that empowers organizations to move beyond simple AI experiments. You can build, manage and govern a robust ecosystem of AI agents that drive real business value. - diff --git a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/building-custom-ai-agent.md b/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/building-custom-ai-agent.md deleted file mode 100644 index 5307969c2b..0000000000 --- a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/building-custom-ai-agent.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: building-custom-ai-agent -title: Building a Custom AI Agent and Managing its Full Lifecycle -sidebar_label: Building a Custom AI Agent ---- - -### The Scenario - -A legal tech firm wants to build a highly specialized RAG (Retrieval-Augmented Generation) agent for its lawyers. The agent needs to answer complex legal questions based on a proprietary knowledge base of internal case files, legal documents, and contracts, which are stored in various formats (PDFs, DOCX, and text files). - -### The Challenge - -* **Custom Data Sources**: The knowledge base is not a public website. The agent needs to ingest data from secure, internal file systems and databases. -* **Specialized Data Processing**: Legal documents require a specific data chunking strategy. Simple paragraph-based splitting is not effective. The firm needs to implement a custom logic that understands legal clauses and document structure. -* **Governance and Security**: The data is highly confidential. The agent must be deployed in a secure environment, and access to its configuration and data ingestion APIs must be strictly controlled. -* **Full Lifecycle Management**: The firm needs to manage the agent like any other production application, including versioning, monitoring, logging, and CI/CD. - -### The Solution with Mia-Platform - -The team decides that a pre-built plugin is not flexible enough for their needs. They choose to use the **AI RAG Chat Template** from the **Marketplace** to get a head start, and then use the full power of **Mia-Platform Console** to customize and govern the agent. - -1. **Starting from the Template**: The team creates a new microservice from the "AI RAG Chat Template". This provides them with a Git repository containing a fully functional RAG application's source code, including the backend API and data ingestion logic. - -2. **Customizing the Data Ingestion Logic**: - * The developers clone the repository and modify the data ingestion part of the service. They replace the default web scraper with custom code that connects to their internal document management system. - * They implement a sophisticated data chunking algorithm that splits documents based on legal sections and clauses, ensuring that the context provided to the LLM is always relevant. - * They modify the `/api/embeddings/generateFromFile` endpoint to handle their specific file formats and apply the custom logic. - -3. **Deploying as a Standard Microservice**: The custom agent is a standard microservice within their Mia-Platform project. They manage its entire configuration through the Console's **Design Area**: - * They configure **environment variables** to securely connect to their internal systems. - * They set **CPU and memory requests and limits** to ensure the agent has the resources it needs. - * They configure **health probes** (`/-/healthz`, `/-/readyz`) to allow Kubernetes to manage the agent's health. - -4. **Implementing Governance and Security**: - * **Access Control**: Using the **IAM Portal**, they define who can manage the agent's configuration. Only `Senior Developers` are allowed to modify the service's settings. - * **API Security**: The data ingestion endpoint is secured. In the **Endpoints** section, they configure it to require an **API Key** and a specific **User Group Permission**, ensuring that only authorized internal processes can add new documents to the knowledge base. - -5. **Monitoring and Observability**: Once deployed, the Operations team uses the **Runtime Area** to monitor the agent. They can stream its logs in real-time to check the status of data ingestion jobs, monitor its resource consumption, and troubleshoot any issues. - -### The Outcome - -* **Highly Specialized Solution**: The firm successfully built an AI agent tailored to its unique needs, with custom data connectors and processing logic that would have been impossible with an off-the-shelf solution. -* **Full Development Control**: Starting from a template gave them a significant head start, but they retained full control over the source code, allowing for deep customization and future evolution. -* **Enterprise-Grade Governance**: The AI agent is not a standalone, ungoverned application. It is a fully managed component of their software ecosystem, subject to the same security, deployment, and monitoring standards as all their other microservices. -* **Complete Lifecycle Management**: The team manages the agent's entire lifecycle through the Console, from development and deployment to monitoring and maintenance, ensuring a robust and reliable service for their users. - -This use case demonstrates that Mia-Platform is not just a platform for building agents with pre-built components, but is a comprehensive ecosystem for developing, deploying and governing custom, mission-critical and task-specific AI applications. diff --git a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/leveraging-software-catalog-with-mia-assistant.md b/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/leveraging-software-catalog-with-mia-assistant.md deleted file mode 100644 index a0b3d88312..0000000000 --- a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/leveraging-software-catalog-with-mia-assistant.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: leveraging-software-catalog-with-mia-assistant -title: Leveraging the Software Catalog with Mia-Assistant -sidebar_label: Leveraging Software Catalog with Mia-Assistant ---- - -### The Scenario - -An organization has fully embraced Mia-Platform, managing dozens of projects, hundreds of microservices, and a complex cloud infrastructure. As the platform scales, developers and operators find it increasingly difficult to find information and troubleshoot issues efficiently. - -### The Challenge - -* **Information Overload**: Finding specific information—like the owner of a service, its current version in production, or its resource consumption—requires navigating through multiple pages in the Console or querying different systems. -* **High Cognitive Load for Troubleshooting**: When an issue occurs, an operator needs to manually correlate information from different sources. For example, to debug a failing pod, they might need to check its logs, its deployment configuration, recent commits in its Git repository, and the status of its dependencies. -* **Onboarding Complexity**: New team members are overwhelmed by the amount of information and struggle to understand the architecture and dependencies of the systems they are working on. -* **Need for Actionable Insights**: The platform generates a vast amount of data, but turning that data into actionable insights (e.g., identifying optimization opportunities or potential risks) is a manual and time-consuming process. - -### The Solution with Mia-Platform - -The company enables the **AI features** of Mia-Platform Console, turning its platform into an intelligent system that can be queried and managed through natural language. - -1. **Enriching the Software Catalog with Real-Time Data**: The journey begins with data. The team configures the **Integration Connector Agent** to automatically scrape data from their cloud providers (like Azure) and DevOps tools (like GitLab). This data is used to enrich the **Software Catalog**, turning it from a static list of components into a dynamic, real-time representation of their entire software ecosystem. The catalog now knows about every deployed resource, its runtime status, its configuration, and its relationships with other components. - -2. **Enabling AI Capabilities**: In the **Company Settings**, a Company Owner enables the **AI Settings**. This grants **Mia-Assistant**, the AI-powered assistant within the Console, secure access to the enriched data from the Software Catalog and the project configurations. - -3. **Interacting with the Platform via Mia-Assistant**: Now, developers and operators can use Mia-Assistant to get immediate answers and perform actions: - * **A developer** preparing for a release can ask: `"@mia show me the DORA metrics for the checkout project in the last 30 days."` Mia-Assistant queries the platform data and provides an instant report on deployment frequency and change failure rate. - * **An operator** investigating an alert can use the `/debug` command: `"/debug the payment service in production, are there any errors in the logs?"` Mia-Assistant fetches the latest logs from the `payment-service` pod, analyzes them for error patterns, and provides a summary of its findings, often suggesting a root cause. - * **A new team member** trying to understand the architecture can ask: `"@mia what services does the order-service depend on?"` The assistant uses the relationship data in the catalog to provide a clear dependency graph. - * **A platform engineer** can even perform actions: `"@mia deploy the latest version of the user-profile service to the staging environment."` After a confirmation prompt, Mia-Assistant can trigger the deployment pipeline. - -### The Outcome - -* **Drastically Reduced Time to Information**: Team members no longer waste time hunting for information. They get immediate, context-aware answers to their questions through a simple, conversational interface. -* **Accelerated Troubleshooting**: The `/debug` command has become the first step in any troubleshooting process. It automates the initial data gathering and analysis, allowing operators to identify the root cause of issues much faster. -* **Democratized Platform Knowledge**: The institutional knowledge about the platform is no longer confined to a few senior engineers. Anyone can now query the system and get the information they need, which has significantly improved onboarding and collaboration. -* **From Data to Actionable Intelligence**: The platform is no longer just a system for managing configurations; it's an intelligent partner that helps teams make better decisions. Mia-Assistant turns raw data into actionable insights, proactively highlighting risks and suggesting improvements. - -By integrating AI at its core, Mia-Platform Console transforms the developer and operator experience, moving from a traditional UI-based interaction to a conversational, intelligent, and highly efficient way of managing the entire software lifecycle. diff --git a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/orchestrating-multi-agent-ai-workflows.md b/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/orchestrating-multi-agent-ai-workflows.md deleted file mode 100644 index 7d868959d3..0000000000 --- a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/orchestrating-multi-agent-ai-workflows.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: orchestrating-multi-agent-ai-workflows -title: Orchestrating Multi-Agent AI Workflows with Mia-Platform Flow Manager -sidebar_label: Orchestrating Multi-Agent AI Workflows ---- - -### The Scenario - -An insurance company wants to automate its claims processing workflow. The process is complex and requires several distinct steps, each with its own specialized logic, making it unsuitable for a single monolithic AI agent. - -### The Challenge - -* **Complex, Multi-Step Process**: A claim process involves: - 1. **Document Analysis**: Extracting information from a submitted claim form (PDF). - 2. **Fraud Detection**: Analyzing the extracted data against historical patterns to flag suspicious claims. - 3. **Policy Verification**: Checking the customer's policy to ensure the claim is valid and covered. - 4. **Customer Communication**: Notifying the customer of the outcome (approved, rejected, or needs more information). -* **Need for Specialized Agents**: Each step requires a different type of expertise. A single LLM or agent would struggle to perform all these tasks optimally. The company needs a system of specialized agents that can collaborate. -* **Resilience and Error Handling**: The process must be resilient. If one agent fails (e.g., the fraud detection service is temporarily unavailable), the entire workflow shouldn't fail irreversibly. The system needs a way to manage state and handle retries or compensation logic. -* **Lack of Orchestration**: Simply having the agents call each other directly (choreography) would create a brittle, tightly coupled system that is hard to debug and maintain. The company needs a central orchestrator. - -### The Solution with Mia-Platform - -The company decides to model the workflow as a saga and use the **Flow Manager Service** to orchestrate a team of specialized AI agents. - -1. **Implementing Specialized AI Agents**: The AI team develops several microservices, each acting as a specialized agent: - * `Document-Analyzer-Agent`: Uses OCR and an LLM to extract structured data from PDFs. - * `Fraud-Detector-Agent`: A machine learning model that scores a claim's fraud risk. - * `Policy-Verifier-Agent`: A rule-based service that checks the claim against the policy database. - * `Notification-Agent`: A service that sends emails to customers. - Each agent is deployed as a standard microservice in the Mia-Platform Console. - -2. **Designing the Workflow with the Flow Manager**: The team uses the **Flow Manager Configurator**, a no-code graphical tool, to design the entire workflow as a finite state machine. - * They define states like `ClaimReceived`, `DocumentAnalyzed`, `FraudCheckComplete`, `ClaimApproved`, `ClaimRejected`. - * For each state transition, they define the **command** to be sent to an agent and the **events** that agent can produce as a response. For example, from the `DocumentAnalyzed` state, the Flow Manager sends a `DetectFraud` command to the `Fraud-Detector-Agent`. - -3. **Decoupled Communication via Kafka**: The Flow Manager and the agents communicate asynchronously via **Kafka**. The Flow Manager publishes commands, and the agents consume them. After processing a command, an agent publishes an event (e.g., `FraudDetected` or `NoFraudDetected`), which the Flow Manager consumes to move the saga to the next state. - -4. **State Persistency and Visibility**: The Flow Manager is configured to persist the state of each claim's saga in a **CRUD** collection. This provides a complete, real-time audit trail. A support agent can, at any time, look up a claim ID and see its exact status in the workflow. - -### The Outcome - -* **Robust and Scalable Automation**: The company has successfully automated a complex, mission-critical business process. The decoupled, event-driven architecture is highly scalable and resilient. -* **Centralized Orchestration and Visibility**: The entire business logic for the workflow is centralized and visualized in the Flow Manager. It's easy for both business analysts and developers to understand and modify the process. If a step fails, it's immediately visible in the saga's state. -* **Specialized and Maintainable Agents**: Each AI agent is a small, focused microservice that does one thing well. This makes them easy to develop, test, and maintain independently. The company can upgrade the fraud detection model without affecting any other part of the system. -* **Foundation for Hyperautomation**: This multi-agent system becomes the foundation for further automation. New agents (e.g., for sentiment analysis on customer emails) can be easily added to the workflow by simply updating the Flow Manager configuration, and they can cooperate and communicate autonomously. - -By using the Flow Manager as an AI agent orchestrator, the company was able to move beyond simple chatbots and implement a sophisticated, resilient, and manageable multi-agent system that automates a core business process. diff --git a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/prototyping-rag-application.md b/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/prototyping-rag-application.md deleted file mode 100644 index d17dc8a7f9..0000000000 --- a/versioned_docs/version-15.0.0/solutions/ai-agent-lifecycle/prototyping-rag-application.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: prototyping-rag-application -title: Prototyping a RAG Application in Minutes -sidebar_label: Prototyping a RAG Application ---- - -### The Scenario - -A software company wants to reduce the load on its human support agents by providing a 24/7 chatbot that can answer common questions from users. The source of knowledge for the chatbot is the company's existing public documentation website. - -### The Challenge - -* **Time to Market**: The company wants to validate the idea quickly and needs a working prototype in a matter of days, not months. Building the entire RAG (Retrieval-Augmented Generation) pipeline from scratch is not feasible. -* **Technical Complexity**: The team is skilled in web development but has limited experience with AI/ML infrastructure, such as managing vector databases, generating embeddings, and orchestrating LLM calls. -* **User Interface**: They need a simple and intuitive chat interface for users to interact with the agent, but they don't want to spend significant time on frontend development. -* **Integration**: The final solution needs to be securely exposed via an API and integrated into their main website. - -### The Solution with Mia-Platform - -The team uses the **AI RAG Chat** application from the **Mia-Platform Marketplace** to create and deploy a fully functional RAG chatbot in a few simple steps. - -1. **Installing the RAG Application**: From the **Applications** section in the Design Area, the team searches for and creates the "AI RAG Chat" application. With a few clicks, the wizard automatically sets up all the necessary components in their project: - * The **RAG Chatbot API**: A pre-built microservice that handles all the backend logic. - * The **AI RAG Template Chat**: A React-based frontend providing the chat UI. - * An **API Gateway** with pre-configured endpoints to expose both the frontend and the backend API. - -2. **Configuring the Service**: The team navigates to the `rag-chatbot-api` microservice in the Console. - * They configure the **Environment Variables** with their `MONGODB_CLUSTER_URI` (for the vector database) and their `OPENAI_API_KEY`. These are stored as secure project variables. - * They edit the service's **ConfigMap** to specify the LLM and embedding models they want to use (e.g., `gpt-4o-mini` and `text-embedding-3-small`) and the details of their MongoDB collection. - -3. **Ingesting the Knowledge Base**: The team doesn't need to write any data ingestion scripts. They use the **API Portal** to access the APIs exposed by the `rag-chatbot-api` service. - * They make a single `POST` request to the `/api/embeddings/generate` endpoint. - * In the request body, they provide the URL of their documentation website. - The service automatically starts the web scraping process: it crawls the website, extracts the text content, splits it into chunks, generates embeddings using the OpenAI API, and stores them in the MongoDB Atlas vector database. - -4. **Deploying and Testing**: The team saves the configuration and deploys the project. Immediately after the deployment is complete, the chatbot is live and accessible at the project's main URL. They can start asking questions related to their documentation and receive accurate, context-aware answers. - -### The Outcome - -* **Prototype in Minutes**: The team had a fully functional, end-to-end RAG application up and running in less than an hour, a process that would have taken weeks or months if built from scratch. -* **Zero AI/ML Infrastructure Management**: The team didn't have to worry about the complexities of setting up a vector database, managing embedding pipelines, or orchestrating LLM calls. The Marketplace application abstracted all of this away. -* **Seamless Integration**: The solution came with a ready-to-use frontend and was securely exposed via the API Gateway, making it easy to integrate into their existing web properties. -* **Easy to Customize and Evolve**: While the initial prototype was built with a no-code approach, the team has the option to switch to the **AI RAG Chat Template**, which provides the full source code, allowing them to customize and extend the agent's capabilities in the future. - -The AI RAG Chat application from the Marketplace provided the team with an incredible accelerator, enabling them to rapidly validate their idea and deliver a valuable AI-powered solution to their users with minimal effort. diff --git a/versioned_docs/version-15.0.0/solutions/application-development/accelerating-frontend-development.md b/versioned_docs/version-15.0.0/solutions/application-development/accelerating-frontend-development.md deleted file mode 100644 index ead9763265..0000000000 --- a/versioned_docs/version-15.0.0/solutions/application-development/accelerating-frontend-development.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: accelerating-frontend-development -title: Accelerating Frontend Development with Microfrontend Composer -sidebar_label: Accelerating Frontend Development ---- - -### The Scenario - -A company needs to develop a new internal backoffice application for managing its product catalog. The application must be ready in a few weeks and must provide a modern and intuitive user experience for the operators. The development team is small and doesn't have deep expertise in all the latest frontend frameworks. - -### The Challenge - -* **Tight Deadlines**: The time-to-market is extremely short, making it impossible to develop the entire frontend from scratch. -* **Complex Requirements**: The backoffice needs to include functionalities like a searchable product table, forms for creating and editing products, data visualization dashboards, and user management. -* **Need for Consistency**: The UI must be consistent across all pages, but achieving this with custom development is time-consuming. -* **Integration with Existing Services**: The frontend needs to communicate with an existing CRUD service that exposes the product data. - -### The Solution with Mia-Platform - -The development team decides to use **Mia-Platform Microfrontend Composer** to build the backoffice application through a composable approach, leveraging the no-code/low-code capabilities of the platform. - -1. **Application Setup**: The team starts by creating the **Microfrontend Composer Toolkit** application from the Marketplace. This instantly sets up the necessary services, including the `micro-lc` frontend orchestrator and the webserver to serve the application. - -2. **Creating the Main Page with a Table**: Using the **Page Composer**, the team creates the main page of the backoffice. - * They choose the "Base table" template, which provides a pre-configured page with a table, search bar, and buttons for creating new items. - * In the **Connectors & Adapters** section, they connect the page to the existing `products` CRUD endpoint. They use the "Generate Schema" feature to automatically infer the data structure and configure the table columns. - -3. **Configuring Forms for Data Entry**: The template already includes a **Form Modal**. The team customizes the form by: - * Modifying the `dataSchema` to define which fields are editable and which are required. - * Setting up validation rules directly in the schema to ensure data integrity (e.g., price must be a positive number). - -4. **Adding a Details Page with Cards**: To view the details of a single product, the team creates a new page using the "Show info/details page" template. - * This template uses **Card** components to display information in a clear and organized way. - * They configure a `bk-url-parameters-adapter` to read the product ID from the URL, so the page dynamically fetches and displays the data for the selected product. - * Finally, they add a "Detail" button to each row of the main table that navigates to this new page, passing the product ID in the URL. - -5. **Applying Consistent Styling**: The team customizes the overall look and feel of the application by configuring the **Layout** in the Microfrontend Composer. They set the company logo, choose the primary color to match the corporate branding, and define the structure of the navigation menu. - -### The Outcome - -* **Rapid Development**: The entire backoffice application was built and deployed in a matter of days, not weeks. The no-code/low-code approach allowed the team to focus on the user experience rather than on writing boilerplate code. -* **High-Quality and Consistent UI**: By using the pre-built components from the **Back-kit** library, the team created a modern, responsive, and consistent user interface without needing deep frontend expertise. -* **Easy Integration**: Connecting the frontend to the backend CRUD service was a matter of simple configuration, thanks to the integrated components like the `CRUD Client`. -* **Empowered Team**: The development team was able to deliver a complex application on time, demonstrating that composability drastically streamlines application design and configuration. - -Mia-Platform Microfrontend Composer allowed the team to transform a complex requirement into a fully functional application quickly, proving that modern, high-quality frontends can be built with agility and efficiency. diff --git a/versioned_docs/version-15.0.0/solutions/application-development/application-development-overview.md b/versioned_docs/version-15.0.0/solutions/application-development/application-development-overview.md deleted file mode 100644 index 11309227dc..0000000000 --- a/versioned_docs/version-15.0.0/solutions/application-development/application-development-overview.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: application-development-overview -title: Application Development Overview -sidebar_label: Application Development Overview ---- - -# Application Development: Accelerate the Creation of Cloud-Native Applications - -In a market that demands continuous and rapid innovation, the ability to quickly develop, deploy, and iterate on applications is a critical competitive advantage. Modern application development, especially in a cloud-native context, requires tools that not only speed up coding but also ensure quality, security, and scalability from day one. - -## The Challenges of Modern Application Development - -Development teams often face obstacles that slow down the entire software lifecycle and compromise the final quality of the product: - -* **Repetitive and Low-Value Work**: Developers spend a significant amount of time writing boilerplate code for common functionalities like creating REST APIs for data, managing authentication, or orchestrating processes, instead of focusing on the unique business logic that creates value. -* **Complex Frontend Development**: Building modern, modular, and consistent user interfaces is complex. Integrating different frontend components and ensuring a seamless user experience requires specialized skills and significant effort. -* **Integration with Legacy Systems**: Many organizations rely on existing systems. Exposing data from these systems through modern and secure APIs is often a complex and time-consuming process. -* **Managing Complex Distributed Transactions**: In a microservices architecture, ensuring data consistency across multiple services during a business process (like an e-commerce order) is a major challenge that, if not handled correctly, can lead to data corruption. -* **Lack of Secure and Standardized Exposure**: Exposing APIs securely, managing traffic, and applying consistent authentication and authorization policies for each new service is a repetitive and error-prone task. - -## The Mia-Platform Solution: a Composition-based Approach - -**Mia-Platform Console** provides a suite of tools and ready-to-use building blocks that enable an approach based on **composability and reuse**. Instead of building everything from scratch, developers can assemble applications using pre-built, secure, and scalable components, drastically accelerating the time-to-market. - -### Accelerate Frontend Development with Microfrontend Composer - -The **Microfrontend Composer** is a powerful tool for creating modern user interfaces in a no-code/low-code fashion. Developers can: -* **Visually Compose Pages**: Assemble complex pages by dragging and dropping components from the **Back-kit** library, which includes tables, forms, buttons, and charts. -* **Integrate Any Microfrontend**: Incorporate microfrontends built with any technology (React, Angular, Vue) or even legacy applications via iFrame, creating a consistent and integrated user experience. -* **Build Custom Backoffices in Minutes**: Create data management interfaces and internal tools quickly, connecting them directly to your data sources. - -### Create REST APIs on Your Data in Minutes - -With Mia-Platform, you don't need to write code to create CRUD (Create, Read, Update, Delete) APIs on your data. -* **CRUD Service**: A ready-to-use plugin that automatically exposes REST APIs on any MongoDB collection. Simply define your data model in the Console, and the service will handle the API creation, including pagination, filtering, and sorting. -* **Database and Legacy System Integration**: Connect to existing databases or legacy systems and use the CRUD Service to expose their data through a modern and secure API layer, without modifying the original systems. - -### Orchestrate Complex Processes with the Flow Manager - -For managing distributed transactions and complex business processes, Mia-Platform offers the **Flow Manager Service**. -* **Saga Pattern Orchestration**: Visually design and manage complex sagas that coordinate multiple microservices. The Flow Manager handles state management, error handling, and compensation logic, ensuring data consistency even in the event of failures. -* **Decouple Your Microservices**: Avoid direct and fragile communication between services. The Flow Manager acts as a central orchestrator, making the architecture more resilient and easier to maintain. - -### Secure and Govern Your APIs with an API Gateway - -Every endpoint created in Mia-Platform Console is automatically exposed through an **API Gateway**, which provides a centralized point of control for security and traffic management. -* **Centralized Security**: Apply authentication and authorization policies consistently across all your APIs. Integrate with external Identity Providers (IdP) or use static API keys. -* **API Lifecycle Management**: Manage traffic, apply rate limiting, and get a clear view of how your APIs are being used through the **API Portal**, which provides auto-generated and interactive documentation. - -By adopting Mia-Platform's composition-based approach, development teams can stop reinventing the wheel and focus on what truly matters: generating value and delivering innovative features to their users, faster and more securely. diff --git a/versioned_docs/version-15.0.0/solutions/application-development/building-rest-api.md b/versioned_docs/version-15.0.0/solutions/application-development/building-rest-api.md deleted file mode 100644 index 3045e5d86d..0000000000 --- a/versioned_docs/version-15.0.0/solutions/application-development/building-rest-api.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: building-rest-api -title: Building a REST API on Top of a Legacy Database -sidebar_label: Building a REST API ---- - -### The Scenario - -A retail company has a legacy MongoDB database that contains all of its product inventory information. A new mobile application needs to access this data to show product availability to customers. The development team needs to create a modern, secure, and scalable REST API to expose this data, but they don't have the time or resources to write a dedicated microservice from scratch. - -### The Challenge - -* **Time Constraints**: The project has a very tight deadline, and writing, testing, and deploying a new API layer would take several weeks. -* **Lack of Expertise**: The team primarily consists of frontend developers and lacks deep expertise in backend development and API design best practices. -* **Need for Standard API Features**: The API must support standard features like pagination, filtering, sorting, and projection to be efficient for the mobile app. Implementing these from scratch is complex. -* **Security Requirements**: The data is sensitive, so the API must be secured, and access must be controlled. - -### The Solution with Mia-Platform - -The team decides to use **Mia-Platform Console** to create a secure and fully functional REST API without writing a single line of code. - -1. **Connecting the Database**: First, the team configures the connection to the legacy MongoDB database. They create a **secret variable** in the project's environment settings containing the MongoDB connection string. This ensures that the credentials are kept secure. - -2. **Creating the CRUD Service**: From the **Marketplace**, they add the **CRUD Service** plugin to their project. In the service's environment variables, they reference the MongoDB connection string variable they just created. The CRUD Service is a ready-to-use component that automatically handles the logic for interacting with a MongoDB database. - -3. **Defining the Data Model (CRUD Collection)**: In the **MongoDB CRUD** section of the Design Area, the team defines a new "CRUD Collection" named `products`. - * Instead of manually defining all the fields, they use the **"Import fields from data sample"** feature. They provide a small JSON file with an example of a product document from their legacy database. - * The Console automatically infers the data schema, including field names and types (string, number, boolean, etc.). The team quickly reviews and confirms the schema. - -4. **Exposing the REST API (Endpoint)**: In the **Endpoints** section, they create a new endpoint: - * **Base Path**: `/products` - * **Type**: `CRUD` - * **CRUD Base Path**: They select the `/products` internal endpoint exposed by the CRUD Service. - -5. **Securing the Endpoint**: In the endpoint's security settings, they check the **"Authentication required"** box and define a **User Group Permission** (e.g., `groups.mobile_app`) to ensure that only authenticated clients belonging to the correct group can access the API. - -6. **Deploying the Solution**: The team saves the configuration and deploys the project. - -### The Outcome - -* **API Ready in Minutes**: In less than an hour, the team had a fully functional, production-ready REST API exposing their legacy data. There was no need for backend coding, which would have taken weeks. -* **Rich Features Out-of-the-Box**: The API automatically supports: - * **GET `/products/`**: To list all products, with support for pagination (`_l`, `_sk`), filtering (`_q`), sorting (`_s`), and projection (`_p`). - * **GET `/products/:id`**: To retrieve a single product. - * **POST `/products/`**: To create a new product. - * **PATCH `/products/:id`**: To update a product. - * **DELETE `/products/:id`**: To delete a product. -* **Secure by Design**: The endpoint is protected by the API Gateway and the Authorization Service, ensuring that only authorized requests can access the data. -* **Empowered Frontend Team**: The frontend developers were unblocked immediately and could start developing the mobile app against a real, well-documented API (available in the **API Portal**). - -Mia-Platform Console, with its powerful no-code/low-code components like the CRUD Service, allowed the team to overcome their lack of backend expertise and deliver a critical API on a tight schedule, demonstrating how abstracting common patterns can dramatically accelerate development. diff --git a/versioned_docs/version-15.0.0/solutions/application-development/orchestrating-complex-business-processes.md b/versioned_docs/version-15.0.0/solutions/application-development/orchestrating-complex-business-processes.md deleted file mode 100644 index 839a76fc0f..0000000000 --- a/versioned_docs/version-15.0.0/solutions/application-development/orchestrating-complex-business-processes.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: orchestrating-complex-business-processes -title: Orchestrating Complex Business Processes with Flow Manager -sidebar_label: Orchestrating Complex Business Processes ---- - -### The Scenario - -An e-commerce company is building a new order processing system. The process is complex and involves multiple microservices: one for checking inventory, one for processing payments, and one for arranging shipments. If any of these steps fail, the entire transaction must be rolled back to maintain data consistency. - -### The Challenge - -* **Distributed Transaction Management**: Coordinating actions across multiple services is hard. A simple direct communication (choreography) approach, where services call each other, would create a fragile and tightly coupled system, often called a "distributed monolith". -* **Data Consistency**: If the payment is successful but the shipment fails, how do you handle the refund? Ensuring data consistency across different databases (inventory, payments, shipments) is a major challenge. -* **Error Handling and Compensation**: The system needs robust error handling. For every action, a corresponding "compensation" action (or rollback) must be defined and triggered in case of failure. Managing this logic within each service is complex and duplicates effort. -* **Lack of Visibility**: With a choreographed approach, it's very difficult to understand the overall state of an order. Where did it fail? Why? Diagnosing and debugging problems becomes a nightmare. - -### The Solution with Mia-Platform - -The development team decides to implement the **Saga Pattern** using the **Flow Manager Service**, an orchestration engine available in the Mia-Platform Marketplace. - -1. **Designing the Saga as a Finite State Machine**: First, the team uses the **Flow Manager Configurator**, a no-code graphical interface in the Console, to design the entire order process as a finite state machine. They define the states: - * `OrderCreated` (initial state) - * `InventoryChecked` - * `PaymentProcessed` - * `OrderShipped` (final success state) - * `OrderFailed` (final failure state) - -2. **Defining Commands and Events**: For each state transition, they define **commands** (actions to be performed by other services) and **events** (outcomes of those actions). - * From `OrderCreated`, the Flow Manager sends a `CheckInventory` command. - * The Inventory Service processes the command and responds with either an `InventoryCheckOK` or `InventoryCheckKO` event. - * Based on the event, the Flow Manager moves the saga to the next state (`InventoryChecked` or `OrderFailed`). This logic is repeated for the payment and shipment steps. - -3. **Configuring the Communication Protocol**: The team configures the Flow Manager to communicate with the other microservices via **Kafka**. This creates a decoupled and resilient architecture. The Flow Manager publishes commands on a `commands-topic`, and listens for events on an `events-topic`. - -4. **Implementing the Microservices**: The existing microservices (Inventory, Payment, Shipment) are slightly modified to: - * Consume commands from the Kafka topic. - * Perform their business logic. - * Produce the corresponding outcome event back to the events topic. - They don't need to know anything about the overall process; they just do their job and report the result. - -5. **Persistency and Visibility**: The Flow Manager is configured to use a **CRUD** collection to persist the state of each saga instance. This means that at any time, the team can query the CRUD to know the exact state of a specific order, providing complete visibility into the process. - -### The Outcome - -* **Decoupled and Resilient Architecture**: The microservices are completely decoupled. The Flow Manager is the single source of truth for the process, making the system easier to understand, maintain, and evolve. If a service is temporarily down, the saga remains in its current state, and can be resumed later. -* **Guaranteed Data Consistency**: The Saga pattern ensures that the process is either completed successfully or fully rolled back. The Flow Manager handles the compensation logic (e.g., sending a `RefundPayment` command if the shipment fails), guaranteeing that the system never ends up in an inconsistent state. -* **Centralized Logic and Visibility**: The entire business process is defined and visualized in one place—the Flow Manager Configurator. This makes it easy for both technical and business stakeholders to understand and modify the flow. Debugging becomes simple, as the state of each order is persisted and auditable. -* **Accelerated Development**: The developers of the individual microservices didn't have to worry about the complexity of the overall transaction. They focused solely on their domain logic, leading to faster development and higher quality code. - -The Flow Manager Service allowed the team to tame the complexity of distributed transactions, delivering a robust and reliable order processing system while maintaining a loosely coupled and scalable microservices architecture. diff --git a/versioned_docs/version-15.0.0/solutions/cloud-operations/cloud-operations-overview.md b/versioned_docs/version-15.0.0/solutions/cloud-operations/cloud-operations-overview.md deleted file mode 100644 index 0121e7dfa7..0000000000 --- a/versioned_docs/version-15.0.0/solutions/cloud-operations/cloud-operations-overview.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: cloud-operations-overview -title: Cloud Operations Overview -sidebar_label: Cloud Operations Overview ---- - -# Cloud Operations: Simplify, Secure, and Optimize Your Cloud-Native Infrastructure - -Cloud Operations (CloudOps) encompasses the processes and practices required to manage, secure, and optimize applications and infrastructure in cloud environments. As organizations increasingly adopt multi-cloud and hybrid strategies, CloudOps teams face the challenge of maintaining reliability, controlling costs, and ensuring security across a complex and distributed landscape. - -## The Challenges of Modern Cloud Operations - -Cloud-native environments, while powerful, introduce a new set of operational challenges that can strain resources and increase risk if not managed effectively: - -* **Multi-Cloud and Hybrid Complexity**: Managing disparate environments across different cloud providers (AWS, GCP, Azure) and on-premise data centers leads to fragmented tools, inconsistent processes, and a lack of unified visibility. -* **Ensuring Reliability and Uptime**: Monitoring the health of hundreds of microservices, diagnosing failures in real-time, and ensuring high availability requires advanced observability and rapid troubleshooting capabilities. -* **Cost Optimization**: Without a clear understanding of resource consumption, organizations risk over-provisioning infrastructure, leading to significant and unnecessary cloud spending. Fine-tuning resource requests and limits is a continuous and complex task. -* **Security and Compliance**: Securing a distributed infrastructure, managing access credentials, and ensuring that all deployments comply with security policies is a constant battle. Traditional, manual deployment methods can introduce vulnerabilities. -* **Manual and Error-Prone Deployments**: Relying on custom scripts and manual processes for deployment is not scalable, is prone to human error, and lacks a proper audit trail, making it difficult to meet compliance requirements. - -## The Mia-Platform Solution: a Centralized Control Plane for Your Infrastructure - -**Mia-Platform Console** acts as a unified control plane, providing CloudOps teams with the tools they need to manage the entire operational lifecycle of their cloud-native applications from a single interface. It empowers Ops teams to automate processes, improve security, and optimize costs, all while providing a stable and reliable platform for developers. - -### Unify Multi-Cloud and Hybrid Management - -The Console allows you to connect and manage all your Kubernetes clusters, regardless of where they are running. -* **Centralized Cluster Management**: Add, monitor, and manage clusters from different cloud providers (GKE, EKS, AKS) and on-premise environments from a single dashboard. This provides a unified view of your entire infrastructure. -* **Standardized Deployments**: Deploy applications consistently across any cluster using standardized **Project Blueprints** and CI/CD pipelines, eliminating configuration drift between environments. - -### Proactive Monitoring and Real-Time Troubleshooting - -The **Runtime Area** of the Console offers deep visibility into the health and performance of your deployed applications. -* **Live Pod Monitoring**: View the real-time status of all pods, check their CPU and memory usage, and identify issues like crashes or restarts instantly. -* **Centralized Log Aggregation**: Access and stream logs from any container without needing to use `kubectl` or access the cluster directly. This drastically speeds up troubleshooting. -* **Integrated Dashboards**: Embed your existing Grafana or Kibana dashboards directly into the Console, providing a single pane of glass for both application metrics and operational health. - -### Optimize Resource Usage and Costs - -Mia-Platform provides the tools to right-size your applications and avoid wasted cloud spend. -* **Resource Request & Limit Management**: Easily configure CPU and memory requests and limits for each microservice through a simple UI, preventing resource contention and over-provisioning. -* **Automated Scaling**: Configure **Horizontal Pod Autoscaler (HPA)** to automatically scale your services based on CPU usage, ensuring you only use the resources you need to handle the current load. - -### Adopt a Secure GitOps Deployment Strategy - -Move away from risky, manual deployments by adopting a modern, pull-based GitOps workflow with the **Enhanced Project Workflow**. -* **Git as the Single Source of Truth**: The desired state of your infrastructure and applications is declared in a Git repository. Tools like ArgoCD or Flux can be used to automatically synchronize the cluster's state with the repository. -* **Enhanced Security**: A GitOps approach minimizes the need for direct cluster access. Changes are made through pull requests, providing a clear and auditable workflow. This reduces the attack surface and prevents unauthorized changes. -* **Reliable and Auditable Deployments**: Every change is version-controlled in Git, creating an immutable audit trail. Rolling back to a previous state is as simple as reverting a commit. - -With Mia-Platform Console, CloudOps teams can transition from being reactive firefighters to proactive enablers, building a secure, reliable, and cost-efficient platform that accelerates the entire organization. diff --git a/versioned_docs/version-15.0.0/solutions/cloud-operations/monitoring-and-troubleshooting-runtime.md b/versioned_docs/version-15.0.0/solutions/cloud-operations/monitoring-and-troubleshooting-runtime.md deleted file mode 100644 index 39ffb9b0f7..0000000000 --- a/versioned_docs/version-15.0.0/solutions/cloud-operations/monitoring-and-troubleshooting-runtime.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: monitoring-and-troubleshooting-runtime -title: Monitoring and Troubleshooting Runtime with Mia-Platform Console -sidebar_label: Monitoring and Troubleshooting Runtime ---- - -### The Scenario - -An online retail platform experiences intermittent performance issues during peak traffic hours. The CloudOps team struggles to quickly identify the root cause because they have to manually sift through logs from multiple microservices and correlate events across different systems. - -### The Challenge - -* **Reactive Troubleshooting**: Problems are often reported by users before the Ops team is even aware of them. The team lacks a proactive way to monitor the health of the system. -* **Slow Root Cause Analysis**: When an issue occurs, the team has to SSH into different machines or use multiple `kubectl` commands to get logs from various pods. This process is slow, cumbersome, and requires deep Kubernetes expertise. -* **Information Silos**: Metrics are in one system (Grafana), logs are in another (ELK stack), and Kubernetes events are accessed via the command line. Correlating information between these systems is a manual and time-consuming task. -* **High Mean Time to Resolution (MTTR)**: The combination of these factors leads to a high MTTR, meaning services stay degraded for longer, impacting customer experience and revenue. - -### The Solution with Mia-Platform - -The CloudOps team starts leveraging the **Runtime Area** of **Mia-Platform Console** as their primary tool for monitoring and troubleshooting. - -1. **Centralized Health Dashboard**: The team uses the **Pods** view in the Runtime Area as their main health dashboard. They can see at a glance the status of every pod in a specific environment. The color-coded status indicators (e.g., `OK`, `Warning`) immediately draw their attention to pods that are in a crash loop, pending, or have containers that are not ready. - -2. **Real-Time Log Streaming**: During a period of high traffic, they notice a pod for the `payment-service` turning to a `Warning` state due to frequent restarts. Instead of using `kubectl`, the operator simply clicks on the pod's name directly in the Console. - * They navigate to the **Logs** tab and can immediately stream the logs from the failing container. They discover a recurring `OutOfMemory` error in the logs. - -3. **Inspecting Pod Events**: To understand why the pod is being killed, they switch to the **Events** tab for that pod. They see a series of events from the Kubernetes scheduler indicating that the pod was terminated due to exceeding its memory limit. - -4. **Rapid Remediation**: Having identified the root cause in minutes, the team takes immediate action. - * They navigate back to the **Design Area** of the Console. - * They find the `payment-service` microservice and go to its configuration. - * They increase the **Memory Limit** for the service from `150Mi` to `300Mi`. - * They save the configuration and trigger a deploy to the production environment. - -5. **Verifying the Fix**: After the deploy is complete, they return to the **Runtime Area**. They see the new `payment-service` pod running in a healthy `OK` state. They continue to monitor its resource usage and confirm that the `OutOfMemory` errors have stopped. - -### The Outcome - -* **Drastically Reduced MTTR**: The team was able to identify, diagnose, and resolve a production issue in under 15 minutes, a process that previously could have taken hours. -* **Proactive Monitoring**: The centralized dashboard allowed them to spot the issue as it was happening, before it caused a major outage. -* **Democratized Troubleshooting**: Even junior operators who are not `kubectl` experts can now effectively troubleshoot issues. All the necessary information (pod status, logs, events) is available in an intuitive UI. -* **Integrated Workflow**: The team seamlessly moved from monitoring (Runtime Area) to configuration management (Design Area) and back, all within the same platform, creating a highly efficient feedback loop. - -The Runtime Area of Mia-Platform Console has become the mission control center for the CloudOps team, empowering them to ensure the reliability and performance of their applications proactively and efficiently. diff --git a/versioned_docs/version-15.0.0/solutions/cloud-operations/simplifying-multi-cloud-management.md b/versioned_docs/version-15.0.0/solutions/cloud-operations/simplifying-multi-cloud-management.md deleted file mode 100644 index acdf085579..0000000000 --- a/versioned_docs/version-15.0.0/solutions/cloud-operations/simplifying-multi-cloud-management.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: simplifying-multi-cloud-management -title: Simplifying Multi-Cloud Management with Mia-Platform Console -sidebar_label: Simplifying Multi-Cloud Management ---- - -### The Scenario - -An international corporation has a hybrid cloud strategy. Their production workloads are split between a managed Kubernetes service on AWS (EKS) for scalability and an on-premise Kubernetes cluster for data-sensitive applications. The CloudOps team struggles to manage these two distinct environments. - -### The Challenge - -* **Tool Sprawl**: The team uses different sets of tools and scripts to deploy and monitor applications on EKS versus the on-premise cluster, leading to duplicated effort and increased complexity. -* **Inconsistent Configurations**: Applications deployed on-premise often have slightly different configurations than those on EKS (e.g., for networking or storage), leading to "it works on my cloud" problems and making it difficult to move workloads between environments. -* **Lack of Unified Visibility**: To check the health of the entire system, operators have to switch between different dashboards and terminals (AWS Console, Lens, custom scripts), making it impossible to get a holistic, real-time view. -* **Complex Access Management**: Managing user access and permissions for two separate environments is cumbersome and error-prone, increasing the security risk. - -### The Solution with Mia-Platform - -The CloudOps team adopts **Mia-Platform Console** as a centralized control plane to manage both their AWS and on-premise clusters. - -1. **Connecting All Clusters to the Console**: From the **Clusters** section at the Company level, the team connects both the EKS and the on-premise Kubernetes clusters. They provide the necessary credentials (like service account tokens) for each cluster, and the Console establishes a secure connection. Now, both clusters are visible and manageable from a single interface. - -2. **Standardizing Environments Across Clusters**: In the **Project Blueprint**, they define the company's standard environments (e.g., `Development`, `Staging`, `Production`). They then map these logical environments to the physical clusters: - * `Development` and `Staging` environments are configured to deploy on a specific namespace in the on-premise cluster. - * The `Production` environment is configured to deploy on the EKS cluster in AWS. - -3. **Unified Deployment Process**: The development teams now use a single, consistent process to deploy their applications, regardless of the target cluster. When they trigger a deploy from the Console to the `Production` environment, the pipeline automatically uses the correct credentials and context for the EKS cluster. When they deploy to `Development`, the same pipeline targets the on-premise cluster. This eliminates configuration drift. - -4. **Centralized Monitoring and Observability**: The Ops team uses the **Runtime Area** in the Console to monitor both environments. They can switch between the `Production` (EKS) and `Development` (on-premise) environments with a single click, viewing pod status, streaming logs, and checking resource usage in a unified way. They also embed their Grafana dashboards, which collect metrics from both clusters, directly into the Console's **Dashboard** section. - -### The Outcome - -* **Single Pane of Glass**: The CloudOps team now manages their entire hybrid infrastructure from one place. They have a unified view of all their clusters, namespaces, and applications, drastically reducing operational complexity. -* **Consistent and Portable Workloads**: Since deployments are standardized, applications can be moved between the on-premise and cloud environments with minimal changes, providing true workload portability. -* **Improved Troubleshooting Speed**: When an issue arises, the team doesn't waste time figuring out which tool to use. They go directly to the Console's Runtime Area, select the environment, and start debugging immediately, whether the problem is in the cloud or on-premise. -* **Simplified Governance**: Access control is managed centrally through the Console's IAM, ensuring that user permissions are applied consistently across all connected clusters. Automated policies and controls guarantee security and compliance best practices by design. - -Mia-Platform Console has provided the organization with a powerful abstraction layer over their hybrid infrastructure, enabling teams to take full advantage of multi-cloud without the associated operational overhead. diff --git a/versioned_docs/version-15.0.0/solutions/data-integration/create-real-time-data-aggregation.md b/versioned_docs/version-15.0.0/solutions/data-integration/create-real-time-data-aggregation.md deleted file mode 100644 index 8359442613..0000000000 --- a/versioned_docs/version-15.0.0/solutions/data-integration/create-real-time-data-aggregation.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: create-real-time-data-aggregation -title: Create a Real-Time Data Aggregation with Fast Data Single Views -sidebar_label: Create Real-Time Data Aggregation ---- - -### The Scenario - -A multi-brand retail company has its customer data spread across multiple, disconnected systems. This fragmentation makes it impossible to have a unified understanding of their customers' behavior and preferences. - -### The Challenge - -* **Data Silos**: - * Customer personal information (name, email) is in a **Salesforce CRM**. - * Order history is in an **e-commerce platform**. - * Product browsing history and marketing preferences are in a **HubSpot marketing automation tool**. - * Development team activities and product releases are tracked in **GitHub repositories**. - * Customer support tickets and issue tracking data are stored in **Jira Service Management**. - * Cloud infrastructure logs and security events are scattered across **AWS CloudTrail** and **Azure Activity Logs**. -* **Inconsistent Customer Experience**: When a customer calls support, the agent doesn't have a complete view of their recent orders or marketing interactions, leading to a frustrating and disjointed experience. -* **Ineffective Marketing Campaigns**: The marketing team cannot create personalized campaigns because they cannot segment customers based on their combined purchase and browsing history. -* **Slow Batch Processes**: The company has a nightly batch process that tries to unify this data in a data warehouse, but the information is always stale by up to 24 hours, making real-time personalization impossible. - -### The Solution with Mia-Platform - -The company leverages **Integration Connector Agent** and **Fast Data Engine 2.0** to create a unified, real-time customer 360° view. - -1. **External Data Ingestion**: **Integration Connector Agent** connects to GitHub, Jira, AWS CloudTrail, and Azure Activity Logs, synchronizing development activities, support tickets, and infrastructure events directly into MongoDB collections. - -2. **Real-Time Data Capture**: **Mongezium CDC** captures changes from all data sources (CRM, e-commerce, marketing platforms, and external systems) and streams them to Kafka topics with high performance. - -3. **Data Transformation and Aggregation**: **Farm Data** combines multiple data streams into a unified customer profile, while **Stream Processor** enriches and transforms data using JavaScript logic. - -4. **Unified Single View Creation**: **Kango** persists the aggregated customer data to MongoDB, creating the `customer_sv` collection with complete 360° customer profiles that include traditional business data plus development activities, support interactions, and infrastructure insights. - -5. **API Exposure**: Modern REST APIs expose the unified customer single view, providing millisecond response times for applications requiring complete customer context. - -### The Outcome - -* **Comprehensive 360° Customer View**: The company now has a single, real-time view combining traditional customer data with technical and operational insights. A document in the `customer_sv` collection might look like this: - ```json - { - "email": "jane.doe@example.com", - "name": "Jane Doe", - "crm_info": { ... }, - "order_history": [ { ... }, { ... } ], - "marketing_preferences": { ... }, - "support_tickets": [ { ... } ], - "product_interactions": { ... } - } - ``` -* **Personalized Customer Experience**: The new customer support portal, built with **Microfrontend Composer**, calls the `/customers-sv` endpoint. When a customer calls, the support agent instantly sees their complete history, enabling personalized and efficient service. -* **Targeted and Effective Marketing**: The marketing team can now run highly targeted campaigns. For example, they can create a segment of customers who have viewed a specific product category but have not made a purchase in the last 30 days. -* **Foundation for New Applications**: The `customer_sv` becomes a valuable asset for the entire company. New applications, like a recommendation engine or a loyalty program app, can be built quickly on top of this reliable and real-time data source. - -By leveraging Fast Data Single Views, the company broke down its data silos and transformed its fragmented data into a strategic asset, that is to say unified business data as a product. Single Views are easily discoverable, reusable and governed across all layers of the organization, enabling a new level of personalization and operational efficiency. diff --git a/versioned_docs/version-15.0.0/solutions/data-integration/data-integration-overview.md b/versioned_docs/version-15.0.0/solutions/data-integration/data-integration-overview.md deleted file mode 100644 index 36b1dfa06b..0000000000 --- a/versioned_docs/version-15.0.0/solutions/data-integration/data-integration-overview.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -id: data-integration-overview -title: Data Integration Overview -sidebar_label: Data Integration Overview ---- - -# Data Integration: Unlock and Unify Your Data in Real-Time - -Data Integration is the process of combining data from different sources to provide users with a unified, single view of that data. In modern enterprise architectures, data is often fragmented across various systems of record (SoRs), databases, and third-party applications. This creates data silos that hinder innovation, slow down decision-making, and make it difficult to build cohesive customer experiences. - -## The Challenges of Modern Data Integration - -As companies evolve, they face significant hurdles in making their data accessible, scalable, and consistent across the organization: - -* **Legacy System Bottlenecks**: Many critical business systems (like ERPs, mainframes, or legacy databases) were not designed for the high-volume, low-latency read requests of modern web and mobile applications. Direct queries can easily overload these systems, causing performance degradation and even outages. -* **Data Silos**: Customer, product, and operational data is often scattered across multiple applications (CRM, e-commerce, marketing platforms). Creating a unified view requires complex and fragile point-to-point integrations, which are typically slow batch processes. -* **Lack of Real-Time Insights**: Traditional data integration methods often rely on nightly ETL (Extract, Transform, Load) jobs. This means that business decisions and customer-facing applications are based on data that is up to 24 hours old, which is unacceptable in today's fast-paced market. -* **High Development Cost for Data Access**: For every new application that needs data, developers often have to build custom integration logic, which is time-consuming, duplicates effort, and increases the maintenance burden. - -## The Modern Solution: Integration Connector Agent and Fast Data Engine 2.0 - -**Mia-Platform** addresses these data integration challenges through two complementary technologies: the **Integration Connector Agent** for external data ingestion and the **Fast Data Engine 2.0** for high-performance real-time processing. - -### External Data Ingestion with Integration Connector Agent - -The **Integration Connector Agent** connects to external sources and synchronizes changes between various systems and MongoDB. It supports multiple data sources including GitHub, Jira, Google Cloud Platform, AWS CloudTrail, and Azure Activity Logs. The agent processes data through configurable pipelines and delivers it to MongoDB collections, creating a unified entry point for external data. - -### Real-Time Processing with Fast Data Engine 2.0 - -**Fast Data Engine 2.0** revolutionizes data processing through four specialized workloads that replace traditional monolithic components: - -* **Mongezium CDC**: Captures changes from MongoDB collections and streams them to Kafka topics with high performance and fault tolerance. -* **Stream Processor**: Transforms data using secure JavaScript sandbox environments, supporting both stateless and stateful processing. -* **Farm Data**: Aggregates multiple data streams into one, structured data product. -* **Kango**: Persists processed data from Kafka to MongoDB with optimized throughput and transaction support. - -### Unified Real-Time Data Architecture - -This integrated approach creates a seamless data flow: external sources feed into MongoDB via Integration Connector Agent, changes are captured by Mongezium CDC, data is transformed through Stream Processor, aggregated by Farm Data, and persisted by Kango. The result is a unified, real-time data architecture that eliminates silos and enables immediate insights across all connected systems. - -## Unleashing Business Value from Unified Data - -Once your data integration architecture is in place and single views are persistently stored through Kango, the real business value begins to emerge. The unified, real-time data becomes the foundation for multiple high-impact use cases across the organization. - -### Dashboard and Analytics - -With consolidated single views, building **real-time dashboards** becomes straightforward and performant: - -* **Executive Dashboards**: Create comprehensive views of business KPIs that update in real-time, combining data from sales, marketing, operations, and financial systems. -* **Operational Monitoring**: Build dashboards that monitor system health, transaction volumes, and user behavior patterns with live data updates. -* **Customer 360 Views**: Present unified customer profiles that aggregate data from CRM, e-commerce, support tickets, and interaction history. - -### Machine Learning and AI Integration - -The structured, real-time single views provide the perfect data foundation for **machine learning workflows**: - -* **Feature Engineering**: Use consistently formatted data from multiple sources as features for ML models without complex preprocessing. -* **Real-Time Predictions**: Feed live data directly into ML inference pipelines for dynamic recommendations, fraud detection, or predictive maintenance. -* **Model Training**: Leverage historical single view data for training models with complete, unified datasets rather than fragmented sources. - -### Business Intelligence and Reporting - -Transform decision-making capabilities with **comprehensive BI solutions**: - -* **Cross-Functional Reports**: Generate reports that span multiple business areas by leveraging the unified data model. -* **Trend Analysis**: Perform historical analysis on consistent data structures that maintain referential integrity across all source systems. -* **Data Warehousing**: Export single views to data warehouses for complex OLAP operations and long-term analytical storage. - -### Backoffice Applications - -Empower internal teams with **purpose-built backoffice tools**: - -* **Customer Support Portals**: Build internal tools that provide support agents with complete customer context from multiple touchpoints. -* **Operations Management**: Create administrative interfaces for managing products, orders, and customer data with real-time visibility. -* **Compliance and Auditing**: Develop tools that track data lineage and provide audit trails across all integrated systems. - -### Third-Party Application Integration - -Serve external partners and applications through **standardized data APIs**: - -* **Partner Portals**: Provide external partners with real-time access to relevant business data through secure API endpoints. -* **Mobile Applications**: Power mobile apps with consistent, up-to-date information from the unified data layer. -* **Microservices Architecture**: Support distributed microservices with reliable, real-time data access patterns. - -### Lightweight, On-Demand Aggregation with MongoDB Views - -For simpler use cases that don't require the full power of an event-driven architecture, Mia-Platform Console also supports the creation of **MongoDB Views**: - -* **On-the-Fly Aggregation**: A MongoDB View is a virtual collection whose content is defined by a MongoDB aggregation pipeline that can join data from multiple collections at query time. -* **Simplicity and Speed**: This is a perfect solution for backoffice dashboards or internal tools that need to display combined data without the overhead of creating a new persistent collection or a Fast Data pipeline. - -## Competitive Advantage Through Unified Data - -By leveraging Integration Connector Agent and Fast Data Engine 2.0, organizations can break down data silos, unlock the value of their legacy systems, and build a modern, real-time data integration architecture. The result is not just technical improvement, but a fundamental business advantage: the ability to make data-driven decisions in real-time, deliver superior customer experiences, and rapidly adapt to market changes with complete visibility across all business operations. diff --git a/versioned_docs/version-15.0.0/solutions/data-integration/scaling-legacy-system.md b/versioned_docs/version-15.0.0/solutions/data-integration/scaling-legacy-system.md deleted file mode 100644 index 91eebc8e6c..0000000000 --- a/versioned_docs/version-15.0.0/solutions/data-integration/scaling-legacy-system.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: scaling-legacy-system -title: Scaling a Legacy System of Record with Fast Data Projections -sidebar_label: Scaling a Legacy System ---- - -### The Scenario - -A large insurance company relies on a monolithic, on-premise mainframe system as its System of Record (SoR) for customer policies. This system is reliable for transactional writes but is slow and cannot handle the high volume of read requests from new digital channels, such as a customer-facing web portal and a mobile app. - -### The Challenge - -* **Performance Bottlenecks**: Every time a customer logs into the new portal to view their policy details, a query is sent directly to the mainframe. During peak hours, this high volume of read requests is causing the mainframe to slow down, affecting critical business operations. -* **High Latency for Users**: The slow response times from the SoR result in a poor user experience on the web portal and mobile app, with pages taking several seconds to load. -* **Risk of Outages**: The IT team is concerned that a sudden spike in traffic from the digital channels could overload and crash the mainframe, leading to a major business outage. -* **Development Blockers**: Developers building new features are constrained by the mainframe's limited query capabilities and slow performance, hindering innovation. - -### The Solution with Mia-Platform - -The architecture team leverages **Fast Data Engine 2.0** to create a modern, high-performance read layer that shields the mainframe from traffic spikes, implementing a CQRS (Command Query Responsibility Segregation) pattern. - -1. **Real-Time Data Capture**: **Mongezium CDC** captures all changes from the mainframe's database and streams them to Kafka topics with high throughput and fault tolerance. - -2. **Data Transformation**: **Stream Processor** transforms and enriches the policy data in real-time using secure JavaScript environments, creating optimized data structures for fast querying. - -3. **Data Persistence**: **Kango** persists the processed policy data to MongoDB collections with optimized performance, creating a denormalized, query-ready projection of the mainframe data. - -4. **API Exposure**: The MongoDB projection is exposed through modern REST APIs, providing millisecond response times for policy queries while maintaining data consistency with the source system. - -5. **Traffic Redirection**: Digital channels are redirected to query the high-performance projection layer, while write operations continue to flow to the mainframe as the authoritative source of truth. - -### The Outcome - -* **Drastic Performance Improvement**: The user-facing applications now query the highly performant MongoDB Projection. Page load times are reduced from seconds to milliseconds, significantly improving the customer experience. -* **Legacy System Protection**: The mainframe is completely shielded from high-volume read traffic. Its load is reduced to its core transactional function, eliminating the risk of performance degradation or outages caused by the new digital channels. -* **Developer Empowerment**: Developers can now build new features against a modern, flexible, and fast REST API. They can use the full power of MongoDB queries without worrying about impacting the legacy SoR. -* **Scalability and Elasticity**: The read layer can be scaled independently of the mainframe. If traffic to the portal increases, the company can simply add more replicas of the CRUD Service, ensuring the system remains responsive. - -By using Fast Data, the company successfully modernized its architecture, unlocking the data from its legacy system and enabling the development of fast, modern applications without a costly and risky "big bang" migration. diff --git a/versioned_docs/version-15.0.0/solutions/platform-engineering/automate-infrastructure-provisioning.md b/versioned_docs/version-15.0.0/solutions/platform-engineering/automate-infrastructure-provisioning.md deleted file mode 100644 index f79e6f51d6..0000000000 --- a/versioned_docs/version-15.0.0/solutions/platform-engineering/automate-infrastructure-provisioning.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: automate-infrastructure-provisioning -title: Automate Infrastructure Provisioning with Self-Service -sidebar_label: Automate Infrastructure Provisioning ---- - -### The Scenario - -In an organization that adopts a "you build it, you run it" approach, development teams are responsible for the entire lifecycle of their applications. However, when they need new infrastructure resources (like a database, a message queue, or a storage bucket), they must open a ticket for the Cloud Operations team. - -### The Challenge - -* **Slowness and Bottlenecks**: The ticket-based process is slow. A developer can wait for days to get a new database, effectively blocking the development of new features. -* **Resource Inconsistency**: Manual provisioning by the Ops team can lead to inconsistent configurations. A database might be created with different performance parameters than another, or without the correct backup policies. -* **Excessive Load on the Ops Team**: The Cloud Operations team is swamped with repetitive, low-value requests, diverting time and energy from more strategic activities like cost optimization and security improvement. -* **Lack of Self-Service**: Developers are not truly autonomous. Their speed is limited by the overreliance on another team, which hinders effective DevOps practices implementation. - -### The Solution with Mia-Platform - -The Platform Engineering team decides to create a self-service experience for infrastructure provisioning, using **Infrastructure Projects** and the **Software Catalog** of Mia-Platform Console. - -1. **Creation of an Infrastructure Project**: A new project of type **Infrastructure** is created. This project will not contain applications, but repositories with **Infrastructure as Code (IaC)**, in this case Terraform/OpenTofu. - -2. **Definition of Standard Infrastructure Components**: Within this project, the Ops/Platform team defines reusable and standardized Terraform modules for the most common resources: - * A module to create a **MongoDB Atlas** cluster with pre-configured backup policies. - * A module to create a **Google Cloud Storage Bucket** with versioning and lifecycle policies enabled. - * A module to create an **AWS SQS** queue with server-side encryption. - -3. **Publication in the Software Catalog**: Each Terraform module is "packaged" as an **Infrastructure Component** and published in the company's private **Software Catalog**. Each component has a clear manifest describing its purpose, the required input variables (e.g., `database_name`), and the resources that will be created. - -4. **Self-Service Experience for Developers**: Now, when a developer needs a new database: - * They access their **Application Project** on Mia-Platform Console. - * They go to the **Resources** section and select "Create from Marketplace". - * They search for and select the "MongoDB Atlas Cluster" component. - * They fill out a simple form with the required parameters (e.g., the database name and size). - * Upon saving and deploying, the Console triggers a pipeline (defined in the Infrastructure Project) that automatically and securely runs `terraform plan` and `terraform apply`. - -5. **Approval Workflow (Plan & Apply)**: The deployment is not immediate. The pipeline stops after the `plan`, showing the developer (or a designated approver) the exact impact of the changes. Only after approval does the pipeline proceed with the `apply`, creating the resources in the cloud provider. - -### The Outcome - -* **Speed and Agility**: Developers can provision the infrastructure they need in minutes, in total autonomy, eliminating waiting times. -* **Standardization and Security "by Default"**: All resources are created abiding by embedded best practices defined by the Ops team, who sets the standard. Security guardrails, backup, and monitoring are configured by default, drastically reducing the risk of manual errors. -* **Efficiency of the Ops Team**: The Cloud Operations team no longer handles manual requests but focuses on creating and maintaining IaC modules, a higher-value activity that scales for the entire organization. -* **Full Self-Service and Accountability**: Developers are truly end-to-end responsible for their applications, including the infrastructure they need. The process is fully tracked and governed. - -With Infrastructure Projects, Mia-Platform has extended the principles of the internal platform to infrastructure management, creating a self-service experience that accelerates development and improves collaboration between team Dev and Ops. diff --git a/versioned_docs/version-15.0.0/solutions/platform-engineering/gain-visibility-and-control-across-projects.md b/versioned_docs/version-15.0.0/solutions/platform-engineering/gain-visibility-and-control-across-projects.md deleted file mode 100644 index 257946f756..0000000000 --- a/versioned_docs/version-15.0.0/solutions/platform-engineering/gain-visibility-and-control-across-projects.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -id: gain-visibility-and-control-across-projects -title: Gain Visibility and Control Across Multiple Projects with a Centralized Dashboard -sidebar_label: Gain Visibility and Control Across Projects ---- - -### The Scenario - -A large enterprise with multiple business lines manages dozens of projects on Mia-Platform Console. Over time, it has become nearly impossible for the Platform Engineering team and security managers to get an overview of the state of the applications. - -### The Challenge - -* **Lack of Centralized Visibility**: There is no single point to answer critical questions like: "How many endpoints are publicly exposed without authentication?", "Which services are consuming an excessive amount of CPU?", "Are we using deprecated versions of a plugin?". -* **Difficulty in Enforcing Standards**: Although standards have been defined (e.g., all services must have resource limits configured), verifying their application across all projects is a manual, costly, and error-prone task. -* **Impossible Proactive Risk Identification**: Security or performance issues are discovered only after an incident has occurred, instead of being identified and resolved proactively. -* **Manual and Ineffective Reporting**: Preparing reports for management or audits requires manually collecting data from dozens of different projects, a slow and unreliable process. - -### The Solution with Mia-Platform - -The Platform Engineering team leverages the **Design Overview** of Mia-Platform Console, a Company-level feature that aggregates configuration data from all underlying projects into a single interface for a streamlined, automated developer experience. - -1. **Using Predefined Views**: Upon entering the Design Overview, the team uses the predefined views to get immediate insights: - * **Unprotected Endpoints**: In a few seconds, they identify all endpoints exposed without authentication or API key, creating a priority list for the security team. - * **CPU-intensive services / Memory-intensive services**: They analyze services with resource requests above a predefined threshold, identifying potential areas for cost optimization or performance issues. - * **Replicated services**: They check which services are horizontally scaled, useful for understanding the criticality and expected load for each component. - -2. **Creating Custom Public Views**: To go further, the team creates custom views to monitor compliance with specific company standards: - * **"Services without Log Parser" View**: They create a view filtering all microservices where the `logParser` field is set to `not collected`. This view becomes a fundamental tool for the observability team to ensure that all services produce analyzable logs. - * **"CRUD without Description" View**: They set up a filter on CRUDs where the `description` field is empty. This helps enforce internal documentation policies. - * **"Deprecated Plugin Usage" View**: They create a view that filters services based on a specific Docker image corresponding to a deprecated version of an internal plugin, facilitating migration planning. - -3. **Integration into the Governance Workflow**: These views are not just a visualization tool but become an integral part of the governance process. During weekly reviews, the Platform Engineering team analyzes the views to identify deviations from standards and assigns resolution tickets to the relevant development teams. - -### The Outcome - -* **360-Degree Visibility**: The Platform Engineering team now has a centralized, real-time dashboard on the health and compliance status of all projects, without having to access each one individually. -* **Simplified Enforcement of Standards**: It has become easy and immediate to verify if development teams are following the guidelines, transforming governance from a reactive to a proactive activity. -* **Rapid Risk Identification**: Security risks (open endpoints) and performance risks (oversized services) are identified in minutes, allowing for quick resolution before they become critical problems. -* **Automated and Reliable Reporting**: The views can be exported or shared, providing accurate and up-to-date data for management and audits, eliminating the need for manual collection. - -The Design Overview has transformed how the company governs its software ecosystem, providing the Platform Engineering team with the ultimate tool for visibility, control, and proactive management. diff --git a/versioned_docs/version-15.0.0/solutions/platform-engineering/implement-secure-governance.md b/versioned_docs/version-15.0.0/solutions/platform-engineering/implement-secure-governance.md deleted file mode 100644 index 52a5ab3ac4..0000000000 --- a/versioned_docs/version-15.0.0/solutions/platform-engineering/implement-secure-governance.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: implement-secure-governance -title: Implement Secure Governance with Granular Access Control -sidebar_label: Implement Secure Governance ---- - -### The Scenario - -A financial sector organization must ensure maximum security and compliance for its applications. However, to avoid slowing down release cycles, it wants to give development teams some autonomy while maintaining strict control over critical configurations. - -### The Challenge - -* **Risk of Unauthorized Changes**: Developers, by necessity or by mistake, could modify sensitive configurations in production environments, such as a service's Docker image, an endpoint's security policies, or resource limits. -* **Operational Bottleneck**: To mitigate the risk, the company has mandated that every change in production be approved and applied by the Ops team. This manual process creates queues and drastically slows down the time-to-market. -* **Lack of Guardrails**: Development teams have no clear guidelines on what they can and cannot modify, leading to trial and error and continuous approval requests. -* **Difficult Traceability**: It is difficult to know who changed what and when, making audit and incident response activities complex. - -### The Solution with Mia-Platform - -The Platform Engineering team decides to implement a "railroad framework", which features golden paths, paved roads and guardrails measures, by using the governance features of **Mia-Platform Console**. - -1. **Definition of Roles in IAM**: Using the **IAM Portal** at the Company level, clear roles such as `Developer`, `Senior Developer`, and `Platform Engineer` are defined. Each user is assigned a role based on their responsibilities. - -2. **Configuration of Granular Access Control Rules (Fine-Grained Access Control)**: The core of the solution lies in configuring specific rules that limit actions for each role. From the Company settings, the Platform Engineer sets the following `SaveChangesRules`: - * **Disallow Rule**: A rule is created that **prevents** the `Developer` role from modifying the `dockerImage` field for any microservice. This is a critical security measure to prevent unauthorized deployments in production. - * **Allow Rule**: A rule is configured that allows **only** the `Senior Developer` and `Platform Engineer` roles to modify the security settings of endpoints (such as `Authentication required` or `User Group Permission`). - -3. **Self-Service and Secure Workflow**: Developers continue to work autonomously in the **Design Area** of the Console. When a `Developer` attempts to save a configuration that includes a change to the Docker image, the Console **blocks the save** and displays an error message explaining the rule violation. The developer can then request the change from a `Senior Developer`, who can make it in compliance with the policies. - -4. **Audit Log for Traceability**: Every save attempt, whether successful or failed, and every configuration change are recorded in the **Audit Log**. This provides the security and compliance team with a complete and immutable trace of all activities, simplifying audits and post-incident analysis. - -### The Outcome - -* **Security Integrated into the Workflow**: Security is no longer an external manual process but is integrated directly into the development tools. Developers receive immediate feedback if they attempt an unauthorized action. -* **Elimination of Bottlenecks**: Development teams can deploy autonomously, knowing that automatic "guardrails" will prevent risky changes. The Ops team is freed from routine approval requests. -* **Clear and Automatic Governance**: Access policies are defined declaratively and applied automatically by the platform, ensuring compliance without sacrificing speed. -* **Complete Accountability**: Thanks to the Audit Log, every action is tracked and attributed, increasing responsibility and transparency within the organization. - -Mia-Platform has allowed the company to perfectly balance agility and control, creating a self-service development environment where security is a shared and automated responsibility. diff --git a/versioned_docs/version-15.0.0/solutions/platform-engineering/platform-engineering-overview.md b/versioned_docs/version-15.0.0/solutions/platform-engineering/platform-engineering-overview.md deleted file mode 100644 index 35dc583c14..0000000000 --- a/versioned_docs/version-15.0.0/solutions/platform-engineering/platform-engineering-overview.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: platform-engineering-overview -title: Platform Engineering Overview -sidebar_label: Platform Engineering Overview ---- - -# Platform Engineering: Build and Manage Your Internal Developer Platform - -Platform Engineering is a strategic approach aimed at improving the developer experience and productivity through the creation and management of an **Internal Developer Platform (IDP)**. An IDP is a set of standardized tools, processes, and "golden paths" that enable development teams to operate autonomously, quickly, and securely by abstracting the complexity of the underlying infrastructure. - -The goal is to treat the platform as an internal product, with developers as its customers, to accelerate the delivery of high-quality software. - -## The Challenges of Modern Development - -In today's cloud-native landscape, development teams face increasing complexity that can slow innovation and increase operational risk: - -* **High Cognitive Load**: Developers need to be familiar with a wide range of technologies (Kubernetes, Docker, CI/CD, monitoring), diverting their focus from business logic. -* **Lack of Standardization**: Without defined paths, each team adopts different tools and configurations, leading to a fragmented architecture that is difficult to maintain and govern. -* **Slow Onboarding Processes**: New developers take weeks to become productive as they navigate scattered documentation and complex setups. -* **Governance and Security Risks**: The lack of centralized control exposes the company to risks, with insecure configurations or unregulated access that can compromise the entire infrastructure. -* **Operational Bottlenecks**: Development teams depend on operations (Ops) teams for provisioning resources like databases or test environments, creating long waits. - -## The Mia-Platform Solution: Your Platform as a Product - -**Mia-Platform** is the AI-Native Developer Platform Foundation that enables Platform Engineering teams to build and manage a robust, secure, and customized IDP. The Console transforms the infrastructure from a complex set of tools into a coherent, self-service product to manage the entire software lifecycle. - -### Centralize and Standardize with the Software Catalog - -The **Software Catalog** is the heart of standardization. Platform teams can create and distribute reusable resources such as **Templates**, **Plugins**, and **Infrastructure Components**. This ensures that every new microservice or resource starts from a solid, approved foundation, following opinionated "golden paths." -* **Microservice Standardization**: Create templates with pre-configured logging, health checks, and CI/CD pipelines, ensuring consistency and quality. -* **Code Reuse**: Offer ready-to-use plugins (e.g., CRUD Service, Authorization Service) to accelerate development and reduce duplication. - -### Abstract Complexity with the Console - -Mia-Platform Console provides an intuitive interface that abstracts the complexity of Kubernetes. Developers interact with high-level concepts like **Microservices**, **Endpoints**, and **CRUDs**, without needing to write complex YAML manifests. -* **No-Code/Low-Code Configuration**: Define resources, environment variables, ports, and probes through a graphical interface, reducing errors and cognitive load. -* **Integrated Management**: From design to deployment, through debugging and monitoring, the entire software lifecycle is managed in a single environment. - -### Enable Self-Service for Developers - -With an IDP based on Mia-Platform, developers become autonomous. They can create new environments, deploy their services, and access logs and metrics independently, without relying on other teams. -* **On-Demand Environments**: Create development and test environments in minutes. -* **Simplified Deployment**: Release new versions of applications securely and controlled, with both **push-based (pipeline)** and **pull-based (GitOps)** strategies. - -### Apply Centralized Governance and Security - -The Console offers powerful tools for platform teams to govern access and resource usage. -* **Identity and Access Management (IAM)**: Define roles and groups with specific permissions for Companies, Projects, and Environments. -* **Fine-Grained Access Control**: Set granular rules to prevent changes to critical configurations (e.g., the Docker image in production) by unauthorized roles. -* **Audit Log**: Track every action performed on the platform to ensure accountability and compliance. -* **Security Policies with Rönd**: Integrate authorization policies directly at the microservice level, ensuring security is an intrinsic requirement, not an afterthought. - -### Gain Unprecedented Visibility - -The **Design Overview** at the Company level provides an aggregated view of all resources distributed across various projects. This allows platform teams to: -* Quickly identify unprotected endpoints. -* Monitor services with anomalous resource consumption (CPU/memory). -* Verify the consistency of configurations and compliance with corporate standards. - -By using Mia-Platform Console, Platform Engineering teams can finally build an internal platform that not only solves operational challenges but also becomes a true accelerator and value generator for the entire organization. - - diff --git a/versioned_docs/version-15.0.0/solutions/platform-engineering/standardize-microservices-development.md b/versioned_docs/version-15.0.0/solutions/platform-engineering/standardize-microservices-development.md deleted file mode 100644 index 90658df9fb..0000000000 --- a/versioned_docs/version-15.0.0/solutions/platform-engineering/standardize-microservices-development.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: standardize-microservices-development -title: Standardize Microservice Development with Custom Templates -sidebar_label: Standardize Microservice Development ---- - -### The Scenario - -A rapidly growing company is managing dozens of development teams working on different projects. Each team creates microservices independently, leading to a proliferation of heterogeneous configurations. - -### The Challenge - -* **Inconsistency**: Microservices have different structures, non-uniform logging and monitoring implementations, and CI/CD pipelines written from scratch for each project. -* **Slow Onboarding**: New developers take weeks to understand their team's specific configurations and become productive. -* **Complex Maintenance**: The lack of standards makes maintaining and updating services difficult, increasing the risk of errors in production. -* **Variable Code Quality**: There is no "golden path" for development, so the quality and security of services depend entirely on the skills of the individual team. - -### The Solution with Mia-Platform - -The Platform Engineering team decides to use **Mia-Platform Console** and the **Software Catalog** to create and distribute reusable development standards for the entire company. - -1. **Creation of a Project Blueprint**: First, the team defines a **Project Blueprint** at the Company level. This Blueprint includes pre-configured environments (e.g., Development, Production), default Git and CI/CD providers, ensuring that every new project starts from a common, approved base. - -2. **Development of a Custom Microservice Template**: Next, the team creates a **Template** for a Node.js microservice. This template is not just a "hello world," but a true application skeleton that includes: - * Standardized logging libraries (`lc39`). - * Health check endpoints (`/-/healthz`, `/-/readyz`) already implemented. - * A standard `.gitlab-ci.yml` pipeline that includes steps for linting, unit tests, and security scans. - * A basic configuration for resources (CPU and memory) and Kubernetes probes. - -3. **Publication in the Software Catalog**: The template is published in the company's private **Software Catalog**. It is clearly documented, specifying its purpose and how to use it. It is assigned the "Backend Templates" category for easy searching. - -4. **Self-Service for Developers**: Now, when a development team needs to create a new microservice, they no longer start from scratch. They access the **Microservices** section in Mia-Platform Console, select "Create from Marketplace," and find the "Node.js Standard Service" template approved by the platform team. With a few clicks, the Console: - * Creates a new Git repository by cloning the template. - * Creates the new microservice in the project with all standard configurations already applied. - -### The Outcome - -* **Consistency and Standardization**: All new Node.js microservices follow the same best practices, simplifying management and maintenance. -* **Increased Development Speed**: Teams can create and deploy a new production-ready service in minutes instead of days. -* **Accelerated Onboarding**: New developers are immediately productive, as the service structure and pipelines are already defined and familiar. -* **Quality and Security "by design"**: Security and quality practices are integrated directly into the template, reducing the risk of errors and vulnerabilities. - -Thanks to Mia-Platform, the Platform Engineering team has transformed chaos into an industrial process, providing developers with golden paths and guardrails that makes them faster, more autonomous and more secure. diff --git a/versioned_sidebars/version-15.0.0-sidebars.json b/versioned_sidebars/version-15.0.0-sidebars.json index ecfeac928f..95f01673bd 100644 --- a/versioned_sidebars/version-15.0.0-sidebars.json +++ b/versioned_sidebars/version-15.0.0-sidebars.json @@ -67,21 +67,6 @@ } ] }, - { - "collapsed": true, - "type": "category", - "label": "Infrastructure Project", - "items": [ - { - "id": "products/console/tutorials/infrastructure-project/create-project-configuration", - "type": "doc" - }, - { - "id": "products/console/tutorials/infrastructure-project/visualize-infrastructure-project-components-runtime-data-in-console", - "type": "doc" - } - ] - }, { "id": "products/console/tutorials/configure-new-company", "type": "doc" @@ -356,10 +341,6 @@ "id": "products/console/project-configuration/application-project", "type": "doc" }, - { - "id": "products/console/project-configuration/infrastructure-project", - "type": "doc" - }, { "id": "products/console/project-configuration/create-a-project", "type": "doc"