<h3>The Future of Platform Engineering: AI Agents and the Rise of the Intelligent Internal Developer Portal</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*xNsVrpGcQSpQBAjIlWYBaA.png"></figure>Internal Developer Portals (IDPs) have transformed how teams scale software delivery. They standardize infrastructure, simplify workflows, and help developers move faster. But even the most advanced portals today are still passive. Developers are expected to figure out what to run, how to run it, and when to do it. That’s about to change thanks to AI agents.
<h4>From Self-Service to Self-Driving</h4>
I genuinely believe that AI agents are about to redefine what we expect from an internal developer portal. The IDPs we use today are designed for self-service. Developers click through menus, select templates, and fill out forms. But with the help of AI, we can shift from self-service to something much more powerful: self-driving.
Picture a developer saying, “I need a new service.” Instantly, the agent scaffolds the code, provisions infrastructure, applies policies, sets up the Git repo, and integrates observability all in one automated flow. No guesswork. No context switching.
This isn’t just a better UI. It’s a fundamental shift in how developers interact with infrastructure.
<h4>Discoverability, Supercharged</h4>
One of the most frustrating challenges in large organizations is that developers don’t know what already exists. What tools are available? What services have been built? Which templates apply to their use case?
AI agents can surface the right choices by analyzing signals like past usage, team preferences, or project context. Instead of searching, developers are shown what they need often before they ask.
<h4>Documentation That Talks Back</h4>
Let’s talk about documentation, the silent struggle of every engineering team. Traditional documentation is often outdated, hard to navigate, or irrelevant to the problem at hand. With AI, that flips too.
Now, a developer can ask, “What happens if I change this config?” and get an accurate, contextual answer drawn from code, policies, and historical context.
Docs become conversations. The knowledge gap shrinks.
<h4>An Intelligent Platform Teammate</h4>
Modern AI agents do more than automate tasks. They learn how your platform operates. They adapt based on usage. Some teams are already experimenting with multiple agents one handling provisioning, another scanning for security issues, and another watching for cost optimizations.
These agents aren’t just tools. They’re collaborators.
<h4>The Future Starts Now</h4>
This isn’t a futuristic vision. It’s already happening. Organizations are embedding AI into their IDPs, using it to scaffold services, generate documentation, and guide developers through infrastructure decisions. With the right platform foundations in place, AI becomes the layer that makes everything faster, simpler, and more intuitive. We’re moving toward a world where the question isn’t “Do you have an IDP?” but “How intelligent is your platform?”
<h3>Final Thought</h3>
AI won’t replace platform engineers, it will amplify them. It will give smaller teams the power to support larger orgs, help developers focus on what matters, and reduce the time spent navigating complexity.
If you’re building a platform today, don’t just think about self-service. Think about intelligence. Think about how your portal can stop being a passive interface and start acting like a teammate.
That’s the future of platform engineering. And it’s closer than we think.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=42561df2d771" width="1" height="1" alt="">

The Future of Platform Engineering: AI Agents and the Rise of the Intelligent Internal Developer…

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*o5T7wHfiQq9-sk_z"></figure>Imagine this, you are deploying microservices, configuring CI/CD pipelines, and managing multiple cloud services. But then someone realizes the database credentials are hardcoded in a Kubernetes Secret or worse, an API key was leaked in a public repo.
Secrets are critical, but managing them properly is a headache. Kubernetes already has a built-in Secret resource, but it doesn’t encrypt secrets at rest by default and lacks versioning, rotation, and fine-grained access controls.
That’s where solutions like AWS ASCP and External Secrets Operator (ESO) come in. Instead of storing secrets directly in Kubernetes, ESO fetches them from an external secret manager like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. This means:
<ul>
<li>
Centralized security — Manage secrets in a dedicated vault, not in scattered YAML files.</li>
<li>
Automated sync — Kubernetes retrieves secrets automatically, reducing manual updates.</li>
<li>
No plaintext secrets in repos — Secrets are pulled securely at runtime.</li>
</ul>
<h3>Why Native Kubernetes Secrets Aren’t Enough</h3>
Kubernetes provides a Secret resource, but it has major security limitations:
<ul>
<li>
Base64 ≠ Encryption — Kubernetes Secrets are just base64-encoded, not encrypted at rest by default.</li>
<li>
No built-in rotation — If an API key changes, you have to manually update and redeploy it.</li>
<li>
Secrets sprawl — Storing secrets across multiple clusters leads to security risks.</li>
<li>
Limited access control — Kubernetes RBAC is powerful, but it doesn’t integrate directly with cloud IAM policies.</li>
</ul>
Why Solutions Like AWS ASCP and ESO Are Better
These tools solve the above problems by syncing secrets from external vaults into Kubernetes dynamically. Instead of storing secrets in YAML files or environment variables, they ensure secrets are always pulled from a secure, external source.
<h3>How External Secrets Operator Works</h3>
<h3>Key Components of ESO</h3>
ESO introduces new Kubernetes resources that integrate with external secret managers:
<ol><li>ExternalSecret</li></ol>
<ul>
<li>Defines which secret to fetch from an external system (e.g., AWS Secrets Manager).</li>
<li>Maps external secrets to a Kubernetes Secret.</li>
</ul>
2. SecretStore / ClusterSecretStore
<ul>
<li>Defines where to fetch secrets from (AWS, Vault, Azure, etc.).</li>
<li>SecretStore is namespaced, while ClusterSecretStore is cluster-wide.</li>
</ul>
3. ESO Controller
<ul><li>Watches for ExternalSecret resources and syncs secrets into Kubernetes.</li></ul>
<h3>Implementing External Secrets Operator in Your Platform</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*09lcddyb7aHEbCXW.png"></figure><h3>Step 1: Install External Secrets Operator</h3>
ESO can be installed via Helm:
<pre>helm repo add external-secrets &lt;https://charts.external-secrets.io&gt; helm install external-secrets external-secrets/external-secrets</pre>
<h3>Step 2: Create Service account with IRSA</h3>
<pre>apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/eso-role name: eso-service-account</pre>
<h3>Step 3: Configure a Secret Store</h3>
Define a SecretStore to connect Kubernetes to AWS Secrets Manager (example for AWS):
<pre>apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: aws-secrets spec: provider: aws: service: SecretsManager region: eu-west-1 auth: jwt: serviceAccountRef: name: eso-service-account</pre>
<h3>Step 4: Define an ExternalSecret</h3>
Now, create an ExternalSecret that syncs a secret from AWS Secrets Manager:
<pre>apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: my-app-secret namespace: default spec: refreshInterval: 1h secretStoreRef: name: aws-secrets kind: ClusterSecretStore target: name: my-app-secret creationPolicy: Owner data: - secretKey: DATABASE_PASSWORD remoteRef: key: my-app/db-password</pre>
<h3>Step 5: Inject Secrets into Your Pods</h3>
Modify your deployment to use the Secret:
<pre>apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: template: spec: containers: - name: my-container env: - name: DATABASE_PASSWORD valueFrom: secretKeyRef: name: my-app-secret key: DATABASE_PASSWORD</pre>
Now, your application automatically pulls the latest secrets without storing them in code.
<h3>Benefits of Using External Secrets Operator</h3>
<ul>
<li>
No More Hardcoded Secrets — Secrets are never stored in Git, config files, or environment variables.</li>
<li>
Automatic Secret Rotation — If a secret changes in AWS, Kubernetes updates it automatically.</li>
<li>
Unified Secrets Management — Use a single source of truth across multiple clusters.</li>
<li>
Strong Access Control — Leverage cloud IAM policies instead of relying solely on Kubernetes RBAC.</li>
<li>
Multi-Cloud Support — Works with AWS, Vault, Azure, Google Secret Manager, and more.</li>
</ul>
<h3>Stop Treating Secrets as an Afterthought</h3>
Managing secrets is one of the most critical and often most neglected parts of platform engineering.
Tools like AWS ASCP and External Secrets Operator offer a clean, scalable solution by bridging the gap between secure external secret stores and Kubernetes-native workflows. They help teams enforce best practices without slowing down development and reduce the cognitive and operational overhead that comes with managing secret lifecycles.
Whether you’re running a small cluster or managing a multi-cloud platform, building a modern secrets management strategy is no longer optional it’s foundational to the security and reliability of your platform.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=687b7f2c6bed" width="1" height="1" alt="">

Secrets Are Everywhere And They’re a Mess

<figure><img alt="" src="https://cdn-images-1.medium.com/max/839/1*9VoMor8YtaG9cTrpau088g.png"></figure>GitOps has revolutionized infrastructure and application deployment, especially within Kubernetes environments. By treating Git as the single source of truth, organizations can achieve automated, version controlled, and repeatable deployments. However, while GitOps thrives in small setups such as single cluster environments or within a single development team, scaling GitOps introduces significant technical and operational challenges.
In this article we will explores these challenges and provides solutions for scaling GitOps successfully.
<h3>Why Scaling GitOps is Challenging</h3>
<h4>Complexity in Multi-Cluster, Multi-Region, and Multi-Team Environments</h4>
As organizations expand, managing infrastructure across multiple clusters and regions becomes exponentially more complex. Some key challenges include:
<ul>
<li>Ensuring consistent deployments across different environments.</li>
<li>Synchronizing configurations and avoiding drift.</li>
<li>Coordinating between multiple teams, leading to potential merge conflicts and broken dependencies.</li>
</ul>
One possible solution is adopting GitOps-driven multi-cluster management using tools like ArgoCD’s ApplicationSets that can assist managing configurations centrally while deploying specific changes based on cluster labels.
<h4>Security, Access Control, and Secret Management</h4>
Security becomes a monumental task in large organizations:
<ul>
<li>Who can approve changes?</li>
<li>Who has write access to repositories?</li>
<li>How are secrets managed securely?</li>
</ul>
Scaling GitOps requires robust Role-Based Access Control (RBAC), granular permissions, and advanced secret management solutions such as HashiCorp Vault or AWS Secrets Manager. Without these, organizations risk unauthorized changes, security breaches, and compliance violations.
Additionally, adopting GitOps-friendly security tools like External Secrets Operator ensures sensitive data remains encrypted in Git while being decrypted securely in Kubernetes clusters.
<h4>Operational Overhead</h4>
At scale, the operational burden of maintaining Git repositories increases. Common issues include:
<ul>
<li>
Handling sync failures due to API limits or misconfigurations.</li>
<li>
Performance bottlenecks in Git repositories containing thousands of configuration files.</li>
<li>
Troubleshooting reconciliation failures without proper monitoring and alerting.</li>
</ul>
For instance, an enterprise using ArgoCD across 200+ clusters may need to optimize its sync intervals and sharding strategies to prevent Git and API overloads. Implementing progressive synchronization, where updates are rolled out incrementally rather than all at once, can help mitigate these issues.
<h3>Essential GitOps Principles at Scale</h3>
<h4>Separation of Concerns</h4>
To prevent chaos, organizations must structure repositories effectively:
<ul>
<li>
Monorepo: Centralizes all configurations in a single repository, ensuring visibility and policy enforcement. However, it can lead to scalability challenges as the number of services grows.</li>
<li>
Multi-Repo: Each team or service maintains its own repository, offering autonomy but requiring strict governance.</li>
<li>
Hybrid Approach: Global configurations (e.g., security policies) reside in a monorepo, while service-specific configurations remain in dedicated repos.</li>
</ul>
Using namespace-based repository structures, where each team operates within predefined scopes, can also help ensure scalability without introducing unnecessary complexity.
<h4>RBAC and Policy Enforcement</h4>
Integrating policy-as-code tools like Open Policy Agent (OPA) or Kyverno allows organizations to:
<ul>
<li>Enforce Kubernetes security policies programmatically.</li>
<li>Automate approval workflows to ensure compliance.</li>
<li>Minimize human error in configuration changes.</li>
</ul>
For large-scale deployments, organizations should also adopt GitOps-friendly authorization frameworks such as Gatekeeper, which allows OPA policies to be enforced at the admission control level in Kubernetes.
<h4>Drift Detection &amp; Reconciliation Loops</h4>
At scale, drift detection is crucial. Tools like ArgoCD and FluxCD continuously monitor for discrepancies and reconcile changes in real time. Enhancing this with Prometheus-based monitoring and Grafana dashboards ensures immediate visibility when things go wrong.
Additionally, event-driven reconciliation (e.g., leveraging Kubernetes Admission Controllers) can trigger immediate rollbacks if an unauthorized configuration change is detected.
<h3>Choosing the Right GitOps Tools for Scale</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/707/1*ydY7-t5rdxSDUqVNDshjCw.png"></figure>For large deployments, ArgoCD scales better due to its built-in sharding support and UI, while FluxCD excels in event-driven deployments requiring simplicity.
<h4>Karpenter for Autoscaling</h4>
Scaling isn’t just about adding nodes, it’s about adding the right nodes. Karpenter dynamically provisions nodes based on actual usage, reducing costs and improving workload performance, particularly in heterogeneous environments.
<h4>Progressive Delivery Strategies</h4>
<ul>
<li>
Canary Deployments: Slowly introduce changes to a small subset of users, expanding rollout if no issues arise.</li>
<li>
Blue-Green Deployments: Maintain two environments and switch traffic between them for seamless updates.</li>
<li>
Feature Flags: Enable/disable features dynamically without redeploying applications.</li>
</ul>
<h3>Scaling GitOps Across Teams</h3>
<h4>The Role of Platform Engineering</h4>
Platform teams act as the backbone of scalable GitOps by defining standards, automating processes, and enforcing governance. Their responsibilities include:
<ul>
<li>Developing Infrastructure-as-Code (IaC) templates with Helm, Kustomize, or Jsonnet.
</li>
<li>Establishing guardrails for security and compliance.</li>
<li>Providing self-service capabilities through Internal Developer Portals.</li>
</ul>
<h4>Reusable Templates &amp; Automation</h4>
Using templating tools, teams can standardize configurations while allowing flexibility:
<ul>
<li>
Helm Charts for reusable Kubernetes manifests.</li>
<li>
Kustomize for overlay-based modifications.</li>
<li>
Jsonnet for complex templating needs.</li>
</ul>
<h3>The Future of GitOps at Scale</h3>
<h4>AI-Driven GitOps Workflows</h4>
<ul>
<li>
Self-Healing Deployments: AI detects failed rollouts or misconfigurations and automatically reverts to a stable state, minimizing human intervention. AI-enhanced Kubernetes operators can prevent outages before they happen.</li>
<li>
Smarter Resource Optimization: AI models adjust resources on the fly to balance cost and availability. Tools like Karpenter can be paired with AI to predict demand and auto-scale ahead of time.</li>
<li>
Faster Root Cause Analysis: AI observability platforms (e.g., New Relic, Datadog) diagnose failures and suggest fixes, reducing MTTR by analyzing logs and telemetry data.</li>
<li>
Security Anomaly Detection: AI identifies suspicious Git activity, unauthorized changes, or risky misconfigurations, suggesting immediate corrective actions to avoid breaches.</li>
<li>
Predictive Drift Detection: Machine learning flags drift conditions before they lead to failures, similar to how Netflix leverages AI to proactively adjust Kubernetes configurations.</li>
<li>
AI-Optimized Rollouts: AI recommends safe deployment strategies (e.g., canary, blue-green) based on past incidents and usage patterns, reducing the risk of downtime. Google’s Borg and Facebook’s continuous deployment pipelines have integrated AI-driven decision-making to enhance rollout safety and efficiency.</li>
</ul>
<h3>GitOps Beyond Kubernetes</h3>
While GitOps is often associated with Kubernetes, the principles can be extended to other domains, including serverless deployments, database schema migrations, and CI/CD pipelines for non-containerized applications.
Scaling GitOps is both a technical and cultural transformation. Organizations that embrace automation, strong governance, and scalable architectures will be better positioned to deliver high-quality, reliable software at scale.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=b97af6c75a9e" width="1" height="1" alt="">

GitOps at scale: Lessons from the trenches of platform engineering

In the evolving landscape of software development, speed, scalability, and efficiency are non-negotiable. Platform engineering has emerged as a strategic discipline aimed at optimizing developer productivity by providing tools, automation, and best practices to streamline software delivery. One of the transformative aspects of modern platform engineering is the advent of self-service environments.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/585/1*w6jpaM-2aAJydOmz0GNEdw@2x.jpeg"></figure>Self-service environments empower developers to provision resources, manage configurations, and deploy applications autonomously without relying on centralized operations teams. This article explores the concept of self-service environments, their critical role in platform engineering, and showcases how tools like kro can help platform teams create and manage these environments effectively.
<h4>The Connection Between Platform Engineering and Self-Service Environments</h4>
At its core, platform engineering is about building internal platforms that provide reusable components, workflows, and best practices for developers. The primary goal is to reduce cognitive load on developers and enable them to focus on writing code rather than managing infrastructure or worrying about deployment complexities.
Self-service environments are a natural outcome of effective platform engineering. They embody the principles of developer empowerment by providing:
<ul>
<li>
Autonomy: Developers can access the resources they need without waiting for manual approvals.</li>
<li>
Consistency: Pre-configured templates and automation enforce organizational standards and best practices.</li>
<li>
Speed: On-demand access to environments accelerates development and testing cycles.</li>
<li>
Reduced Cognitive Load: Abstracts complex infrastructure configurations, allowing developers to focus on feature development instead of underlying systems.</li>
</ul>
When done right, self-service models don’t just reduce bottlenecks, they unlock creativity, accelerate delivery, and give your organization the agility it needs to stay ahead in a competitive landscape.
<h4>Simplifying Self-Service Environment Management with kro</h4>
Imagine if, with a single, easy-to-understand file, development teams could create a complete environment to experiment in without needing to grasp the complexities of Kubernetes. That’s exactly what kro brings to the table.
kro (Kube Resource Orchestrator) is an open-source, Kubernetes-native framework developed by Amazon Web Services (AWS). It simplifies the management of complex Kubernetes resource configurations, enabling platform teams to build scalable, reusable systems that empower developers to deploy applications autonomously.
<h4>How kro Currently Helps Platform Teams</h4>
<ul>
<li>
Reusable Resource Definitions: kro allows platform engineers to define reusable, declarative configurations, enabling developers to deploy resources consistently across environments.</li>
<li>
Simplified Resource Management: By abstracting complex Kubernetes configurations, kro reduces the operational overhead for developers, allowing them to focus on building and deploying applications.</li>
<li>
Cross-Team Collaboration: Platform, compliance, and security teams can collaborate to develop standardized APIs, ensuring secure, compliant configurations while streamlining adoption by developer teams.</li>
</ul>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*iBdKBs3qRwx-wszMBG5wgQ@2x.jpeg"></figure>Quick Note: While kro is still in its early stages and isn’t production-ready yet, it’s clear that this tool has the potential to revolutionize platform engineering by simplifying environment management and standardizing deployment practices. For organizations scaling rapidly, adopting solutions like kro early can be a significant competitive advantage.
<h4>The Future of Self-Service Environment Management</h4>
As software systems grow more complex and organizations scale, the need for efficient, developer-friendly environments will continue to rise. The future of platform engineering will revolve around creating ecosystems where developers have greater autonomy while maintaining strong governance and security standards.
Emerging tools like kro and more signal a broader shift toward more flexible and scalable solutions that abstract away infrastructure complexities. By enabling developers to focus on innovation rather than configuration, platform engineering teams can foster a culture of experimentation, rapid iteration, and continuous improvement.
Looking ahead, organizations that invest in robust self-service platforms will not only improve operational efficiency but also gain a competitive edge by accelerating their ability to deliver value to customers. As the field matures, the emphasis will move toward refining these systems for greater automation, improved observability, and seamless scalability.
<h4>Points to remember</h4>
As platform engineering continues to evolve, investing in self-service environments is becoming less of an option and more of a necessity for organizations that want to stay competitive. Tools like kro are at the forefront of this transformation, helping platform teams build scalable, efficient, and secure systems that empower developers to take control of their workflows.
If you’re considering ways to enhance your platform engineering strategy, now is an ideal time to explore how self service environments can support your organization’s future growth. Whether your goal is to boost productivity, streamline operations, or stay ahead of industry trends, investing in these solutions offers long-term benefits that are too significant to overlook.
The future of development lies in autonomy, efficiency, and innovation taking small steps today could set the foundation for major breakthroughs tomorrow.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=be7076064b4a" width="1" height="1" alt="">

Empowering Developers: Self-Service Environment Management in Platform Engineering

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*wDnpjdwYXOFu4vaL.jpeg"></figure>Developer experience (DX) has become a competitive advantage in modern software delivery and a core pillar of Platform Engineering. Companies that prioritize DX move faster, innovate more, and retain top engineering talent.
But achieving a developer-first culture isn’t just about adopting fancy tools or automating workflows, it requires a fundamental shift in how platform teams support developers.
Many organizations I’ve spoken with struggle to balance developer autonomy and operational efficiency. Without the right foundations, a self-service platform can spiral into uncontrolled shadow IT, where developers adopt unapproved tools, bypass security policies, or create unmanaged infrastructure.
The key to preventing the mentioned above is to build a developer-first culture, where platform engineering acts as an enabler, not a bottleneck.
<h4>What is a Developer-First Culture?</h4>
A developer-first culture prioritizes developer experience by removing friction from software delivery. It enables engineers to focus on building products instead of struggling with the cognitive load of managing complex infrastructure, slow CI/CD pipelines, or bureaucratic processes
<h4>How Developer-First Differs from Traditional Ops-First Cultures:</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*yDZogLNRgxWeDHLZ79X0ag.png"></figure>The key challenge is balancing developer autonomy with platform governance. Developers should have the freedom to deploy services without unnecessary friction, but within sensible guardrails that maintain security, compliance, and reliability.
<h4>Why Developer Experience (DX) Matters</h4>
Developer experience isn’t just about the happiness of developers; it’s directly linked to business outcomes:
<ul>
<li>
Faster Time to Market — Efficient DX enables teams to ship features faster.</li>
<li>
Reduced Cognitive Load — Developers can focus on solving business problems, not infrastructure hurdles.</li>
<li>
Higher Developer Retention — A great developer experience reduces burnout and improves morale.</li>
<li>
Standardization Across Teams — DX helps create a consistent approach to code quality, testing, deployment, and shared libraries (e.g., logging, monitoring, security best practices), reducing fragmentation and improving maintainability.</li>
</ul>
<h4>The Hidden Cost of a Bad Developer Experience</h4>
A poor DX slows down innovation and increases operational burden and technical debt. Common DX pitfalls include:
<ul>
<li>
Long CI/CD pipelines — Slow build and deploy cycles waste developer time.</li>
<li>
Overly restrictive security policies — Developers bypass them, leading to security risks.</li>
<li>
Unclear ownership and on-call rotations — When there is no clear ownership of services, developers often feel overwhelmed. They may not know who is responsible for fixing issues, leading to confusion during incidents.</li>
</ul>
<h4>Key Pillars of a Developer-First Culture</h4>
1. Self-Service Infrastructure Developers shouldn’t have to file tickets for every infrastructure request. A self-service platform enables developers to deploy, scale, and manage resources without waiting on Ops teams.
2. Frictionless CI/CD Pipelines Deployments should be boring and predictable. GitOps, progressive delivery, and automated rollback mechanisms can help.
<ul>
<li>GitOps for infrastructure management (ArgoCD, FluxCD)</li>
<li>Feature flags for controlled rollouts (LaunchDarkly, Unleash)</li>
<li>Observability in CI/CD pipelines.</li>
</ul>
3. Observability &amp; Ownership Developers should have real-time insights into their services without relying on Ops.
<ul>
<li>Centralized logs, metrics, and tracing (OpenTelemetry, Grafana, Prometheus, Datadog)</li>
<li>You Build It, You Run It mindset (with safety nets)</li>
<li>Automated post-mortems and incident retrospectives</li>
</ul>
4. Measuring Developer Productivity (Without Micromanagement) Avoid vanity metrics like lines of code or commit counts. Instead, focus on meaningful DX metrics:
<ul>
<li>
Lead Time for Changes — How fast can a code change reach production?</li>
<li>
Deployment Frequency — How often are teams deploying?</li>
<li>
Mean Time to Recovery (MTTR) — How quickly can teams resolve issues?</li>
</ul>
5. Psychological Safety &amp; Continuous Improvement Developers should feel safe to experiment, fail, and improve.
<ul>
<li>
Blameless post-mortems ensure learning from failures.</li>
<li>
Platform teams act as enablers, not gatekeepers.</li>
<li>
Regular DX feedback loops — Developer surveys, feedback sessions.</li>
</ul>
<h4>How to Get Started: Building a Developer-First Culture</h4>
Step 1: Conduct a developer experience survey to identify friction points.
Step 2: Implement self-service infrastructure (e.g., Backstage for service discovery).
Step 3: Optimize CI/CD pipelines for speed and reliability.
Step 4: Introduce observability and developer-friendly monitoring tools.
Step 5: Foster a culture of continuous feedback and psychological safety.
<h4>The Role of Platform Engineering in Developer-First Cultures</h4>
Platform teams should abstract complexity without adding bureaucracy.
<ul>
<li>Build paved roads to provide golden paths for development.</li>
<li>Act as internal product teams, treating developers as customers.</li>
<li>Standardize environments while allowing flexibility.</li>
</ul>
<h4>Conclusion</h4>
Building a developer-first culture isn’t just about adopting new tools it requires a mindset shift where developers are empowered to own their services while platform teams provide support and guardrails. By investing in DX, companies can accelerate innovation, reduce operational burden, and build happier, more productive engineering teams.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=2518d68c4c5a" width="1" height="1" alt="">

How to Make Your Platform Developer-First

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*1J2Ta28__2zE-tpAfYx3vg.jpeg"></figure>Part 2 of the “How to Build a Platform Without Pulling Your Hair” series
In today’s fast paced software development environment, efficiency is no longer a luxury, it’s a necessity. Developers face increasing pressure to move quickly, yet they often find themselves bogged down by fragmented documentation, disjointed tool integrations, and slow infrastructure provisioning. These challenges can hinder progress, but there’s a solution: Internal Developer Portals (IDPs). By centralizing and streamlining developer workflows, IDPs empower teams to focus on what matters most delivering software.
However, not all IDPs are created equal. Choosing the right one for your organization requires thoughtful consideration of various factors. From integration capabilities to scalability and user experience, the IDP you select will shape how your team works. In this article, we’ll dive into the power of IDPs, provide criteria to help you choose the best one for your needs, and explore three leading platforms that could transform your development workflows.
<h3>What Is an Internal Developer Portal?</h3>
An Internal Developer Portal (IDP) is a centralized hub that connects all the tools, systems, and processes developers rely on to deliver software efficiently. Think of it as the “command center” for development — integrating infrastructure, code repositories, CI/CD pipelines, documentation, and monitoring tools into a unified platform. By centralizing these resources, IDPs eliminate the need to jump between disconnected systems, allowing developers to focus on building and deploying software rather than navigating complex workflows.
The core philosophy behind IDPs is empowerment. By enabling self-service capabilities, IDPs allow developers to provision environments, deploy applications, and access logs on their own without relying on platform or operations teams. This autonomy accelerates delivery, reduces bottlenecks, and fosters a culture of ownership and accountability.
Unlike more narrowly focused tools like Kubernetes dashboards or CI/CD systems, IDPs offer a broader, end to end solution. They consolidate disparate tools and processes, while also providing governance, visibility, and customization based on user roles. In essence, an IDP isn’t just a tool, it’s a comprehensive platform that aligns with the needs of both developers and platform teams, driving efficiency and enhancing the overall developer experience.
<h3>Criteria for Choosing the Right Internal Developer Portal</h3>
Selecting the right IDP for your organization is crucial. A poor choice can hinder adoption, disrupt workflows, and limit the impact of your development efforts. To ensure success, consider the following criteria when evaluating potential IDPs:
<h4>Developer Experience</h4>
First and foremost, the portal must be user-friendly. Developers should be able to navigate it easily and complete tasks without frustration. A poorly designed user interface can lead to low adoption rates and decreased productivity. Prioritize platforms that allow for custom workflows and personalized interfaces, so developers can spend less time searching for resources and more time focusing on their work.
<h4>Integrations</h4>
Seamless integration with your existing toolset is essential for a smooth workflow. The IDP should complement, rather than complicate, your current systems. Check whether it integrates with popular tools like GitHub, Jenkins, Kubernetes, and cloud platforms, and whether it supports custom integrations for any unique requirements.
<h4>Customization and Extensibility</h4>
Every organization has unique workflows and needs, so your IDP should be flexible enough to adapt to these. Look for a platform that allows for the creation of custom plugins, templates, and features. A customizable IDP ensures that the platform grows with your team and accommodates your evolving needs.
<h4>Scalability</h4>
As your organization grows, your IDP must scale with it. Whether your team expands or your infrastructure becomes more complex, the platform should be able to maintain performance and usability. Assess how well the IDP can handle increased user demand, additional microservices, and new integrations as your company scales.
<h4>Security &amp; Compliance</h4>
Security is a top priority. Your IDP should have built-in features to enforce security policies, manage access control, and maintain compliance with industry standards like GDPR or SOC 2. A secure IDP minimizes the risk of costly mistakes and provides peace of mind for developers and platform teams alike.
<h4>Community &amp; Support</h4>
Whether open-source or commercially supported, a strong community and reliable customer support are vital. An active open-source community drives continuous innovation, while vendor support ensures timely issue resolution. Look for platforms with comprehensive documentation, active forums, and responsive customer service to maximize the value of your IDP.
<h3>Examples of Internal Developer Portals</h3>
Understanding the strengths and limitations of available IDP options is key to making an informed decision. Below, we explore three popular platforms — Backstage, Harness, and Port — that are widely recognized for their capabilities in streamlining developer workflows.
<h4>Backstage</h4>
Backstage, an open-source IDP framework created by Spotify, allows organizations to build highly customized portals. It centralizes tools, services, and documentation, offering flexibility and scalability through its vibrant plugin ecosystem and open-source community.
Pros:
<ul>
<li>
Highly Customizable: Backstage allows you to build a portal tailored to your unique workflows using plugins, APIs, and open-source extensibility.</li>
<li>
Active Open-Source Community: With contributions from developers worldwide, Backstage’s ecosystem is constantly improving, offering new features and plugins.</li>
<li>
Extensibility: Integrates seamlessly with popular tools like Kubernetes, Jenkins, and GitHub.</li>
<li>
Scalability: Ideal for organizations with complex microservices architectures.</li>
</ul>
Cons:
<ul>
<li>
Requires Maintenance: As an open-source solution, setting up and maintaining Backstage falls on your internal teams.</li>
<li>
Steep Learning Curve: To unlock its full potential, a strong platform engineering expertise is often necessary.</li>
<li>
Plugin Dependency: While the plugin ecosystem is extensive, some specialized integrations may require custom development.</li>
</ul>
Best for: Organizations with dedicated platform engineering teams looking for a flexible, customizable solution.
<h4>Harness</h4>
Harness is a commercial IDP platform that combines developer portal capabilities with software delivery automation. Known for its simplicity and enterprise features, Harness integrates deployment automation, cost optimization, and governance into a streamlined experience.
Pros:
<ul>
<li>
Turnkey Solution: Harness offers a ready-to-use platform with minimal setup required that allows teams to ship code faster.</li>
<li>
Automation: Built-in deployment tools, cost management features, and incident handling capabilities streamline developer workflows.</li>
<li>
Robust Governance: Enforces security policies and ensures compliance, making it ideal for enterprise needs.</li>
<li>
Enterprise Support: Provides dedicated support to quickly address issues and scale as your organization grows.</li>
</ul>
Cons:
<ul>
<li>
Less Customizable: While Harness covers a wide range of use cases, it offers less flexibility compared to open-source solutions like Backstage.</li>
<li>
Cost: The commercial nature of Harness means it may not be financially viable for smaller organizations or those with tighter budgets.</li>
<li>
Tightly Integrated Ecosystem: While the platform offers many integrated tools, connecting it to external tools may require extra work but harness provides the support to do so.</li>
</ul>
Best for: Enterprises looking for a scalable, out of the box solution with strong governance and automation capabilities.
<h4>Port</h4>
Port is a modern IDP that focuses on service ownership and visibility. Designed to streamline microservices management, it provides centralized observability and self-service capabilities for developers.
Pros:
<ul>
<li>
Service Ownership Focus: Encourages accountability by clearly cataloging services, environments, and resources.</li>
<li>
Visual Clarity: Provides a centralized view of microservices and their dependencies.</li>
<li>
Self-Service Capabilities: Developers can provision environments and access logs independently.</li>
<li>
Actionable Insights: Built-in observability tools help teams monitor service performance and dependencies.</li>
</ul>
Cons:
<ul>
<li>
Relatively New: Port is still maturing and lacks the widespread adoption and ecosystem of platforms like Backstage.</li>
<li>
Initial Customization Effort: Adapting Port to fit your organization’s specific needs may require significant initial engineering resources.</li>
<li>
Limited Scope: Port focuses primarily on microservices management, which may not address broader organizational needs.</li>
</ul>
Best for: Teams managing complex microservices architectures who prioritize service ownership and self-service capabilities.
<h3>Closing Thoughts: Selecting the Best IDP for Your Organization</h3>
Choosing the right IDP is a decision that should align with your team’s unique needs. Whether you’re managing a microservices-based architecture or a more traditional system, and whether you need a highly customizable solution or a simple out of the box option, the IDP you choose will impact your team’s productivity and overall success.
I’ve seen firsthand how implementing the right IDP can transform a team’s ability to deliver software streamlining workflows, improving collaboration, and accelerating time to market. To make an informed choice, consider these next steps:
<ol>
<li>
Evaluate Current Needs: Take stock of your existing workflows, tools, and developer needs.</li>
<li>
Test the Options: Many platforms offer trials or open-source versions — test them to see which fits your team best.</li>
<li>
Seek Feedback: Engage developers early in the process to understand their pain points and get their input.</li>
<li>
Plan for Scaling: Ensure the solution you choose can scale as your organization grows, both in terms of users and functionality.</li>
</ol>
The right IDP will help accelerate software delivery, reduce cognitive load, and foster a culture of collaboration and innovation. Use this guide to evaluate your options and choose a solution that will set your team up for success. Happy building!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=e0b2023636e8" width="1" height="1" alt="">

Harnessing the Power of Internal Developer Portals

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*pt27omojtSCuBeMZZlrw4g.jpeg"></figure>The following article focuses on Platform engineering teams and Internal Developer Portals as Catalysts for adopting modern software delivery techniques.
In my position as a platform engineering tech lead Im approached almost on a daily basis by leaders and innovators who want to excelerate their development while still maintaining best practices and not paying for it in velocity.
In Today’s fast-paced development landscape, organizations struggle with a web of complex challenges that prevent them from getting code into production efficiently and safely.
Development teams face a triple challenge: 1. Velocity vs. Reliability: How can we ship high-quality software quickly while maintaining operational excellence? 2.Standardization at Scale: How do we ensure consistent observability, security, and operational practices across dozens or hundreds of microservices? 3.Knowledge Sharing: How do we prevent teams from solving the same problems repeatedly with different, incompatible solutions?
Enter platform engineering a discipline that’s rapidly emerging not just as a technical solution, but as a comprehensive approach to these fundamental challenges. By providing a structured “paved road” for software delivery, platform engineering helps organizations transform their development workflow from a maze of individual decisions into a streamlined, standardized process that maintains both speed and quality.
<h3>What is Platform Engineering?</h3>
Platform engineering represents the natural evolution of DevOps principles, transforming them from a set of practices into a structured, product-driven discipline. While DevOps brought development and operations together, platform engineering takes this fusion further by creating a comprehensive, systematic approach to software delivery and operations.
At its essence, platform engineering is both an art and a science — the art of crafting intuitive developer experiences, and the science of building robust, scalable systems. It’s about creating what we call a “paved road”: a well-designed, thoroughly documented path that engineering teams can follow to transform their code into production-ready services with minimal friction.
This discipline operates at a crucial intersection where multiple technical domains converge:
<ul>
<li>Development practices that enhance productivity and code quality</li>
<li>Infrastructure management that ensures scalability and reliability</li>
<li>Operational excellence that maintains system health and performance</li>
<li>Developer experience that reduces friction and accelerates delivery</li>
<li>Security and compliance that protect systems and data throughout the software lifecycle</li>
</ul>
The industry’s rapid embrace of platform engineering isn’t just a trend — it’s a response to real organizational needs. Gartner’s prediction that 80% of software engineering organizations will establish dedicated platform teams by 2026 reflects a fundamental shift in how we think about software delivery. These teams are tasked with building and maintaining internal developer platforms: which are comprehensive solutions that provide the tools, workflows, and environments needed for efficient software development and operations.
This shift represents more than just adding another team or tool — it’s about creating a foundation that enables organizations to scale their software delivery capabilities while maintaining quality and security. Internal developer platforms serve as the cornerstone of this approach, providing a standardized yet flexible environment that empowers developers.
<h3>Why Platform Engineering Matters Now</h3>
The emergence of platform engineering as a critical discipline isn’t coincidental — it’s a direct response to the evolving challenges in modern software development that we discussed earlier. The key factors driving this transformation are:
<h4>Growing Complexity in Modern Architecture</h4>
Remember the triple challenge we mentioned? The complexity of modern software systems exemplifies this perfectly. Today’s applications aren’t just single monoliths — they’re intricate ecosystems of containers, microservices, cloud services, and DevOps tools. Without a structured platform approach, organizations find themselves navigating a maze of technologies, each requiring specific expertise and management. Platform engineering provides the framework needed to tame this complexity, turning potential chaos into manageable, standardized processes.
<h4>The Developer Productivity Imperative</h4>
Recall Gene Kim’s observation about code in production being the only generator of value. This principle highlights why developer productivity is crucial. Organizations are realizing they can’t afford to have their valuable development teams spending precious time wrestling with infrastructure concerns, debugging CI/CD pipelines, or handling operational issues. Every hour spent on these tasks is an hour not spent delivering business value. Platform engineering addresses this by creating standardized, automated solutions that handle these operational concerns, allowing developers to focus on what they do best — writing code that delivers value.
<h4>The Scale of Standardization</h4>
As we discussed in our introduction, organizations face significant challenges in maintaining consistent practices across teams. This need for standardization becomes even more critical as organizations scale. Platform engineering provides the foundation for implementing uniform security controls, consistent operational standards, and shared best practices across all development teams. This standardization isn’t about restricting creativity — it’s about creating a reliable foundation that teams can build upon.
<h4>Cloud Native Evolution</h4>
The shift to cloud native architectures has transformed how we build and deploy software. This transformation brings new challenges in managing infrastructure, ensuring observability, and coordinating service delivery. Platform engineering helps organizations navigate this cloud native landscape by providing structured approaches to:
<ul>
<li>Container orchestration and management</li>
<li>Service mesh implementation</li>
<li>Observability and monitoring solutions</li>
<li>Security and compliance in distributed systems</li>
</ul>
This evolution of platform engineering addresses the fundamental challenges we identified earlier — the tension between velocity and reliability, the need for standardization, and the importance of knowledge sharing. By providing a structured approach to these challenges, platform engineering has become not just useful but essential for modern software development organizations.
<h3>The Platform Engineering Mindset: Building for Developer Success</h3>
Understanding the technical aspects of platform engineering is only half the battle. The true differentiator between successful and struggling platform team often lies in the mindset and approach of the team. This mindset represents a fundamental shift in how we think about internal tooling and infrastructure.
<h4>Embracing Product Thinking</h4>
Think of the last product you used perhaps your favorite development tool or productivity app. What made it great? Chances are it wasn’t just the features, but how thoughtfully they were implemented with the user in mind. This same principle applies to platform engineering. Your platform isn’t just a collection of tools and services; it’s a product, and your developers are your customers.
This means moving beyond the traditional approach which is “build it and they will come”. Instead, platform teams must engage with their developer customers, understand their pain points, and create solutions that genuinely make their lives easier. This involves regular user research, feedback sessions, and a commitment to continuous improvement based on actual usage patterns and developer needs.
<h4>The Power of Golden Paths</h4>
Imagine you’re hiking in a national park. While you could theoretically forge your own trail and choose where to go, the maintained paths offer the safest, most efficient route to your destination. Similarly, golden paths in platform engineering provide developers with well-maintained, documented routes for completing common tasks.
These paths aren’t rigid constraints but rather carefully designed defaults that make the right way the easy way. They should handle 80% of common use cases while still allowing for deviation when necessary. For example, a golden path might provide a standardized way to deploy a microservice, complete with monitoring, logging, and security controls, while still allowing teams to customize specific aspects when their use case demands it.
<h4>Cultivating a Self-Service Culture</h4>
In the modern development landscape, waiting for someone else to provision resources or configure services isn’t just inefficient — it’s a competitive disadvantage. The self-service mindset is about empowering developers to safely and confidently accomplish tasks without dependencies on platform teams or other groups.
This goes beyond simply providing automation tools. It requires creating comprehensive documentation, clear usage guidelines, and robust guardrails that give developers the confidence to help themselves. When done right, self-service capabilities act like a well-designed vending machine: users can get what they need quickly and safely, while platform teams can focus on improving the service rather than handling routine requests.
<h4>Committing to Continuous Evolution</h4>
Platform engineering isn’t a “build once, use forever” endeavor. Technology landscapes evolve, organization needs change, and developer expectations grow. Successful platform teams understand that their platform must evolve continuously to remain valuable.
This evolution isn’t just about adding new features — it’s about regularly reassessing existing capabilities, removing outdated components, and refining the platform based on emerging best practices and technologies. Think of it like maintaining a garden rather than building a static structure. Regular pruning, updates, and replanting are essential for keeping the ecosystem healthy and productive.
<h3>Putting it All Together</h3>
These mindset elements work together to create a platform that truly serves its users. Product thinking helps you understand what to build, golden paths show you how to build it effectively, self-service principles guide how to deliver it, and continuous evolution ensures it stays relevant and valuable over time.
By embracing these principles, platform teams can create not just a set of tools, but a genuine enablement layer that accelerates software delivery while maintaining operational excellence. This mindset transforms platform engineering from a technical initiative into a strategic advantage for the entire organization.
<h3>Getting Started with Platform Engineering</h3>
Building a successful platform engineering practice doesn’t happen overnight. To get started, you should focus on the following key steps:
<ol>
<li>Understanding your developers’ pain points and needs</li>
<li>Identifying the most impactful areas for standardization</li>
<li>Creating clear documentation and support processes</li>
<li>Building a minimum viable platform that addresses core needs</li>
<li>Establishing feedback loops with your users</li>
</ol>
Remember, the goal isn’t to build the perfect platform immediately, but to create a foundation that can evolve with your organization’s needs.
<h3>Conclusion</h3>
Platform engineering marks a pivotal shift in software delivery, transcending DevOps to address the challenges of modern development. By creating streamlined, standardized paths to production, it tackles complexity, boosts developer productivity, and ensures consistent practices across scaling architectures.
Beyond its technical foundations, platform engineering’s power lies in its mindset. By embracing product thinking, golden paths, self-service principles, and continuous evolution, organizations can transform development workflows into efficient, developer-empowering systems.
Looking ahead, the next article in my series, “How to Build a Platform Without Pulling Your Hair,” will explore the essential components of modern internal developer platforms. I’ll share practical strategies for immediate value creation and long-term growth.
Remember, the journey to effective platform engineering isn’t about creating the perfect system overnight — it’s about building a foundation that evolves with your organization’s needs, guided by a clear understanding of your developers’ challenges and a commitment to continuous improvement.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=70116f584fa6" width="1" height="1" alt="">

The Foundations of Modern Software Delivery

Kindly allow me to introduce myself, my name is Michael, a DevOps Engineer and a Solution Architect specialist serving corporate clients of various industries. That said and with your humble permission, I would like to take this festive opportunity to share with you personal insights and thoughts related to Istio service mesh and ways of implementing it in Kubernetes.
<h4>What is Service Mesh?</h4>
Modern applications are typically architected as distributed collections of microservices, with each collection performing some function. A service mesh is a dedicated infrastructure layer that you can add to your applications. It allows you to transparently add capabilities like observability, traffic management, and security without adding them to your code.
<h4>What is Istio and how does it work?</h4>
Istio Service Mesh is an open-source platform that provides a unified way to manage microservices in a distributed system. It provides a layer of infrastructure between the services and the network, making it easy to manage service-to-service communication. Istio provides a set of features, including traffic management, security, observability, and policy enforcement. Istio control plane brings extra features, including:
· Secure service-to-service communication in a cluster with TLS encryption, strong identity-based authentication, and authorization
· Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic
· Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
· A pluggable policy layer and configuration API supporting access controls, rate limits, and quotas.
· Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
<h4>Istio Architecture:</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/936/1*wtHlbVtRiIF0qrKHhpkpyw.png"><figcaption>Credit: Istio.io</figcaption></figure>· Pilot: Provides fleet-wide traffic management capabilities in the Istio Service Mesh
· Citadel: This is your certificate authority that provides certificates to each service in order to provide TLS encryption.
· Galley: Is Istio’s configuration validation, ingestion, processing, and distributing component. Responsible for insulating the rest of the Istio component from the details of obtaining user configuration from the underlying platform.
· Envoy: A high-performance proxy used by Istio that is in charge of mandating all the inbound and outbound traffic in the service mesh. It is used as a sidecar container and is mandatory to provide you with the ability to implement Istio capabilities.
<h4>How to deploy Istio in Kubernetes:</h4>
Step 1:
Use the following command to download Istio to your cluster:
<pre>curl -L https://istio.io/downloadIstio | sh -</pre>
Step 2:
Move to the directory you downloaded in the previous step and add the istioctl binary to your path with the following command:
<pre>export PATH=$PWD/bin:$PATH</pre>
Step 3:
After we set the istioctl binary in our path, we can use it to download Istio to our cluster and verify it with the following commands:
<pre>istioctl install –set profile=default -y</pre>
<pre>kubectl get pods -n Istio-systems</pre>
Please note that the profile can change between environments, and there are extra recommended steps before setting up Istio in production.
Step 4:
Now, to enable Istio to inject sidecar containers into our deployments, we need to label the namespace to enable Istio with the following command:
<pre>kubectl label namespace default Istio-injection=enabled</pre>
You may not see the injection of sidecars right away; if so restart the deployments, and then Istio will take effect and put the sidecar containers.
Bonus step:
In the folder we downloaded previously, we have the kali dashboard, which is perfect for Istio and provides you with an easy way to observe your service mesh and validate configurations and capabilities.
To download kiali, do the following commands in the Istio directory:
<pre>kubectl apply -f samples/addons</pre>
<pre>kubectl rollout status deployment/kiali -n Istio-system</pre>
<pre>istioctl dashboard kiali</pre>
You can also expose kiali in the cluster and show it like any other monitoring dashboard.
<h4>How to use Istio in our cluster</h4>
Istio provides us with additional resources we need to use to implement his capabilities:
Destination Rule
DestinationRule defines policies that apply to traffic intended for service after routing has occurred. These rules can specify configuration for load balancing, you can create subsets of deployments (v1, v2) in order to implement canary deployments, and much more.
Virtual Service
A VirtualService defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines a matching criterion for the traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service defined in the registry.
Gateway
We use this resource to manage inbound and outbound traffic for our mesh. The gateway lets you use the full power of Istio’s traffic routing and is used instead of Kubernetes ingress resources. You can do this because the gateway resource lets you configure layer 4–6 load balancing properties such as ports to expose, TLS settings, and so on. You bind a regular Istio virtual service to the gateway. This lets you manage gateway traffic like any other data plane traffic in an Istio mesh.
<h4>Use Case</h4>
Istio enables developers to separate and manage service-to-service communications within a dedicated infrastructure layer. As we go over time to implement more microservice approaches in applications, so do the benefits of using a service mesh to manage and monitor them.
example use case:
The easiest example is the book info application shown in the Istio documentation:
The application is broken into four separate microservices:
1. product page — which shows calls the details and reviewer’s microservices to populate the page.
2. details — contain the book information.
3. reviews — contain the book reviews and call rating microservice.
4. ratings — contain book ranking information that accompanies a book review.
We have 3 versions of the reviews microservice.
· version 1 doesn’t call the rating service.
· version 2 calls the ratings service and displays ranking in black starts.
· version 3 calls the ratings service and displays the ranking in red starts.
As we all know, the approach in the industry is agile development, which means we want to release new versions faster than ever.
Let’s say we want only calls with a certain header to reach version 3 because it’s still in the early test phase, only a small percent of traffic to reach version 2 because we want to implement a canary type of deployment, and all the other traffic reach version 1.
With the help of Istio, we can set subsets for each version of the rating service using the destination rules and set certain rules regarding traffic with our virtual service.
<h4>Conclusion</h4>
Istio service mesh provides a powerful way to manage microservices in a distributed system. It provides features like traffic management, security, observability, and policy enforcement, which make it easy to manage communication between services.
I hope my guide helped you understand a few of the concepts, although there is much more to learn to use Istio correctly, especially in Production environments. I would suggest that you continue exploring the Istio documentation and try doing a few projects or courses about Istio to enrich your knowledge and understand all the options you have with it.
Thank you for reading. Feel free to connect with me on <a href="https://www.linkedin.com/in/michael-liav-a5484b220">LinkedIn</a>.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=3df3375aca0c" width="1" height="1" alt="">

Latest Articles

All Articles