Esperti Google Cloud Freelance Italiani

In cosa Google Cloud è diverso dagli altri due?

Sulle fondamenta i tre cloud si somigliano molto. Le differenze percepibili riguardano due ambiti e un aspetto di metodo.

Container: Kubernetes è nato in Google e la piattaforma ha una lunga esperienza su questo terreno. Cloud Run in particolare permette di pubblicare un container senza gestire alcun server, ed è spesso la via più rapida per mettere online un'applicazione.
Dati e analisi: BigQuery è il servizio che più spesso porta le aziende su questa piattaforma: interroga volumi molto grandi senza infrastruttura da dimensionare.
Il contesto aziendale: se usi già Google Workspace, Google Analytics e Google Ads, i dati e le identità si incastrano con meno lavoro.

Il criterio più onesto resta chi manterrà il sistema: la piattaforma che il tuo fornitore conosce bene batte quella teoricamente più adatta.

Cloud Run o Kubernetes: cosa scegliere?

È la domanda più utile che puoi fare in un progetto Google Cloud, perché la risposta cambia i costi di gestione per anni.

Cloud Run conviene quando: hai una o poche applicazioni in container e vuoi che qualcun altro si occupi di tutto il resto. Scala da sola, si paga l'uso e non c'è un cluster da mantenere. Per la maggior parte delle PMI è la scelta giusta.
Kubernetes gestito conviene quando: i servizi sono molti e interconnessi, servono configurazioni particolari di rete o di risorse, o esiste già una competenza interna sulla piattaforma.
Il segnale di sovradimensionamento: un cluster con dentro due applicazioni. Costa in canone e soprattutto in attenzione continua.

BigQuery serve solo alle grandi aziende?

No, e l'equivoco nasce dal fatto che viene raccontato con esempi da miliardi di righe. Il criterio vero è la struttura del problema, non la dimensione dell'azienda.

Quando ha senso: devi unire dati che oggi stanno in posti diversi — gestionale, e-commerce, campagne pubblicitarie, analisi del sito — e interrogarli insieme senza rallentare i sistemi di produzione.
Quando non serve: se i dati stanno in un database aziendale e le analisi girano in tempi accettabili, aggiungere un altro sistema è complessità inutile.
Attenzione al modello di costo: si paga in base ai dati esaminati dalle interrogazioni. Query scritte male su tabelle grandi costano, ed è per questo che conviene farsi impostare bene la struttura all'inizio.

Se l'obiettivo è un cruscotto per la direzione, la domanda da porsi prima è quale decisione deve supportare: spesso la risposta ridimensiona il progetto e lo rende fattibile.

Dove finiscono i nostri dati e come stiamo con il GDPR?

Gli strumenti per essere conformi ci sono; la responsabilità del titolare del trattamento resta comunque tua, e alcune scelte vanno fatte all'inizio perché dopo sono costose da cambiare.

La regione va scelta: le risorse si creano in una regione specifica, europee comprese. È una decisione esplicita, non un'impostazione predefinita da dare per buona.
Identità e permessi: vanno dati per ruolo e limitati al necessario. L'errore classico è concedere permessi ampi «per non avere problemi» e lasciarli lì per anni.
Registri di accesso: da attivare e conservare secondo le tue policy.
Contratto sul trattamento dei dati: da sottoscrivere e archiviare.

Quanto costa e come si evitano sorprese?

Con le stesse tre precauzioni che valgono per ogni cloud, più una specifica di questa piattaforma.

Budget e allarmi: vanno impostati prima di accendere le risorse, con notifiche a soglie intermedie.
Etichette sulle risorse: per sapere quale progetto o cliente genera quale spesa.
Spegnere gli ambienti di prova: la voce di risparmio più semplice e più trascurata.
La specificità da conoscere: i servizi che si pagano a consumo — le analisi e le applicazioni che scalano da sole — possono generare costi improvvisi se qualcosa va in ciclo. Vanno protetti con limiti massimi, non solo sorvegliati.

Una revisione della spesa da parte di un consulente richiede pochi giorni e in genere si ripaga entro i primi mesi.