Bună! Sunt

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

Contactează-mă

Despre Mine

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Competențele Mele

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Automatizarea Proceselor

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Sisteme Personalizate

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

Misiunea Mea

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

Democratizarea Tehnologiei

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

Unirea IT și Economiei

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

Crearea de Soluții Personalizate

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Transformă-ți Afacerea cu Tehnologia

Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.

Hai să Vorbim →

Unisciti alla Community

Entra nella community di sviluppatori dove discutiamo di software, AI, architettura e DevOps. Condividi idee, fai domande e cresci insieme a noi.

Canale

FC Dev Blog

Ricevi notifiche su nuovi articoli, serie complete, tips settimanali e tool in evidenza. Contenuti bilingui IT/EN direttamente nel tuo Telegram.

Nuovi articoli appena pubblicati
Tips e code snippets settimanali
Sondaggi sugli argomenti futuri

Iscriviti al Canale

Gruppo

FC Dev Community

Una community bilingue IT/EN per sviluppatori. Discussioni, Q&A, aiuto reciproco e networking con altri professionisti del settore.

Discussioni su articoli e tecnologie
Help coding e code review
Opportunità di lavoro e collaborazione

Unisciti al Gruppo

Topic di Discussione

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

Linguaggi & Tecnologie

Java

Python

JavaScript

Angular

React

TypeScript

SQL

PHP

CSS/SCSS

Node.js

Docker

Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Contactează-mă

Ai un proiect în minte? Hai să vorbim! Completează formularul și îți voi răspunde curând.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

Service Mesh: Istio vs Linkerd, mTLS și gestionarea traficului

Într-o arhitectură de microservicii pe Kubernetes, fiecare serviciu comunică cu zeci de alții. Cine garantează că aceste comunicații sunt criptate? Cine gestionează reîncercarea automată când un serviciu este temporar inaccesibil? Cine furnizează valorile privind latența și rata de eroare pentru fiecare pereche sursă-destinație? Fără o plasă de serviciu, răspundeți la acestea întrebările necesită cod personalizat în fiecare serviciu.

Un plasă de serviciu rezolvă aceste probleme la nivel de infrastructură, transparent la aplicare. Cei doi jucători dominanti în mediul Kubernetes sunt Istio, cel mai bogat în caracteristici și Linkerd, proiectat pentru simplitate și minimă suprasolicitare. Acest articol arată cum se instalează ambele, configurați mTLS automat, gestionați traficul cu implementarea Canary și întreruperea circuitului și când să alegeți una sau alta.

Ce vei învăța

Cum funcționează o rețea de serviciu: plan de date (sidecar) și plan de control
mTLS automat: ce înseamnă, cum să-l verifici, cum să gestionezi excepțiile
Istio: instalare, VirtualService, DestinationRule, canary și albastru/verde
Linkerd: instalare ușoară, SMI TrafficSplit, extensii
Întreruperea circuitului cu Istio OutlierDetection
Reîncercați și expirați la nivel de infrastructură
Observabilitate: valorile semnalelor de aur din rețeaua de serviciu
Istio vs Linkerd: când să alegi pe care

Cum funcționează o plasă de servicii

Rețeaua de serviciu se bazează pe injectarea automată a a proxy sidecar (Envoy pentru Istio, Linkerd2-proxy pentru Linkerd) în fiecare Pod. Sidecarul interceptează totul trafic în și din containerul aplicației, fără a necesita modificări la cod.

Il planul de date și setul de toate sidecar-urile proxy care se ocupă de trafic eficient. The planul de control (Istiod pentru Istio, linkerd-control-plane pentru Linkerd) distribuie configurația către proxy, gestionează certificate pentru mTLS și colectează telemetria.

Comparație Istio vs Linkerd

Caracteristică	Istio	Linkerd
Proxy Sidecar	Envoy (C++, 50-100MB)	linkerd2-proxy (Rugina, 10-20 MB)
Suplimentar de memorie pentru Pod	100-200 MB	20-30 MB
Latență peste cap P99	2-5 ms	0,5-1 ms
mTLS automat	Da (cert-manager sau încorporat)	Da (rotire automată 24 de ore)
Managementul traficului	Complet (serviciu virtual, DR)	De bază (HTTPRoute, TrafficSplit)
Politica L7	HTTP, gRPC, TCP	HTTP, gRPC
Intrare	Gateway API + Gateway Istio	Gateway API
Curba de învățare	Abrupt	Moderat
Maturitatea producției	Ridicat (Google, Airbnb)	Ridicat (Shopify, Microsoft)

Istio: Instalare și configurare de bază

Instalare cu istioctl

# Scarica e installa istioctl
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.22.0 sh -
export PATH=$PWD/istio-1.22.0/bin:$PATH

# Installa Istio con profilo di produzione
istioctl install --set profile=production -y

# Il profilo production abilita:
# - HA con multiple repliche del control plane
# - Affinity rules per distribuire su nodi diversi
# - Risorse CPU/memoria adeguate
# - Solo le feature necessarie (no addon come Kiali, Jaeger)

# Abilita l'iniezione automatica del sidecar nel namespace
kubectl label namespace production istio-injection=enabled

# Verifica lo stato del mesh
istioctl proxy-status

# Analizza la configurazione per possibili problemi
istioctl analyze --namespace production

mTLS cu Istio: PeerAuthentication și DestinationRule

Istio implementează mTLS automat între toate podurile sidecar injectate. Cu PeerAuthentication se poate face prin mTLS STRICT (obligatoriu) a spațiu de nume sau întreg nivel de plasă:

# mtls-strict.yaml
# Abilita mTLS STRICT per tutto il namespace production
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT  # DISABLE, PERMISSIVE, STRICT
---
# Eccezione: un servizio legacy che non ha sidecar
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: legacy-service-exception
  namespace: production
spec:
  selector:
    matchLabels:
      app: legacy-service
  mtls:
    mode: PERMISSIVE  # accetta anche connessioni plain-text

# Verifica mTLS
kubectl exec -n production frontend-pod -c istio-proxy -- \
  pilot-agent request GET /config_dump | grep -A5 "tls_context"

# Visualizza lo stato mTLS con istioctl
istioctl x describe pod frontend-pod.production

VirtualService: rutare și împărțire a traficului

VirtualService definește modul în care este direcționat traficul către un serviciu, cu reguli bazate pe antete HTTP, ponderi, potrivire a căilor:

# virtual-service-canary.yaml
# Canary deployment: 90% traffico a v1, 10% a v2
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api-service-vs
  namespace: production
spec:
  hosts:
    - api-service  # nome del Kubernetes Service
  http:
    # Routing per header: dev e QA ricevono sempre v2
    - match:
        - headers:
            x-user-group:
              exact: "beta-testers"
      route:
        - destination:
            host: api-service
            subset: v2
    # Traffico generale: 90/10 split
    - route:
        - destination:
            host: api-service
            subset: v1
          weight: 90
        - destination:
            host: api-service
            subset: v2
          weight: 10
      # Timeout e retry a livello di infrastruttura
      timeout: 5s
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: "5xx,reset,connect-failure,retriable-4xx"
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-service-dr
  namespace: production
spec:
  host: api-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    loadBalancer:
      simple: LEAST_CONN  # ROUND_ROBIN, RANDOM, LEAST_CONN
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Întrerupător cu OutlierDetection

Întrerupătorul de circuit elimină temporar gazdele „nesănătoase” de la echilibrarea sarcinii pool atunci când depășesc pragurile de eroare definite:

# destination-rule-circuit-breaker.yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: payment-service-circuit-breaker
  namespace: production
spec:
  host: payment-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 50
        connectTimeout: 3s
      http:
        http1MaxPendingRequests: 100
        http2MaxRequests: 500
        maxRetries: 3
    outlierDetection:
      # Rimuovi un host se in 10 secondi riceve 5 errori 5xx
      consecutiveGatewayErrors: 5
      consecutive5xxErrors: 5
      interval: 10s
      # Tienilo fuori per 30 secondi
      baseEjectionTime: 30s
      # Massimo 50% degli host puo essere rimosso
      maxEjectionPercent: 50
      # Analizza solo richieste con 100ms o piu di latenza
      minHealthPercent: 50

Istio Gateway pentru traficul de intrare

# istio-gateway.yaml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: wildcard-tls-cert  # Secret con cert TLS
      hosts:
        - "*.federicocalo.dev"
    - port:
        number: 80
        name: http
        protocol: HTTP
      tls:
        httpsRedirect: true  # redirect tutto HTTP a HTTPS
      hosts:
        - "*.federicocalo.dev"
---
# Collega il Gateway al VirtualService
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api-gateway-vs
  namespace: production
spec:
  hosts:
    - "api.federicocalo.dev"
  gateways:
    - istio-system/production-gateway
    - mesh  # anche per traffico interno al mesh
  http:
    - route:
        - destination:
            host: api-service
            port:
              number: 8080

Politica de autorizare: Controlul accesului

# authorization-policy.yaml
# Solo il frontend puo chiamare il backend
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-access-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/frontend-service-account"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/v1/*"]
---
# Blocca tutto il resto (default deny)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  action: DENY
  # Nessun selector = si applica a tutti i Pod nel namespace
  # Nessuna rule = blocca tutto

Linkerd: Instalare și configurare

Linkerd favorizează simplitatea operațională și performanța. Proxy-ul său scris în Rust Are o supraîncărcare de ~1ms latență P99 și ~20MB de memorie per Pod, ceea ce îl face ideal pentru clustere cu multe microservicii sau constrângeri de resurse.

Instalare Linkerd

# Installa Linkerd CLI
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
export PATH=$HOME/.linkerd2/bin:$PATH

# Prerequisiti: verifica che il cluster sia compatibile
linkerd check --pre

# Installa il control plane
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

# Verifica installazione
linkerd check

# Abilita injection sul namespace
kubectl annotate namespace production linkerd.io/inject=enabled

# Installa l'estensione Viz per osservabilita
linkerd viz install | kubectl apply -f -
linkerd viz check
linkerd viz dashboard &

Canary cu Linkerd și HTTPRoute (API-ul Gateway)

# linkerd-canary-httproute.yaml
# Linkerd usa la Gateway API per il traffic splitting
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-service-canary
  namespace: production
spec:
  parentRefs:
    - name: api-service
      kind: Service
      group: core
      port: 80
  rules:
    - backendRefs:
        - name: api-service-v1
          port: 80
          weight: 90
        - name: api-service-v2
          port: 80
          weight: 10

# Monitora il canary con linkerd viz
linkerd viz stat httproute/api-service-canary -n production
linkerd viz routes deploy/api-service-v2 -n production

Observabil cu Linkerd

# Visualizza metriche golden signals per tutti i deployment
linkerd viz stat deploy -n production

# Output tipico:
# NAME              MESHED   SUCCESS     RPS   LATENCY_P50   LATENCY_P99   TCP_CONN
# api-service       4/4      99.8%       245   1ms           12ms          42
# backend-service   3/3      98.2%       180   3ms           45ms          28
# payment-service   2/2      100.0%      65    8ms           89ms          12

# Visualizza il traffico per un singolo Pod
linkerd viz tap pod/api-service-xyz -n production

# Genera un report di osservabilita
linkerd viz check --proxy -n production

Istio Telemetry: metrici, urmărire și înregistrare

Istio emite automat semnale de aur (latență, trafic, erori, saturație) pentru fiecare pereche sursă-destinație. Valorile sunt expuse în format Prometheus și vizibil în Grafana cu tablourile de bord oficiale Istio.

# telemetry-config.yaml
# Configura il sampling per il distributed tracing
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-tracing
  namespace: istio-system
spec:
  tracing:
    - providers:
        - name: tempo  # o jaeger, zipkin
      randomSamplingPercentage: 1.0  # campiona 1% del traffico in produzione
---
# Metriche custom per un servizio specifico
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: payment-service-metrics
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  metrics:
    - providers:
        - name: prometheus
      overrides:
        - match:
            metric: REQUEST_COUNT
          tagOverrides:
            destination_version:
              value: "request.headers['x-version'] | 'unknown'"

# Importa le dashboard Grafana ufficiali Istio
# Dashboard ID: 7639 (Mesh Overview), 11829 (Service), 12378 (Workload)

Service Mesh vs Cilium eBPF: Când să le folosiți

Odată cu apariția Cilium, care oferă politici mTLS și L7 fără sidecar-uri (prin eBPF în nucleu), alegerea este complicata. Iată un ghid practic:

Scenariu	Alegere recomandată	Motiv
Microservicii cu management avansat al traficului (canary, rutare bazată pe antet)	Istio	VirtualService/DestinationRule de neînlocuit
Securitate mTLS cu cheltuieli minime	Linkerd sau Cilium	Rust proxy sau eBPF minim
Cluster cu sute de microservicii, resurse limitate	Linkerd sau Cilium mTLS	Suprafața laterală înmulțită cu fiecare Pod
Multi-cluster sau multi-cloud	Istio	Federație mesh încorporată
Echipa nouă în service mesh	Linkerd	Curba de învățare semnificativ mai mică

Cele mai bune practici pentru Service Mesh

Lista de verificare pentru Service Mesh în producție

Începeți în modul PERMISIV: activați mTLS în PERMISSIVE înainte de a-l STRICT, pentru a identifica serviciile care nu au încă sidecar
Setați timeout pentru toate VirtualServices: fără timeout, o dependență lentă blochează întregul lanț de apeluri
Întrerupător pentru fiecare dependență externă: baze de date, API-uri externe, servicii de plată
Folosiți reîncercarea numai pentru erorile idempotente: nu reîncercați automat pe POST fără cheia idempotence, altfel veți crea comenzi duplicate
Monitorizați procesorul/memoria sidecar: în grupuri cu multe Pod-uri, supraîncărcarea agregată a sidecarului poate fi semnificativă
Testare failover: dezactivați manual un pod și verificați dacă întrerupătorul și reîncercările funcționează conform așteptărilor
Păstrați rețeaua actualizată: Versiunile Istio și Linkerd au cicluri de viață scurte (6-12 luni); planificați upgrade-uri regulate

Anti-modele comune

Reîncercări infinite cu amplificare: dacă A reamintește B cu 3 reîncercări și B reamintește C cu 3 reîncercări, o singură eroare generează 9 încercări către C (furtună de reîncercare)
Timeout-uri prea generoase: un timeout de 60 de secunde pe un API critic înseamnă că, în timpul unei întreruperi, toate firele/goroutinele aplicației sunt blocate timp de 60 de secunde
Ignorarea planului de control deasupra capului: Istiod consumă CPU/memorie semnificativă pentru fiecare proxy conectat; în clustere cu peste 1000 de poduri, este necesar un nod dedicat
Injectie selectiva fara avion: dacă doar unele Pod-uri au sidecar-uri, mTLS STRICT eșuează pentru comunicațiile către Pod-uri fără sidecar

Concluzii și pașii următori

Mesh-ul de serviciu a încetat să mai fie un „placut de a avea” și a devenit o cerință pentru orice arhitectură serioasă de microservicii. mTLS automat, observabilitate granulară, întreruperea circuitului și gestionarea declarativă a traficului rezolvă probleme reale fără o plasă de servicii ar necesita cod personalizat în fiecare serviciu.

Alegerea dintre Istio și Linkerd depinde de nevoile dvs.: Istio pentru scenarii complexe cu management avansat și multi-cluster al traficului, Linkerd pentru simplitate operațională și cheltuieli generale minim. În ambele cazuri, investiția inițială în învățare și configurare și a fost răsplătită prin reducerea codului de infrastructură în aplicații și vizibilitate impact fără precedent asupra traficului intra-cluster.

Articole viitoare din seria Kubernetes la scară

Articole anterioare

Serii înrudite

Rețea Kubernetes: Cilium cu eBPF — alternativă la rețeaua de serviciu pentru mTLS
Observabilitate și OpenTelemetry — urmărire distribuită integrată cu Istio
Ingineria platformei — plasă de serviciu ca platformă internă