{"id":1782,"date":"2022-02-22T10:38:00","date_gmt":"2022-02-22T09:38:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/api-gateway-kong-tyk-aws-pmi-architettura-2022\/"},"modified":"2022-02-22T10:38:00","modified_gmt":"2022-02-22T09:38:00","slug":"api-gateway-kong-tyk-aws-pmi-architettura-2022","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/api-gateway-kong-tyk-aws-pmi-architettura-2022\/","title":{"rendered":"API Gateway per PMI 2022: Kong vs Tyk vs AWS API Gateway, scelta architetturale"},"content":{"rendered":"

Quando un’azienda inizia a esporre API verso clienti B2B, integrare partner via webhook, federare servizi cloud e suddividere il monolite in microservizi, qualcosa di apparentemente banale diventa centrale: il traffico HTTP smette di essere lineare. Ogni endpoint ha le sue logiche di autenticazione, rate limiting, logging, versioning, trasformazione del payload. Replicare queste logiche dentro ogni microservizio significa duplicare codice, divergere nelle policy di sicurezza e perdere visibilit\u00e0 sul comportamento del sistema. Da qui nasce il concetto di API gateway: un unico punto di ingresso che fa da vigile urbano per tutto il traffico applicativo, separando le responsabilit\u00e0 trasversali (cross-cutting concerns) dalla logica di business.<\/p>\n

Nel 2022 l’API economy \u00e8 un mercato maturo. Twilio, Stripe, Shopify, Salesforce hanno dimostrato che le API non sono un dettaglio tecnico ma un canale di vendita. Anche per una PMI italiana che fattura 5-20 milioni e gestisce un gestionale custom collegato a 3 marketplace, due partner logistici e un’app mobile, la domanda non \u00e8 pi\u00f9 “mi serve un API gateway?” ma “quale scelgo, come lo deployo, quanto mi costa nei prossimi 36 mesi?”. In questo articolo confrontiamo i tre candidati che oggi monopolizzano le shortlist tecniche: Kong Gateway<\/strong>, Tyk<\/strong> e AWS API Gateway<\/strong>. Analizziamo architettura, pricing, performance, ecosistema plugin, lock-in e maturit\u00e0 del developer portal, con un occhio sempre puntato al contesto PMI: budget contenuti, team piccoli, esigenza di non scrivere infrastruttura per il gusto di scriverla.<\/p>\n

\n

TL;DR \u2014 Verdetto per persona<\/h3>\n
    \n
  • Startup tech \/ cloud-agnostic con 5-15 microservizi<\/strong> \u2192 Kong Gateway OSS self-hosted su Kubernetes. Gratis, plugin ecosystem ricco, portabilit\u00e0 totale fra AWS\/GCP\/Azure.<\/li>\n
  • PMI con team DevOps minimale, budget ridotto<\/strong> \u2192 Tyk Open Source self-hosted. Dashboard inclusa nel piano gratuito community, configurazione meno verbosa di Kong.<\/li>\n
  • Azienda gi\u00e0 all-in su AWS con Lambda e Cognito<\/strong> \u2192 AWS API Gateway (HTTP API). Zero gestione infrastruttura, billing al consumo, integrazione nativa con il resto dello stack.<\/li>\n<\/ul>\n<\/div>\n

    Cos’\u00e8 davvero un API gateway (e cosa non \u00e8)<\/h2>\n

    Un API gateway \u00e8 un reverse proxy specializzato che si interpone fra i client (browser, app mobile, partner B2B, altri microservizi) e il backend. Ma confonderlo con un reverse proxy generico come NGINX standalone o HAProxy \u00e8 un errore comune. Un reverse proxy classico instrada il traffico e bilancia il carico. Un API gateway aggiunge consapevolezza del protocollo API: parsing JSON, validazione OpenAPI, gestione di token OAuth 2.0 e JWT, rate limiting per consumatore, trasformazione di payload fra REST e gRPC, caching contestuale, exposing di metriche per endpoint.<\/p>\n

    Va distinto anche da due figure architetturali con cui spesso viene confuso. L’Enterprise Service Bus<\/strong> (ESB) degli anni 2000 \u2014 IBM WebSphere, Oracle Service Bus, TIBCO \u2014 implementava trasformazioni complesse, orchestration di processi business e routing basato su contenuto, ma era pensato per ambienti SOA legacy con XML e SOAP. L’API gateway moderno \u00e8 pi\u00f9 leggero, pi\u00f9 focalizzato, e delega l’orchestration ai microservizi stessi. Il service mesh<\/strong> (Istio, Linkerd, Kuma) opera invece a livello di traffico est-ovest fra microservizi interni, mentre l’API gateway si occupa del traffico nord-sud, cio\u00e8 ingressi esterni. I due strumenti convivono: gateway al perimetro, mesh dentro al cluster.<\/p>\n

    \"Developer<\/p>\n

    Le sette responsabilit\u00e0 di un API gateway<\/h2>\n

    Prima di scegliere uno strumento serve un check sulle responsabilit\u00e0 che dovr\u00e0 coprire. Non tutti i gateway le implementano allo stesso modo, e alcune diventano fattori discriminanti.<\/p>\n

      \n
    1. Routing dinamico<\/strong>: mapping fra URL pubblici (api.azienda.it\/v2\/orders) e servizi interni (orders-svc.prod.svc.cluster.local). Deve supportare path matching, host matching, header matching.<\/li>\n
    2. Autenticazione e autorizzazione<\/strong>: validazione di chiavi API, JWT firmati, token OAuth 2.0 con introspection, mTLS per traffico machine-to-machine. Idealmente con delega a un Identity Provider esterno (Auth0, Keycloak, Okta).<\/li>\n
    3. Rate limiting e quota<\/strong>: limiti per IP, per consumer, per piano (free\/pro\/enterprise), per endpoint. Sliding window, token bucket, distribuito su pi\u00f9 nodi gateway.<\/li>\n
    4. Trasformazione richieste\/risposte<\/strong>: riscrittura header, rimozione campi sensibili dalle risposte, conversione fra formati (REST in ingresso, gRPC verso backend), aggregazione di chiamate per BFF (Backend For Frontend).<\/li>\n
    5. Caching<\/strong>: caching delle risposte GET a livello edge per ridurre carico sul backend, con invalidazione per tag o per evento.<\/li>\n
    6. Observability<\/strong>: metriche Prometheus, trace distribuiti via OpenTelemetry, log strutturati JSON spediti a un’aggregator (Loki, Elasticsearch, Datadog).<\/li>\n
    7. Developer portal<\/strong>: documentazione OpenAPI auto-generata, self-service per registrazione applicazioni e generazione chiavi, sandbox per testing.<\/li>\n<\/ol>\n

      Se hai pi\u00f9 di 5 microservizi o stai per superare i 50 endpoint pubblici, queste responsabilit\u00e0 diventano critiche e replicarle a mano in ogni servizio non \u00e8 pi\u00f9 sostenibile. \u00c8 a questo punto che un API gateway non \u00e8 un nice-to-have ma un requisito infrastrutturale.<\/p>\n

      Kong Gateway: il colosso open source diventato piattaforma<\/h2>\n

      Kong nasce nel 2015 come fork specializzato di OpenResty (NGINX + Lua) e in pochi anni diventa de facto lo standard open source per API gateway. La release 2.8 di febbraio 2022 consolida il supporto a gRPC, le policy di routing basate su header e il pacchetto di plugin Enterprise. L’architettura \u00e8 semplice: un control plane (database PostgreSQL o configurazione dichiarativa via YAML) e un data plane stateless che processa il traffico. Si scala orizzontalmente aggiungendo nodi data plane dietro un load balancer.<\/p>\n

      Il vero asset di Kong \u00e8 l’ecosistema plugin. Su Kong Hub trovi oltre cento plugin ufficiali e community: rate limiting (locale, Redis, cluster), OAuth 2.0, JWT validation, IP restriction, request transformer, Prometheus, Datadog, OpenTelemetry, ACL, response rate limiting, bot detection. Se ti manca qualcosa scrivi un plugin in Lua o, dalla versione 2.x, in Go o Python via PDK. Per una PMI questo si traduce in libert\u00e0 operativa: nessun vendor lock-in, nessun rebuild dell’architettura se cambi cloud provider.<\/p>\n

      Sul fronte pricing nel 2022 lo scenario \u00e8 il seguente. Kong Gateway OSS \u00e8 gratuito a vita, anche per uso commerciale. Kong Enterprise (con RBAC granulare, developer portal commerciale, vitals analytics, plugin enterprise come Mocking e GraphQL rate limiting) \u00e8 in vendita con quote a partire da circa 25-50k euro\/anno per le piccole installazioni. Kong Konnect, l’offerta SaaS lanciata in beta nel 2021 e GA nel 2021, parte da circa $250 per utente al mese sul piano Plus, con consumo nodi gateway separato. Per molte PMI italiane il sweet spot resta Kong OSS self-hosted su Kubernetes managed (EKS, GKE, AKS): costo cloud pulito, zero licenze, controllo totale.<\/p>\n

      Lato performance Kong gestisce facilmente 10-20k richieste al secondo per nodo su hardware modesto (2 vCPU, 4 GB RAM), con latenza overhead nell’ordine dei 2-5 millisecondi. Per la maggior parte delle PMI italiane, un cluster di 2-3 nodi \u00e8 abbondantemente sovradimensionato.<\/p>\n

      Tyk: l’alternativa pragmatica con dashboard inclusa<\/h2>\n

      Tyk \u00e8 il principale challenger di Kong nel mondo open source. Scritto in Go (Kong \u00e8 Lua su NGINX), ha un footprint memoria pi\u00f9 contenuto e un avvio pi\u00f9 rapido. Tyk Gateway \u00e8 open source (Mozilla Public License) e include nativamente molte funzionalit\u00e0 che Kong distribuisce come plugin separati: rate limiting per chiave, quotas, transformation middleware, version routing, blueprint OpenAPI, analytics in-memory. Per chi non ama mettere insieme un mosaico di plugin, questa integrazione verticale ha il suo fascino.<\/p>\n

      L’offerta commerciale del 2022 si articola in tre piani. Tyk Self Managed<\/strong> \u00e8 la versione enterprise on-premise o cloud privato, con dashboard avanzata, sviluppatore portal, multi-tenancy, RBAC, MDCB (Multi Data Center Bridge). I prezzi pubblicati partono da circa $600 al mese per ambienti small. Tyk Cloud<\/strong> \u00e8 il SaaS multi-region, con piano Launch a partire da poche centinaia di dollari al mese e scaling fino al piano Enterprise. Tyk Open Source<\/strong> resta gratuito e include gateway, dashboard community e developer portal community.<\/p>\n

      Il punto forte per PMI \u00e8 proprio la dashboard inclusa nell’OSS. Kong OSS non ha dashboard ufficiale (esistono Konga e Kong Manager community, ma con limiti), Tyk s\u00ec. Significa che un team di 2 dev pu\u00f2 configurare API, chiavi, policy senza scrivere YAML, riducendo l’onboarding di settimane. L’observability \u00e8 solida: integrazione nativa con MongoDB o Redis per analytics, export Prometheus, plugin per Datadog e New Relic.<\/p>\n

      Punto debole: ecosistema pi\u00f9 piccolo. La community Tyk \u00e8 circa un quarto di quella Kong in termini di estensioni third-party, quindi se il tuo caso d’uso richiede plugin esotici potresti dover scriverteli. Su gRPC, GraphQL e WebSocket Tyk era nel 2022 ancora qualche passo indietro rispetto a Kong, ma con copertura sufficiente per la maggior parte delle PMI.<\/p>\n

      AWS API Gateway: zero ops, lock-in totale<\/h2>\n

      AWS API Gateway \u00e8 il servizio managed pi\u00f9 diffuso in assoluto, semplicemente perch\u00e9 chi \u00e8 gi\u00e0 su AWS lo trova a portata di click. Nel 2022 esistono tre varianti: REST API<\/strong> (la pi\u00f9 ricca, con caching nativo, validation OpenAPI, WAF integration, API keys, usage plans), HTTP API<\/strong> (pi\u00f9 snella e pi\u00f9 economica, ottimizzata per JWT\/OIDC e Lambda proxy), WebSocket API<\/strong> (per real-time bidirectional). La differenza di costo \u00e8 significativa: REST API costa $3,50 per milione di chiamate, HTTP API costa $1,00 per milione, oltre al data transfer.<\/p>\n

      Per una PMI con 50 milioni di chiamate al mese su HTTP API si parla di circa $50 di gateway puro pi\u00f9 il traffico. Su REST API gli stessi volumi diventano $175. Aggiungendo CloudWatch logs, X-Ray tracing, WAF rules e Cognito user pools si arriva facilmente a $200-500\/mese per ambienti production. Lo zero-ops ha un prezzo, ma se metti sul piatto i costi nascosti di gestire un cluster Kong (Kubernetes, monitoring, patching, on-call), per volumi piccoli e medi AWS pu\u00f2 essere competitivo.<\/p>\n

      I vantaggi sono evidenti: nessuna infrastruttura da patchare, integrazione nativa con Lambda (proxy integration), Cognito per autenticazione, IAM per autorizzazione machine-to-machine, WAF per protezione applicativa, X-Ray per tracing, CloudWatch per metriche, Step Functions per orchestrazione. Se il backend \u00e8 gi\u00e0 una collezione di Lambda + DynamoDB + S3, AWS API Gateway \u00e8 la scelta obbligata.<\/p>\n

      Lo svantaggio \u00e8 altrettanto evidente: lock-in. La configurazione \u00e8 AWS-specific (Swagger esteso con x-amazon-apigateway-*), i plugin sono limitati a quanto AWS espone, la portabilit\u00e0 verso GCP o Azure \u00e8 praticamente nulla senza una riscrittura completa. Per PMI con strategia multi-cloud o con timore di future migrazioni, questo \u00e8 un fattore bloccante.<\/p>\n

      \"Cloud<\/p>\n

      Confronto tabellare: Kong vs Tyk vs AWS<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
      Dimensione<\/th>\nKong Gateway<\/th>\nTyk<\/th>\nAWS API Gateway<\/th>\n<\/tr>\n<\/thead>\n
      Deployment<\/strong><\/td>\nSelf-hosted \/ Konnect SaaS<\/td>\nSelf-hosted \/ Tyk Cloud SaaS<\/td>\nSolo SaaS AWS<\/td>\n<\/tr>\n
      Linguaggio core<\/strong><\/td>\nLua su NGINX\/OpenResty<\/td>\nGo<\/td>\nProprietario AWS<\/td>\n<\/tr>\n
      Pricing entry<\/strong><\/td>\nOSS gratis, Konnect $250\/user\/mo<\/td>\nOSS gratis, Cloud da $600\/mo<\/td>\n$1-3,50 per milione chiamate<\/td>\n<\/tr>\n
      Latenza overhead<\/strong><\/td>\n2-5 ms<\/td>\n2-4 ms<\/td>\n10-30 ms (region-dependent)<\/td>\n<\/tr>\n
      Plugin ecosystem<\/strong><\/td>\n100+ ufficiali, community ricca<\/td>\nMiddleware nativi, community media<\/td>\nChiuso, no plugin esterni<\/td>\n<\/tr>\n
      Dashboard OSS<\/strong><\/td>\nNo (community Konga\/Manager)<\/td>\nS\u00ec inclusa<\/td>\nAWS Console<\/td>\n<\/tr>\n
      Developer portal<\/strong><\/td>\nEnterprise only<\/td>\nOSS portal community<\/td>\nNo nativo (third-party)<\/td>\n<\/tr>\n
      Observability<\/strong><\/td>\nPrometheus, Datadog, OTEL<\/td>\nPrometheus, Datadog, ELK<\/td>\nCloudWatch, X-Ray<\/td>\n<\/tr>\n
      Multi-cloud<\/strong><\/td>\nS\u00ec, totale<\/td>\nS\u00ec, totale<\/td>\nNo, solo AWS<\/td>\n<\/tr>\n
      Learning curve<\/strong><\/td>\nMedia-alta<\/td>\nMedia<\/td>\nBassa per AWS user, alta altrimenti<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Scegliere in base al contesto PMI<\/h2>\n

      Le decisioni non si prendono leggendo solo le feature matrix. Ecco tre profili tipici di PMI italiana e la scelta consigliata.<\/p>\n

      Profilo A \u2014 SaaS B2B in crescita, 8-12 microservizi su Kubernetes, multi-cloud strategy.<\/strong> L’azienda eroga un software gestionale con API pubbliche consumate da 50 clienti enterprise, ha un team DevOps di 3 persone e un budget cloud di circa 4-6k euro\/mese. Qui Kong Gateway OSS self-hosted \u00e8 la scelta ottimale: portabilit\u00e0 totale, plugin ecosystem ricco, possibilit\u00e0 di estendere in Go o Lua. Si parte gratis con la versione OSS, si aggiunge Konnect o Enterprise solo quando il developer portal e l’RBAC granulare diventano effettivamente bloccanti. Costo realistico: 200-400 euro\/mese di compute Kubernetes per il cluster gateway.<\/p>\n

      Profilo B \u2014 PMI manifatturiera con e-commerce headless, 4-6 servizi, budget contenuto.<\/strong> Team di 2 sviluppatori full-stack, no DevOps dedicato, esigenza di dashboard self-service per partner che consumano API ordini e stock. Qui Tyk OSS \u00e8 il sweet spot: dashboard inclusa, configurazione meno verbosa di Kong, footprint ridotto. Si pu\u00f2 fare partire un cluster a 2 nodi su VPS economici (Hetzner, OVH) per circa 50-80 euro\/mese. Se in futuro emerge il bisogno di multi-region o RBAC, l’upgrade a Tyk Cloud \u00e8 graduale.<\/p>\n

      Profilo C \u2014 Startup serverless full AWS, backend interamente Lambda + DynamoDB.<\/strong> Niente Kubernetes in casa, niente desiderio di averlo. Qui AWS API Gateway HTTP API \u00e8 la scelta obbligata: integrazione nativa con Lambda proxy, Cognito user pools, WAF, X-Ray. Si parte con poche decine di euro\/mese, si scala in modo predicibile. L’unica accortezza \u00e8 isolare la business logic dal binding al gateway: usare schemi OpenAPI standard e una struttura di handler portabile, cos\u00ec che un’eventuale migrazione futura sia ipotizzabile senza riscrittura totale.<\/p>\n

      Sicurezza: OAuth 2.0, JWT, mTLS<\/h2>\n

      La sicurezza \u00e8 il caso d’uso numero uno per cui le PMI introducono un API gateway. Esporre direttamente i microservizi a Internet senza un layer di autenticazione centralizzato \u00e8 un rischio sistemico: ogni servizio implementa la propria validazione, e ogni divergenza \u00e8 un buco potenziale. Il gateway centralizza la validazione del token e passa al backend l’identit\u00e0 gi\u00e0 verificata.<\/p>\n

      I tre pattern dominanti nel 2022 sono: API keys<\/strong> per scenari B2B semplici (chiave statica per partner, rate limit per chiave); JWT bearer tokens<\/strong> firmati da un Identity Provider esterno con chiavi pubbliche distribuite via JWKS endpoint (il gateway valida la firma senza chiamare l’IdP a ogni richiesta); OAuth 2.0 con introspection<\/strong> per scenari che richiedono revoca immediata dei token (il gateway chiama l’IdP per validare a runtime, con caching aggressivo per non saturare). Per traffico machine-to-machine fra servizi interni o partner fidati, mTLS<\/strong> \u00e8 la scelta pi\u00f9 robusta: certificato client validato dal gateway, identit\u00e0 derivata dal subject del certificato.<\/p>\n

      Tutti e tre i gateway supportano questi pattern. Kong lo fa via plugin (key-auth, jwt, oauth2, mtls-auth), Tyk via middleware nativi configurabili da dashboard, AWS via Lambda authorizer custom o integrazione diretta con Cognito. Su mTLS AWS API Gateway ha aggiunto il supporto nel 2020, Kong e Tyk lo offrono da anni. Il vero discriminante \u00e8 la facilit\u00e0 di rotazione dei segreti: Kong e Tyk si integrano con Vault per il key management dinamico, AWS si appoggia a Secrets Manager. Per una PMI con compliance ISO 27001 o requisiti contrattuali su rotazione chiavi ogni 90 giorni, questa integrazione fa la differenza.<\/p>\n

      Service mesh: quando serve davvero<\/h2>\n

      Una domanda ricorrente in fase di scelta \u00e8: ho bisogno anche di un service mesh? La risposta breve: probabilmente no, almeno non subito. Il service mesh (Istio, Linkerd, Kuma) gestisce il traffico est-ovest fra microservizi interni, aggiungendo mTLS automatico, retry policy, circuit breaker, traffic shifting per canary release. \u00c8 una mannaia potente, ma complessa: Istio richiede competenze Kubernetes avanzate e introduce un overhead operativo significativo.<\/p>\n

      Per una PMI con meno di 15 microservizi e traffico interno gestibile, un API gateway perimetrale \u00e8 sufficiente. Il service mesh entra in gioco quando si superano i 30-50 servizi, quando si ha bisogno di policy di rete fine-grained per compliance, quando si fanno deploy canary frequenti. Kong ha la sua proposta integrata (Kong Mesh, basato su Kuma) che semplifica la convivenza fra gateway e mesh con un control plane unico. Tyk si integra con Istio. AWS offre App Mesh, ma con adozione pi\u00f9 limitata rispetto alle alternative open source.<\/p>\n

      \"Team<\/p>\n

      Errori comuni da evitare<\/h2>\n

      Dopo aver visto decine di rollout di API gateway in PMI italiane, ecco i cinque errori che si ripetono pi\u00f9 spesso.<\/p>\n

        \n
      1. Over-engineering iniziale.<\/strong> Partire con un cluster Kong multi-region quando hai 3 microservizi e 50 richieste al minuto \u00e8 un suicidio operativo. Inizia con un nodo, scala quando serve.<\/li>\n
      2. Nessuna strategia di versioning.<\/strong> Esporre \/api\/orders senza \/v1\/ \u00e8 una bomba a orologeria: quando dovrai rompere la retrocompatibilit\u00e0 sarai costretto a forzare tutti i client. Usa \/v1\/ dal primo giorno.<\/li>\n
      3. Logiche di business dentro al gateway.<\/strong> Trasformazioni complesse, orchestration di chiamate multiple, calcoli su payload appartengono ai microservizi (o a un BFF dedicato), non al gateway. Il gateway deve restare sottile.<\/li>\n
      4. Nessuna API governance.<\/strong> Lasciare che ogni team esponga endpoint come vuole, senza naming convention n\u00e9 schemi OpenAPI, porta in 18 mesi a un catalogo ingestibile. Imponi linting OpenAPI in CI fin dal primo endpoint.<\/li>\n
      5. Mancanza di observability.<\/strong> Senza metriche per endpoint (latenza, error rate, traffico), il gateway \u00e8 una scatola nera. Configura Prometheus, Grafana e alerting prima del go-live in produzione, non dopo.<\/li>\n<\/ol>\n

        Roadmap di implementazione 90 giorni<\/h2>\n

        Per una PMI che parte da zero, un rollout sostenibile di API gateway si articola in tre fasi da circa 30 giorni ciascuna.<\/p>\n

        Giorni 1-30 \u2014 Discovery e proof of concept.<\/strong> Inventario degli endpoint esistenti, definizione di naming convention, scrittura degli schemi OpenAPI mancanti. Setup di un ambiente non-production con il gateway scelto, migrazione di 2-3 endpoint pilota. Configurazione di authentication base (API keys o JWT) e rate limiting elementare. Output atteso: gateway funzionante in dev, documentazione OpenAPI per gli endpoint pilota, metriche Prometheus esposte.<\/p>\n

        Giorni 31-60 \u2014 Hardening e migrazione progressiva.<\/strong> Migrazione del 50-70% degli endpoint dietro al gateway, configurazione observability completa (Grafana dashboards, alerting su error rate ed SLO di latenza), definizione di RBAC per il team. Onboarding del primo partner B2B su developer portal. Test di carico per validare capacit\u00e0 del cluster gateway.<\/p>\n

        Giorni 61-90 \u2014 Go-live e governance.<\/strong> Cutover finale in produzione, deprecazione dei vecchi endpoint diretti, pubblicazione del developer portal pubblico. Definizione del processo di API change management (RFC per breaking changes, periodo di deprecation di almeno 6 mesi). Retrospettiva e definizione di SLO\/SLA per ogni API esposta.<\/p>\n

        Come implementare un API gateway in 5 passi<\/h2>\n
          \n
        1. Inventario e schemi OpenAPI<\/strong>: censisci tutti gli endpoint esistenti e produci o aggiorna gli schemi OpenAPI 3.0\/3.1. Senza questa base nessuno strumento ti salver\u00e0.<\/li>\n
        2. Scelta del gateway<\/strong>: applica il framework persona (cloud-agnostic, budget OSS, AWS-native) per filtrare le opzioni, poi prova due candidati su un POC di 2 settimane.<\/li>\n
        3. Setup ambiente non-production<\/strong>: deploy del gateway su staging, integrazione con IdP, configurazione di un primo subset di endpoint pilota.<\/li>\n
        4. Migrazione progressiva<\/strong>: sposta endpoint dietro al gateway in batch settimanali, validando metriche e error rate dopo ogni batch.<\/li>\n
        5. Go-live e governance<\/strong>: cutover produzione con feature flag, deprecation dei vecchi endpoint, processo formale per future API change.<\/li>\n<\/ol>\n

          FAQ \u2014 Risposte alle domande pi\u00f9 frequenti<\/h2>\n

          Posso usare NGINX al posto di un API gateway?<\/h3>\n

          NGINX standalone risolve routing e load balancing, ma non gestisce nativamente OAuth 2.0, rate limiting per consumer, developer portal, observability per endpoint. Per scenari semplici (1-2 servizi, niente auth complessa) pu\u00f2 bastare. Sopra i 5 servizi o con esigenze B2B serie, un API gateway dedicato fa risparmiare mesi di lavoro custom.<\/p>\n

          Kong Konnect vale i $250 per utente al mese?<\/h3>\n

          Konnect ha senso se non vuoi gestire il control plane Kong in casa e hai esigenza di governance multi-team (pi\u00f9 gruppi di sviluppatori che gestiscono API separate). Per team singoli o piccoli, Kong OSS self-hosted resta pi\u00f9 conveniente.<\/p>\n

          Tyk Cloud o Tyk Self Managed?<\/h3>\n

          Tyk Cloud \u00e8 la scelta giusta se non hai un team operations dedicato e accetti latenze leggermente maggiori per la natura SaaS. Self Managed conviene se hai requisiti di data residency stringenti (per esempio, dati che non possono uscire dall’UE) o se vuoi performance ottimali in colocation con il backend.<\/p>\n

          Quanto costa davvero AWS API Gateway?<\/h3>\n

          Per una PMI con 30-50 milioni di chiamate al mese su HTTP API si parla di $30-50 di gateway puro, pi\u00f9 data transfer (variabile, tipicamente $50-150), pi\u00f9 CloudWatch e X-Ray se attivati ($30-80). Conto totale realistico: $150-300\/mese all-inclusive.<\/p>\n

          Posso passare da AWS API Gateway a Kong in futuro?<\/h3>\n

          Tecnicamente s\u00ec, ma il costo \u00e8 proporzionale a quanta logica AWS-specific hai messo nelle configurazioni (Lambda authorizer, integrations dirette con servizi AWS, schemi Swagger estesi). Se mantieni schemi OpenAPI standard e handler Lambda portabili, la migrazione \u00e8 fattibile in 2-3 mesi. Altrimenti \u00e8 una riscrittura.<\/p>\n

          Serve un API gateway anche per API solo interne?<\/h3>\n

          Se le API sono consumate solo da altri microservizi interni e non hai esigenze di rate limiting o auth centralizzata, un service mesh pu\u00f2 bastare. Il gateway diventa necessario quando l’API \u00e8 esposta verso client esterni o quando vuoi un unico punto di policy enforcement.<\/p>\n

          Quanto tempo serve per il rollout in una PMI?<\/h3>\n

          Con un team di 2-3 sviluppatori e un perimetro di 10-15 endpoint, una roadmap realistica \u00e8 60-90 giorni dal POC al go-live, includendo definizione di OpenAPI mancanti, setup observability, migrazione progressiva e onboarding del developer portal. Tempi inferiori sono possibili solo se gli schemi OpenAPI sono gi\u00e0 completi e maturi.<\/p>\n

          \n

          Stai valutando un API gateway per la tua azienda?<\/h3>\n

          Brentasoft affianca PMI italiane nella scelta architetturale, nel POC e nel rollout di Kong, Tyk e AWS API Gateway. Richiedi un preventivo per il tuo progetto: ti rispondiamo entro 24 ore con stima oraria, roadmap e budget cloud realistico.<\/p>\n

          Richiedi un preventivo<\/a><\/p>\n<\/div>\n