Co to jest Google Cloud i jak działa chmura Google?

Google Cloud to platforma usług chmurowych Google pozwalająca firmom, programistom i administratorom korzystać przez internet z infrastruktury obliczeniowej, przestrzeni na dane, baz danych, narzędzi analitycznych, usług sieciowych, kontenerów, systemów sztucznej inteligencji i wielu innych zasobów.

Najprościej można powiedzieć:

zamiast kupować i utrzymywać własne serwery, można wynajmować potrzebne zasoby w centrach danych Google i uruchamiać je wtedy, kiedy są potrzebne.

Może to oznaczać:

• jeden niewielki serwer dla aplikacji,
• bazę danych dla sklepu internetowego,
• magazyn na miliony plików,
• system przetwarzający ogromne ilości danych,
• infrastrukturę działającą równolegle w kilku regionach świata.

Słowo „cloud”, czyli chmura, może sugerować coś niematerialnego.

W rzeczywistości za usługami chmurowymi stoją bardzo fizyczne:

• serwery,
• dyski,
• routery,
• łącza światłowodowe,
• centra danych.

Różnica polega na tym, że klient nie musi samodzielnie kupować, instalować i utrzymywać całej tej infrastruktury.

Co to jest cloud computing?

Cloud computing, czyli przetwarzanie w chmurze, to model dostarczania zasobów informatycznych jako usług dostępnych przez sieć.

Zamiast posiadać fizyczny serwer stojący w biurze lub własnej serwerowni, firma może uruchomić w chmurze potrzebną moc obliczeniową.

Zamiast kupować macierz dyskową, może korzystać z magazynu obiektowego.

Zamiast samodzielnie instalować klaster bazy danych, może użyć zarządzanej usługi bazodanowej.

Kluczowe cechy tego modelu to:

• uruchamianie zasobów na żądanie,
• możliwość szybkiego zwiększania i zmniejszania skali,
• rozliczanie na podstawie wykorzystania albo wybranej konfiguracji,
• zarządzanie infrastrukturą przez panel, API lub kod.

Google Cloud czy Google Cloud Platform?

Można spotkać zarówno określenie Google Cloud, jak i skrót GCP oznaczający Google Cloud Platform.

W codziennej rozmowie oba określenia bywają używane zamiennie w odniesieniu do infrastruktury i usług chmurowych Google.

Google Cloud jest jednak szerszą nazwą ekosystemu usług chmurowych Google.

Dla osoby chcącej uruchomić aplikację najważniejsze jest przede wszystkim to, jakie konkretne zasoby są potrzebne:

• serwer,
• baza danych,
• storage,
• sieć,
• kontenery,
• analityka.

Sama nazwa platformy jest mniej istotna niż właściwa architektura.

Jak działa Google Cloud?

Google posiada centra danych i infrastrukturę rozmieszczoną w wielu lokalizacjach.

Użytkownik tworzy konto i projekt, a następnie uruchamia potrzebne usługi.

Może na przykład utworzyć:

• maszynę wirtualną,
• bazę danych,
• bucket na pliki,
• aplikację serverless,
• klaster Kubernetes.

Zasoby są następnie połączone odpowiednią siecią i otrzymują określone uprawnienia.

Całość można zarządzać:

• przez panel internetowy,
• z linii poleceń,
• przez API,
• za pomocą Infrastructure as Code.

Co to jest projekt w Google Cloud?

Projekt jest jednym z podstawowych sposobów organizowania zasobów.

Można traktować go jak logiczny kontener dla:

• serwerów,
• baz danych,
• API,
• uprawnień,
• rozliczeń.

Firma może posiadać osobne projekty dla:

• produkcji,
• środowiska testowego,
• konkretnej aplikacji,
• różnych działów.

Dobry podział projektów pomaga później kontrolować:

• dostępy,
• koszty,
• bezpieczeństwo,
• odpowiedzialność.

Google Cloud a zwykły hosting

Dla osoby prowadzącej stronę internetową pierwsze pytanie często brzmi:

Czym różni się Google Cloud od hostingu?

Klasyczny hosting dostarcza zazwyczaj gotowe środowisko.

Klient otrzymuje:

• określoną przestrzeń,
• panel administracyjny,
• PHP,
• bazę danych,
• pocztę,
• często również backup.

Dużą częścią infrastruktury zajmuje się dostawca hostingu.

Google Cloud daje znacznie większą elastyczność, ale często wymaga również większej wiedzy.

Można samodzielnie zdecydować:

• ile procesorów ma posiadać serwer,
• ile pamięci potrzebuje,
• w jakim regionie działa,
• jaką sieć wykorzystuje,
• jak komunikuje się z bazą,
• jak skalować aplikację.

Czy Google Cloud jest lepsze od hostingu?

Nie istnieje uniwersalna odpowiedź.

Dla prostej strony firmowej dobry zarządzany hosting może być:

• tańszy,
• prostszy,
• łatwiejszy w utrzymaniu.

Google Cloud zaczyna pokazywać swoją przewagę szczególnie wtedy, gdy projekt wymaga:

• nietypowej infrastruktury,
• dużej skali,
• automatycznego skalowania,
• wielu usług współpracujących ze sobą,
• zaawansowanego przetwarzania danych,
• dużej kontroli nad środowiskiem.

Używanie chmury tylko dlatego, że „cloud brzmi nowocześnie”, nie jest dobrym argumentem architektonicznym.

Co to jest Compute Engine?

Compute Engine pozwala tworzyć maszyny wirtualne.

To jedna z najbardziej klasycznych usług cloud computing.

Można uruchomić wirtualny serwer posiadający określoną:

• liczbę procesorów,
• ilość RAM,
• przestrzeń dyskową,
• konfigurację sieciową.

Następnie można zainstalować na nim potrzebne oprogramowanie.

Z perspektywy administratora przypomina to pracę z klasycznym VPS-em.

Różnica polega na integracji z całą platformą chmurową.

Maszyna wirtualna nie jest fizycznym serwerem

Maszyna wirtualna działa na fizycznej infrastrukturze dostawcy, ale użytkownik otrzymuje logicznie wydzielone środowisko.

Może posiadać własny:

• system operacyjny,
• adres IP,
• dyski,
• konfigurację.

Nie musi jednak wiedzieć, w której konkretnej szafie serwerowej znajduje się fizyczny komputer obsługujący tę maszynę.

Czy można uruchomić WordPressa w Google Cloud?

Tak.

WordPress może działać na maszynie wirtualnej tak samo jak na klasycznym serwerze.

Trzeba jednak pamiętać, że samo uruchomienie WordPressa to dopiero początek.

Ktoś musi nadal zadbać o:

• system operacyjny,
• serwer WWW,
• PHP,
• bazę,
• backup,
• bezpieczeństwo,
• aktualizacje,
• monitoring.

Dlatego niewielka strona WordPress nie zawsze potrzebuje Google Cloud.

Dobry hosting zarządzany może być dla niej znacznie bardziej praktyczny.

Co to jest Cloud Run?

Cloud Run pozwala uruchamiać aplikacje znajdujące się w kontenerach bez samodzielnego zarządzania klasycznym serwerem.

Programista przygotowuje aplikację i jej kontener.

Platforma zajmuje się dużą częścią infrastruktury potrzebnej do uruchomienia tego kontenera.

Może automatycznie zwiększać liczbę instancji, gdy pojawia się większy ruch, i zmniejszać ją, gdy zapotrzebowanie spada.

To bardzo dobry przykład modelu serverless.

Co właściwie oznacza serverless?

Nazwa może być myląca.

Serverless nie oznacza, że serwery przestały istnieć.

Serwery nadal są potrzebne.

Różnica polega na tym, że programista nie zarządza nimi bezpośrednio.

Nie musi tworzyć konkretnej maszyny wirtualnej, pilnować jej systemu operacyjnego i ręcznie zwiększać liczby serwerów.

Skupia się przede wszystkim na aplikacji.

Dostawca chmury zarządza większą częścią infrastruktury.

Serverless a klasyczny serwer

Na klasycznej maszynie wirtualnej płacimy za uruchomiony zasób i sami nim administrujemy.

W modelu serverless sposób naliczania kosztów może być silniej związany z rzeczywistym wykonywaniem aplikacji i używanymi zasobami.

Może to być szczególnie atrakcyjne przy systemach, które:

• mają nierówny ruch,
• wykonują zadania okresowo,
• obsługują API,
• reagują na zdarzenia.

Co to są kontenery?

Kontener jest sposobem pakowania aplikacji razem z potrzebnymi jej zależnościami.

Dzięki temu ten sam pakiet może działać w różnych środowiskach w bardziej przewidywalny sposób.

Popularnym standardem są kontenery Docker.

Można w nich umieścić:

• aplikację,
• środowisko uruchomieniowe,
• biblioteki,
• konfigurację potrzebną do startu.

Kontenery stały się jednym z fundamentów nowoczesnej infrastruktury chmurowej.

Co to jest Kubernetes?

Kubernetes służy do zarządzania dużą liczbą kontenerów.

Potrafi między innymi:

• uruchamiać aplikacje,
• pilnować liczby instancji,
• restartować uszkodzone elementy,
• skalować system,
• zarządzać wdrożeniami.

Google oferuje usługę Google Kubernetes Engine, czyli GKE.

Kubernetes daje ogromne możliwości.

Nie oznacza to jednak, że każda aplikacja powinna go używać.

Nie każda firma potrzebuje Kubernetes

To jeden z dobrych przykładów technologii, która może rozwiązać ogromne problemy i jednocześnie stworzyć niepotrzebną złożoność w małym projekcie.

Jeżeli aplikacja składa się z jednego niewielkiego backendu, użycie pełnego klastra Kubernetes może być przerostem formy nad treścią.

Architektura powinna wynikać z potrzeb.

Nie z popularności technologii.

Co to jest Cloud Storage?

Cloud Storage jest usługą przechowywania obiektów.

Można umieszczać w niej między innymi:

• obrazy,
• filmy,
• backupy,
• dokumenty,
• pliki generowane przez aplikację.

Dane są przechowywane w tak zwanych bucketach.

Nie należy mylić takiego magazynu z tradycyjnym dyskiem serwera.

To inny model przechowywania danych.

Bucket a folder na serwerze

Na zwykłym serwerze plik może znajdować się na dysku pod określoną ścieżką.

Storage obiektowy działa inaczej.

Obiekt posiada:

• nazwę,
• dane,
• metadane.

Dzięki temu system może przechowywać ogromne ilości plików bez konieczności zarządzania klasycznym systemem plików w taki sam sposób jak na pojedynczej maszynie.

Do czego wykorzystuje się Cloud Storage?

Przykładowe zastosowania to:

• archiwizacja danych,
• backup,
• przechowywanie plików użytkowników,
• materiały multimedialne,
• eksporty systemowe.

Może również być elementem większej architektury aplikacji.

Serwer przetwarza dane, a pliki trafiają do osobnego magazynu obiektowego.

Google Cloud a bazy danych

Nowoczesna aplikacja zwykle potrzebuje nie tylko serwera.

Potrzebuje również miejsca na dane strukturalne.

Google Cloud oferuje różne rodzaje baz danych przeznaczonych do różnych zastosowań.

Można korzystać z:

• relacyjnych baz SQL,
• baz NoSQL,
• rozwiązań dla bardzo dużej skali,
• hurtowni danych.

Nie istnieje jedna baza najlepsza do wszystkiego.

Co to jest Cloud SQL?

Cloud SQL jest zarządzaną usługą relacyjnych baz danych.

Zamiast samodzielnie instalować silnik bazy na własnej maszynie, można korzystać z usługi, w której częścią operacji infrastrukturalnych zajmuje się Google.

Może to ograniczać ilość pracy związanej z:

• konfiguracją,
• aktualizacjami,
• backupami,
• wysoką dostępnością.

Nadal trzeba jednak prawidłowo projektować:

• strukturę danych,
• zapytania,
• indeksy,
• uprawnienia.

Usługa zarządzana nie oznacza usługi bezobsługowej

To ważna zasada całej chmury.

Dostawca może przejąć część obowiązków infrastrukturalnych.

Nie oznacza to, że aplikacja sama stanie się:

• wydajna,
• bezpieczna,
• dobrze zaprojektowana.

Jeżeli program wykonuje fatalnie napisane zapytania do bazy, przeniesienie go do Google Cloud nie naprawi automatycznie problemu.

Co to jest BigQuery?

BigQuery jest usługą przeznaczoną do analizy dużych zbiorów danych.

Może pełnić rolę hurtowni danych i pozwalać wykonywać zapytania obejmujące bardzo duże ilości informacji.

Przykładowo firma może łączyć dane z:

• sprzedaży,
• marketingu,
• aplikacji,
• systemów wewnętrznych.

Następnie może analizować je w jednym środowisku.

BigQuery nie jest po prostu większą bazą dla WordPressa

To zupełnie inny typ zastosowania.

WordPress potrzebuje bazy obsługującej bieżące operacje aplikacji.

Hurtownia danych jest projektowana przede wszystkim z myślą o analizie.

Można więc mieć:

system operacyjny → eksport danych → BigQuery → raportowanie.

Każdy element pełni inną funkcję.

Google Cloud a analityka

Chmura jest szczególnie użyteczna wtedy, gdy firma posiada dane w wielu miejscach.

Można budować procesy, które:

1. pobierają dane z różnych źródeł,
2. oczyszczają je,
3. łączą,
4. przechowują,
5. udostępniają do analizy.

To podstawa wielu systemów Business Intelligence.

Co to jest ETL?

ETL oznacza:

• Extract – pobierz dane,
• Transform – przekształć je,
• Load – załaduj do miejsca docelowego.

Przykładowo firma może:

1. pobrać zamówienia z systemu sprzedażowego,
2. ujednolicić format danych,
3. zapisać je w hurtowni.

W środowisku chmurowym takie procesy można automatyzować i skalować.

Google Cloud a API

Większość usług chmurowych może być zarządzana programowo.

API pozwala aplikacji komunikować się z usługami bez ręcznego klikania w panelu.

Przykładowo program może automatycznie:

• zapisać plik,
• uruchomić zadanie,
• odczytać dane,
• utworzyć zasób,
• wysłać komunikat.

Dzięki temu chmura dobrze pasuje do systemów integracyjnych i automatyzacyjnych.

Google Cloud a automatyzacja procesów

Chmura może pełnić rolę infrastruktury łączącej różne systemy.

Przykładowo:

sklep → API → usługa chmurowa → ERP.

Albo:

formularz → przetworzenie danych → CRM → powiadomienie.

Przy projektowaniu automatyzacji procesów sama technologia chmurowa jest jednak tylko jednym z elementów. Najpierw trzeba ustalić, co rzeczywiście powinno wydarzyć się pomiędzy systemami i gdzie znajduje się źródło prawidłowych danych.

Co to jest Pub/Sub?

W systemach składających się z wielu elementów przydatny jest model komunikacji oparty na wiadomościach.

Usługa Pub/Sub pozwala tworzyć mechanizm, w którym jeden element publikuje zdarzenie, a inne mogą je odebrać.

Przykład:

zamówienie zostało utworzone.

Na takie zdarzenie mogą zareagować niezależnie:

• system magazynowy,
• moduł fakturowania,
• system powiadomień.

Nie każdy element musi być bezpośrednio połączony z każdym innym.

Architektura oparta na zdarzeniach

Event-driven architecture polega na tym, że system reaguje na zdarzenia.

Zamiast ciągle pytać:

Czy pojawiło się nowe zamówienie?

system otrzymuje informację:

Nowe zamówienie właśnie powstało.

To może znacząco upraszczać niektóre integracje.

Google Cloud a mikroserwisy

Dużą aplikację można czasami podzielić na mniejsze usługi.

Jedna odpowiada za:

• użytkowników,
• inna za płatności,
• kolejna za generowanie dokumentów.

Taką architekturę określa się często jako mikroserwisową.

Chmura dobrze wspiera podobny model.

Nie oznacza to jednak, że każdy system powinien zostać podzielony na dziesiątki mikroserwisów.

Monolit też może być dobrym rozwiązaniem

Jedna dobrze zaprojektowana aplikacja może być znacznie prostsza w:

• wdrożeniu,
• debugowaniu,
• utrzymaniu.

Rozbijanie małego systemu na kilkanaście usług może stworzyć więcej problemów niż korzyści.

Chmura daje możliwości.

Nie nakazuje jednej architektury.

Co to są regiony Google Cloud?

Zasoby chmurowe działają w określonych lokalizacjach geograficznych.

Region reprezentuje większy obszar infrastruktury.

Wybór regionu może wpływać na:

• opóźnienia,
• dostępność usług,
• koszt,
• miejsce przetwarzania danych.

Jeżeli większość użytkowników aplikacji znajduje się w Europie, lokalizacja infrastruktury na innym kontynencie nie zawsze będzie najlepszym wyborem.

Co to są strefy dostępności?

Region może być podzielony na strefy.

Dzięki temu można projektować system tak, aby awaria pojedynczej lokalizacji nie musiała oznaczać niedostępności całej aplikacji.

Przykładowo usługa może posiadać komponenty uruchomione w kilku strefach.

To zwiększa odporność.

Jednocześnie zwiększa złożoność i może podnosić koszt.

Wysoka dostępność nie powstaje sama

To kolejny częsty mit chmurowy.

Uruchomienie pojedynczej maszyny w Google Cloud nie sprawia automatycznie, że aplikacja staje się odporna na każdą awarię.

Trzeba zaprojektować:

• redundancję,
• load balancing,
• bazę danych,
• backup,
• procedury awaryjne.

Cloud daje narzędzia do tworzenia wysokiej dostępności.

Nie zastępuje architektury.

Co to jest load balancing?

Load balancer rozdziela ruch pomiędzy kilka instancji aplikacji.

Zamiast wysyłać wszystkie żądania do jednego serwera, system może kierować je do wielu.

Ma to znaczenie przy:

• dużym ruchu,
• skalowaniu,
• wysokiej dostępności.

Jeżeli jedna instancja przestaje działać, ruch może zostać skierowany do innych zdrowych elementów.

Co to jest autoscaling?

Autoscaling oznacza automatyczne dostosowywanie liczby lub wielkości zasobów do aktualnego zapotrzebowania.

Wyobraźmy sobie aplikację, która zazwyczaj obsługuje 100 użytkowników, ale podczas kampanii pojawia się ich 20 000.

W klasycznym modelu trzeba wcześniej przygotować infrastrukturę na szczytowy ruch.

W chmurze część systemów może zwiększać skalę automatycznie.

Gdy ruch spada, nadmiar zasobów może zostać wyłączony.

Autoscaling nie naprawi każdej aplikacji

Jeżeli wąskim gardłem jest:

• źle napisana baza,
• zewnętrzne API,
• blokujący proces,

dołożenie kolejnych serwerów nie musi pomóc.

Skalowanie trzeba projektować dla całego systemu.

Skalowanie pionowe i poziome

Skalowanie pionowe oznacza zwiększenie mocy jednej maszyny.

Na przykład:

• więcej RAM,
• więcej CPU.

Skalowanie poziome polega na uruchomieniu większej liczby instancji.

Oba modele mają zastosowanie.

Nie każdą aplikację można łatwo skalować poziomo bez wcześniejszego przygotowania architektury.

Google Cloud a sieć

Usługi chmurowe muszą komunikować się ze sobą oraz z internetem.

Dlatego ogromną częścią platformy jest infrastruktura sieciowa.

Można tworzyć:

• sieci prywatne,
• reguły firewall,
• load balancery,
• połączenia pomiędzy środowiskami.

Nie każdy serwer musi być bezpośrednio dostępny z publicznego internetu.

Co to jest VPC?

VPC, czyli Virtual Private Cloud, to logiczna sieć pozwalająca organizować komunikację pomiędzy zasobami.

Można traktować ją jak prywatną warstwę sieciową stworzoną wewnątrz infrastruktury chmurowej.

W niej można kontrolować:

• adresację,
• ruch,
• reguły dostępu,
• połączenia z innymi sieciami.

Publiczny adres IP nie powinien być domyślną odpowiedzią na wszystko

Jeżeli baza danych ma komunikować się tylko z backendem, nie musi być otwarta dla całego internetu.

Im mniej niepotrzebnie publicznych usług, tym mniejsza powierzchnia ataku.

Bezpieczeństwo warto projektować od architektury sieciowej, a nie dopiero po wdrożeniu.

Co to jest IAM?

IAM, czyli Identity and Access Management, służy do zarządzania tożsamościami i uprawnieniami.

Pozwala określić:

kto może zrobić co z konkretnym zasobem.

Jedna osoba może posiadać możliwość tylko odczytu danych.

Inna może zarządzać serwerami.

Aplikacja może otrzymać dostęp tylko do jednego bucketu.

To znacznie bezpieczniejsze niż rozdawanie wszystkim pełnych uprawnień administratora.

Zasada najmniejszych uprawnień w chmurze

Podstawowa reguła brzmi:

użytkownik lub system powinien posiadać tylko takie uprawnienia, jakie są rzeczywiście potrzebne.

Jeżeli aplikacja ma jedynie odczytywać pliki, nie powinna posiadać możliwości:

• usuwania całego projektu,
• tworzenia nowych administratorów,
• zmiany rozliczeń.

Service account – konto dla aplikacji

Nie tylko ludzie potrzebują dostępu do zasobów.

Usługi również komunikują się między sobą.

Do tego wykorzystuje się tożsamości przeznaczone dla aplikacji.

Dzięki nim można dokładnie określić, co dany komponent systemu może zrobić.

Najgorszy model: jeden wspólny administrator dla wszystkiego

W małych projektach można czasami zobaczyć sytuację, w której:

• wszyscy znają jedno hasło,
• każdy ma pełne uprawnienia,
• nie wiadomo, kto wykonał zmianę.

W środowisku chmurowym taki model jest szczególnie niebezpieczny.

Zakres możliwych operacji jest ogromny.

Google Cloud a bezpieczeństwo

Google zabezpiecza swoją infrastrukturę.

Klient nadal odpowiada jednak za dużą część konfiguracji własnego środowiska.

Może samodzielnie popełnić błąd, na przykład:

• udostępnić dane publicznie,
• nadać zbyt szerokie uprawnienia,
• pozostawić otwarty port administracyjny,
• umieścić sekret w kodzie źródłowym.

Samo używanie Google Cloud nie gwarantuje bezpieczeństwa aplikacji.

Model współdzielonej odpowiedzialności

W chmurze odpowiedzialność jest dzielona pomiędzy dostawcę i klienta.

Dostawca odpowiada za określone warstwy infrastruktury.

Klient odpowiada między innymi za sposób:

• konfiguracji usług,
• zarządzania użytkownikami,
• przechowywania sekretów,
• zabezpieczania aplikacji.

Dokładny podział zależy od rodzaju używanej usługi.

IaaS, PaaS i SaaS – czym się różnią?

Usługi chmurowe często dzieli się na kilka modeli.

IaaS

Infrastructure as a Service dostarcza podstawową infrastrukturę.

Przykładem może być maszyna wirtualna.

Klient ma dużą kontrolę, ale również dużą odpowiedzialność.

PaaS

Platform as a Service daje bardziej zarządzane środowisko do uruchamiania aplikacji.

Klient mniej zajmuje się samym serwerem.

SaaS

Software as a Service to gotowe oprogramowanie dostarczane jako usługa.

Użytkownik korzysta z aplikacji zamiast budować jej infrastrukturę.

Im wyższy poziom usługi, tym mniej infrastruktury do zarządzania

To dobre uproszczenie.

Maszyna wirtualna daje ogromną swobodę, ale trzeba o nią dbać.

Zarządzana usługa przejmuje część tej pracy.

Gotowa aplikacja SaaS przejmuje jeszcze więcej.

W zamian użytkownik posiada coraz mniej kontroli nad szczegółami technicznymi.

Nie zawsze większa kontrola jest zaletą

Jeżeli firma potrzebuje zwykłej poczty, nie musi budować własnego serwera pocztowego tylko dlatego, że wtedy „ma pełną kontrolę”.

Kontrola oznacza również:

• odpowiedzialność,
• utrzymanie,
• monitoring,
• bezpieczeństwo.

W wielu przypadkach lepsza jest usługa bardziej zarządzana.

Google Cloud a backup

Chmura daje wiele narzędzi do tworzenia kopii danych.

Nie oznacza to jednak automatycznie, że każdy zasób posiada idealny backup.

Trzeba zaprojektować:

• co kopiujemy,
• jak często,
• jak długo przechowujemy kopie,
• jak wygląda odtwarzanie.

Backup, którego nigdy nie próbowano odtworzyć, jest tylko teorią.

Snapshot a backup

Snapshot może być bardzo przydatny, ale nie zawsze powinien być jedyną kopią bezpieczeństwa.

Jeżeli wszystkie kopie znajdują się w tym samym koncie i osoba posiadająca pełne uprawnienia usunie cały projekt, można stracić również część zabezpieczeń.

Dla krytycznych danych warto projektować backup z myślą również o takich scenariuszach.

Google Cloud a disaster recovery

Disaster recovery określa sposób odtworzenia działania po poważnej awarii.

Plan może odpowiadać na pytania:

• co się stanie, gdy padnie region,
• jak odtworzyć bazę,
• ile danych możemy stracić,
• jak długo system może być niedostępny.

Dwa ważne pojęcia to RPO i RTO.

Co to jest RPO?

RPO określa akceptowalną utratę danych wyrażoną w czasie.

Jeżeli RPO wynosi godzinę, organizacja akceptuje możliwość utraty maksymalnie około godziny ostatnich danych w określonym scenariuszu awaryjnym.

Co to jest RTO?

RTO określa, jak szybko system powinien zostać przywrócony.

Dla jednego serwisu może to być:

24 godziny.

Dla krytycznego systemu:

kilka minut.

Im bardziej restrykcyjne wymagania, tym zazwyczaj droższa infrastruktura.

Google Cloud a monitoring

System produkcyjny powinien być obserwowany.

Nie wystarczy sprawdzić raz dziennie, czy strona się otwiera.

Warto mierzyć między innymi:

• użycie CPU,
• pamięć,
• liczbę błędów,
• czas odpowiedzi,
• dostępność.

Na podstawie takich danych można tworzyć alerty.

Logi są jednym z najważniejszych źródeł diagnostycznych

Gdy system zgłasza błąd, trzeba wiedzieć, co wydarzyło się wcześniej.

Log może pokazać:

• żądanie,
• komunikat błędu,
• czas wystąpienia,
• komponent odpowiedzialny za problem.

Przy systemach rozproszonych centralne zbieranie logów jest szczególnie wartościowe.

Observability to coś więcej niż monitoring

W nowoczesnych systemach mówi się szerzej o observability, czyli obserwowalności.

Łączy się:

• metryki,
• logi,
• trace,
• zdarzenia.

Celem jest możliwość zrozumienia, co dzieje się wewnątrz systemu na podstawie jego zachowania.

Google Cloud i sztuczna inteligencja

Google Cloud oferuje również infrastrukturę i usługi związane z uczeniem maszynowym oraz AI.

Można budować systemy wykorzystujące modele do:

• analizy danych,
• przetwarzania tekstu,
• analizy obrazów,
• automatyzacji wybranych procesów.

Nie oznacza to jednak, że do każdego projektu należy dodawać AI.

Technologia powinna rozwiązywać konkretny problem.

AI nie jest powodem, żeby migrować wszystko do chmury

Firma może potrzebować jednej konkretnej usługi AI, ale pozostała część infrastruktury może działać gdzie indziej.

Nowoczesne systemy bardzo często są hybrydowe.

Nie wszystko musi znajdować się u jednego dostawcy.

Co to jest hybrid cloud?

Hybrid cloud oznacza środowisko łączące różne rodzaje infrastruktury.

Przykładowo firma może posiadać:

• własne serwery,
• część zasobów w Google Cloud,
• zewnętrzne aplikacje SaaS.

Systemy współpracują ze sobą przez sieć i API.

Co to jest multi-cloud?

Multi-cloud oznacza korzystanie z usług więcej niż jednego dostawcy chmurowego.

Firma może na przykład używać jednej platformy do głównej aplikacji, a innej do określonych usług.

Może to zmniejszać zależność od jednego dostawcy.

Jednocześnie zwiększa złożoność.

Vendor lock-in w chmurze

Im więcej bardzo specyficznych usług konkretnego dostawcy wykorzystuje aplikacja, tym trudniejsze może być późniejsze przeniesienie jej gdzie indziej.

To właśnie jedna z form vendor lock-in.

Nie oznacza to, że należy unikać usług natywnych.

Często to właśnie one dają największe korzyści.

Trzeba jednak świadomie wiedzieć, jaki koszt migracji tworzymy.

Kontener nie gwarantuje pełnej przenośności

Czasami słyszy się:

Mamy Dockera, więc możemy przenieść się wszędzie.

Sam kontener aplikacji może być przenośny.

Ale system może jednocześnie korzystać z:

• konkretnej bazy,
• kolejek,
• storage,
• IAM,
• usług analitycznych.

Pełna migracja nadal może wymagać dużo pracy.

Jak działa rozliczanie Google Cloud?

Chmura nie ma jednej ceny.

Koszt zależy od używanych usług oraz ich konfiguracji.

Można płacić między innymi za:

• czas pracy maszyn,
• liczbę używanych procesorów,
• pamięć,
• przechowywanie danych,
• operacje,
• transfer sieciowy.

To ogromna zaleta.

Może być również jednym z największych zagrożeń.

Cloud nie zawsze jest tańszy

To bardzo częsty mit.

Dobrze zaprojektowana chmura może być ekonomiczna.

Źle zaprojektowana może kosztować znacznie więcej niż klasyczna infrastruktura.

Przykładowo firma może:

• uruchomić za duże maszyny,
• nie wyłączać środowisk testowych,
• przechowywać niepotrzebne dane,
• generować ogromny transfer.

Po miesiącu rachunek potrafi zaskoczyć.

Największa zaleta chmury to nie zawsze cena

Często ważniejsze są:

• elastyczność,
• szybkość uruchamiania zasobów,
• skalowalność,
• dostęp do zarządzanych usług.

Firma może zapłacić więcej za jednostkę zasobu, ale jednocześnie nie musi:

• kupować sprzętu,
• utrzymywać serwerowni,
• czekać tygodniami na nowe serwery.

CAPEX i OPEX

Klasyczna infrastruktura często wymaga dużej inwestycji początkowej.

To CAPEX.

Chmura pozwala przesunąć część kosztu w stronę bieżącego wykorzystania.

To OPEX.

Zamiast kupować serwery na kilka lat, firma płaci za usługę.

Nie oznacza to automatycznie niższego kosztu całkowitego.

Zmienia model finansowania infrastruktury.

Koszt transferu danych

W chmurze trzeba zwracać uwagę nie tylko na procesor i dyski.

Znaczenie ma również ruch sieciowy.

Duże ilości danych przesyłanych pomiędzy:

• regionami,
• usługami,
• chmurą i internetem

mogą generować koszt.

Architektura powinna uwzględniać przepływ danych od początku.

FinOps – zarządzanie kosztami chmury

W większych organizacjach powstała nawet osobna praktyka określana jako FinOps.

Łączy ona:

• technologię,
• finanse,
• zarządzanie.

Celem jest świadome kontrolowanie ekonomiki infrastruktury chmurowej.

Nie wystarczy wiedzieć, że system działa.

Trzeba również wiedzieć, ile kosztuje jego działanie i dlaczego.

Budżety i alerty kosztowe

Jedną z pierwszych rzeczy, które warto skonfigurować, są mechanizmy kontroli wydatków.

Można ustawić:

• budżet,
• alerty,
• monitorowanie trendów.

To nie zastępuje optymalizacji, ale pozwala wcześniej zauważyć nietypowy wzrost kosztu.

Najczęstszy błąd: uruchomić i zapomnieć

W chmurze bardzo łatwo utworzyć nowy zasób.

Równie łatwo o nim zapomnieć.

Po kilku miesiącach może się okazać, że firma płaci za:

• stary serwer testowy,
• nieużywany dysk,
• snapshot sprzed kilku lat,
• zapomniany adres IP.

Regularny przegląd zasobów jest częścią utrzymania.

Infrastructure as Code

Chmurą można zarządzać nie tylko przez panel.

Infrastrukturę można opisać kodem.

Taki model określa się jako Infrastructure as Code.

Zamiast ręcznie tworzyć:

• sieć,
• serwer,
• reguły,
• bazę,

można zapisać konfigurację w plikach i na ich podstawie odtwarzać środowisko.

Dlaczego Infrastructure as Code jest ważne?

Daje:

• powtarzalność,
• wersjonowanie zmian,
• łatwiejsze review,
• możliwość automatyzacji.

Jeżeli produkcja i staging mają powstać na podobnej architekturze, można uniknąć wielu ręcznych różnic.

DevOps i Google Cloud

DevOps łączy rozwój oprogramowania z operacyjnym utrzymaniem systemu.

Chmura dobrze pasuje do tego modelu, ponieważ bardzo dużą częścią infrastruktury można zarządzać automatycznie.

Typowy proces może wyglądać:

zmiana kodu → testy → budowa aplikacji → wdrożenie.

Im mniej ręcznych etapów, tym łatwiej zachować powtarzalność.

CI/CD

CI/CD opisuje automatyzację procesu integracji i wdrażania oprogramowania.

Po zmianie kodu system może automatycznie:

• uruchomić testy,
• zbudować aplikację,
• wdrożyć ją na staging,
• po akceptacji wdrożyć produkcję.

To szczególnie wartościowe przy aplikacjach rozwijanych regularnie.

Chmura nie eliminuje potrzeby stagingu

Wręcz przeciwnie.

Łatwość tworzenia środowisk pozwala lepiej oddzielić:

• development,
• staging,
• production.

Zmiany nie powinny być testowane pierwszy raz na użytkownikach produkcyjnych.

Google Cloud a sklep internetowy

Sklep może wykorzystywać Google Cloud na wiele sposobów.

Nie musi od razu przenosić całego WooCommerce do chmury.

Może korzystać z niej tylko do:

• przetwarzania danych,
• generowania plików,
• integracji,
• analityki,
• przechowywania zasobów.

Architektura może być hybrydowa.

Przykład: generowanie dużego feedu produktowego

Załóżmy, że sklep posiada setki tysięcy produktów.

Generowanie feedu na tym samym serwerze co frontend może mocno obciążać stronę.

Można rozważyć przeniesienie ciężkiego procesu do osobnej usługi.

Sklep przekazuje dane.

Chmura generuje plik.

Gotowy feed trafia do storage.

Frontend nie musi wykonywać całej pracy.

Przykład: system konfiguratora

Strona może posiadać konfigurator produktu wymagający intensywnych obliczeń.

Frontend zbiera parametry.

Backend w chmurze:

• waliduje konfigurację,
• wylicza cenę,
• generuje dokument,
• przekazuje dane do ERP.

Nie ma konieczności wykonywania wszystkiego wewnątrz WordPressa.

Przykład: przetwarzanie plików

Użytkownik wysyła duży plik.

Zamiast przetwarzać go podczas jednego żądania strony:

1. plik trafia do storage,
2. system generuje zdarzenie,
3. osobna usługa wykonuje operację,
4. wynik jest zapisywany,
5. użytkownik otrzymuje informację o zakończeniu.

To przykład architektury asynchronicznej.

Asynchroniczność może poprawić odporność systemu

Nie każda operacja musi wydarzyć się natychmiast w jednym żądaniu.

Jeżeli generowanie raportu trwa trzy minuty, użytkownik nie powinien koniecznie utrzymywać przez trzy minuty otwartego połączenia z serwerem.

Lepiej może być:

zleć zadanie → wykonaj w tle → poinformuj o wyniku.

Cloud nie oznacza automatycznie nieskończonej skali

Każda usługa ma określone:

• limity,
• quota,
• parametry.

Jeżeli aplikacja nagle generuje milion razy większy ruch, system nie zawsze bez żadnego przygotowania obsłuży wszystko.

Skalę trzeba projektować i testować.

Quotas mogą chronić również przed błędem

Limit nie zawsze jest przeszkodą.

Może zapobiec sytuacji, w której źle napisany skrypt tworzy tysiące zasobów albo generuje ogromne koszty.

Dobrze ustawione ograniczenia są częścią bezpieczeństwa operacyjnego.

Google Cloud a wydajność strony

Sama migracja serwera do Google Cloud nie gwarantuje lepszego wyniku wydajnościowego.

Na szybkość strony wpływają również:

• kod,
• baza danych,
• cache,
• obrazy,
• JavaScript,
• architektura aplikacji.

Bardzo mocny serwer może jedynie ukryć część problemów.

Większa maszyna nie zawsze jest optymalizacją

Jeżeli strona wykonuje 500 niepotrzebnych zapytań do bazy, można dołożyć CPU.

Można również poprawić aplikację.

Pierwsza metoda może zwiększyć rachunek.

Druga może rozwiązać przyczynę.

Google Cloud a CDN

Przy użytkownikach znajdujących się w różnych lokalizacjach można wykorzystywać rozwiązania rozprowadzające zasoby bliżej odbiorcy.

CDN może przechowywać kopie wybranych treści w wielu punktach sieci.

Dzięki temu nie każdy użytkownik musi pobierać wszystkie zasoby z jednego miejsca.

Cache a chmura

Cache nadal pozostaje jednym z najważniejszych elementów wydajności.

Nie ma sensu za każdym razem wykonywać drogiej operacji, jeżeli jej wynik można bezpiecznie wykorzystać ponownie.

Chmura nie usuwa podstawowych zasad optymalizacji.

Google Cloud a zgodność i lokalizacja danych

Firmy mogą mieć wymagania dotyczące tego:

• gdzie przetwarzane są dane,
• kto ma do nich dostęp,
• jak są zabezpieczone.

Wybór regionu nie powinien więc wynikać wyłącznie z ceny.

W projektach przetwarzających wrażliwe informacje trzeba uwzględnić również wymagania prawne i organizacyjne.

Cloud nie przenosi odpowiedzialności prawnej na Google

Jeżeli firma korzysta z infrastruktury zewnętrznego dostawcy, nadal odpowiada za własne obowiązki dotyczące przetwarzanych danych.

Technologia pomaga spełnić określone wymagania.

Nie zastępuje analizy prawnej.

Najczęstszy błąd: cloud dla samego cloud

Projekt ma prostą stronę i niewielką bazę.

Ktoś proponuje:

• Kubernetes,
• mikroserwisy,
• kilka baz,
• kolejki,
• trzy środowiska.

Technicznie wygląda imponująco.

Biznesowo może być kompletnie niepotrzebne.

Każda dodatkowa usługa zwiększa:

• koszt,
• liczbę zależności,
• zakres monitoringu,
• ilość wiedzy potrzebnej do utrzymania.

Drugi błąd: brak kontroli kosztów

Chmura ułatwia tworzenie zasobów.

Bez budżetów i regularnego przeglądu można bardzo łatwo stracić kontrolę nad wydatkami.

Trzeci błąd: pełne uprawnienia dla wszystkich

To wygodne podczas pierwszego dnia projektu.

Po roku może oznaczać kilkanaście osób mogących usunąć krytyczne zasoby.

Czwarty błąd: brak backupu, bo „Google przecież nie straci danych”

Dostawca może zapewniać bardzo wysoką niezawodność infrastruktury.

Firma nadal może sama:

• usunąć dane,
• nadpisać je,
• wdrożyć błędną migrację,
• paść ofiarą przejęcia konta.

Backup zabezpiecza również przed błędem człowieka.

Piąty błąd: sekrety zapisane w kodzie

Hasła, tokeny i klucze API nie powinny być przypadkowo umieszczane w repozytorium.

Do zarządzania sekretami powinien istnieć kontrolowany mechanizm.

Szósty błąd: jedna wielka maszyna

Początkowo wszystko działa na jednym serwerze:

• aplikacja,
• baza,
• kolejka,
• pliki.

To może być rozsądny MVP.

Problem zaczyna się, gdy system rośnie, a architektura nigdy nie zostaje ponownie oceniona.

Siódmy błąd: komplikowanie systemu za wcześnie

Przeciwna skrajność również jest zła.

Nie warto od pierwszego dnia projektować infrastruktury dla 100 milionów użytkowników, jeżeli produkt nie ma jeszcze pierwszego klienta.

Architektura powinna pozwalać na rozwój, ale nie musi rozwiązywać problemów, których jeszcze nie ma.

Ósmy błąd: brak monitoringu

System działa dobrze przez pół roku.

Później zaczyna zwalniać.

Nikt nie wie:

• kiedy problem się zaczął,
• który komponent odpowiada,
• jak zmieniało się obciążenie.

Bez danych diagnoza jest znacznie trudniejsza.

Dziewiąty błąd: migracja bez planu powrotu

Przenosząc krytyczny system, warto wiedzieć:

• jak będzie wyglądać cutover,
• jak zweryfikować poprawność,
• co zrobić przy niepowodzeniu.

Migracja do chmury również może się nie udać.

Dziesiąty błąd: brak dokumentacji architektury

Po kilku latach firma posiada:

• 30 usług,
• kilka sieci,
• dziesiątki kont,
• setki reguł.

Jedyną osobą wiedzącą, jak to działa, jest administrator, który właśnie odchodzi.

Chmura szczególnie potrzebuje porządku, ponieważ zasoby można tworzyć bardzo szybko.

Kiedy Google Cloud ma szczególnie dużo sensu?

Rozważałbym je przede wszystkim przy projektach wymagających:

• niestandardowej infrastruktury,
• skalowania,
• dużej ilości danych,
• zarządzanych usług,
• integracji wielu systemów,
• przetwarzania zdarzeń,
• zaawansowanej analityki.

Kiedy klasyczny hosting może być lepszy?

Jeżeli projekt to:

• zwykła strona firmowa,
• niewielki WordPress,
• standardowy sklep bez specjalnych wymagań,

dobry zarządzany hosting może być znacznie prostszy.

Nie trzeba wtedy utrzymywać całej warstwy cloud infrastructure.

Google Cloud dla małej firmy

Mała firma również może korzystać z chmury.

Nie musi jednak używać jej w taki sam sposób jak globalna korporacja.

Może potrzebować tylko jednej usługi.

Na przykład:

• storage na backupy,
• backend dla integracji,
• hurtownię danych,
• proces generujący raporty.

Cloud nie jest pakietem, który trzeba wdrożyć w całości.

Google Cloud dla dużej organizacji

W większej firmie pojawiają się dodatkowe potrzeby:

• wiele projektów,
• wiele zespołów,
• kontrola kosztów,
• polityki bezpieczeństwa,
• audyt,
• zarządzanie dostępem.

Wtedy sama technologia staje się tylko częścią problemu.

Trzeba zbudować model zarządzania chmurą.

Cloud governance

Cloud governance oznacza zasady określające, jak organizacja korzysta z chmury.

Mogą definiować:

• kto może tworzyć projekty,
• jak nadawane są dostępy,
• jak oznacza się zasoby,
• jak kontrolowane są koszty,
• które regiony są dozwolone.

Bez takich reguł duża organizacja może bardzo szybko stworzyć chmurowy chaos.

Google Cloud a tradycyjna serwerownia

Własna infrastruktura daje:

• dużą kontrolę fizyczną,
• przewidywalny koszt przy stabilnym wykorzystaniu,
• brak zależności od zewnętrznej platformy w części obszarów.

Chmura daje:

• szybkie uruchamianie zasobów,
• łatwiejsze skalowanie,
• dostęp do wielu usług zarządzanych.

Nie istnieje jedna odpowiedź dla każdej organizacji.

Lift and shift – prosta migracja do chmury

Lift and shift oznacza przeniesienie istniejącego systemu do chmury z niewielkimi zmianami architektury.

Przykładowo:

serwer fizyczny → maszyna wirtualna w Google Cloud.

To może być szybki pierwszy etap.

Nie wykorzystuje jednak wszystkich możliwości cloud computing.

Cloud native

Cloud native oznacza projektowanie systemu z myślą o możliwościach środowiska chmurowego.

Może obejmować:

• kontenery,
• serverless,
• automatyczne skalowanie,
• zarządzane usługi,
• automatyczne wdrożenia.

Nie oznacza to, że architektura cloud native jest zawsze lepsza.

Jest po prostu projektowana z innymi założeniami.

Nie migruj tylko po to, żeby powiedzieć „jesteśmy w cloudzie”

Migracja powinna mieć konkretny cel.

Na przykład:

• zmniejszenie czasu wdrażania,
• obsługa większego ruchu,
• zwiększenie odporności,
• dostęp do usług analitycznych,
• odejście od starego sprzętu.

Jeżeli nie wiadomo, jaki problem ma rozwiązać migracja, trudno później ocenić jej sukces.

Jak zaplanować projekt w Google Cloud?

Zacząłbym od pytań biznesowych i technicznych.

1. Co ma robić system?
2. Ilu użytkowników ma obsługiwać?
3. Jakie dane przetwarza?
4. Jak krytyczna jest jego dostępność?
5. Jak szybko może rosnąć?
6. Z jakimi systemami się komunikuje?
7. Jaki budżet jest akceptowalny?

Dopiero później dobierałbym konkretne usługi.

Nie zaczynaj od listy produktów Google

To częsty błąd architektoniczny.

Najpierw ktoś przegląda katalog usług i wybiera:

• Cloud Run,
• BigQuery,
• Pub/Sub.

Dopiero później próbuje wymyślić, gdzie można ich użyć.

Powinno być odwrotnie.

Najpierw problem.

Później technologia.

Proof of Concept przed dużym wdrożeniem

Jeżeli organizacja nie wie, czy określona architektura sprawdzi się w praktyce, można rozpocząć od PoC.

Mały test może odpowiedzieć:

• czy technologia działa,
• jak wygląda integracja,
• jaka jest wydajność,
• jakie są koszty.

To tańsze niż budowanie pełnego środowiska na podstawie samych założeń.

Google Cloud a MVP

Chmura bardzo dobrze pasuje również do budowania pierwszych wersji produktów.

Można szybko uruchomić:

• backend,
• bazę,
• storage,
• API.

Nie trzeba od razu inwestować we własną infrastrukturę.

Trzeba jednak pilnować, żeby MVP nie otrzymało architektury bardziej skomplikowanej niż sam produkt.

Chmura umożliwia rozwój etapami

Pierwsza wersja może działać na prostszej konfiguracji.

Po potwierdzeniu produktu można:

• dodać autoscaling,
• rozdzielić komponenty,
• wprowadzić dodatkową redundancję.

Nie trzeba od pierwszego dnia budować infrastruktury docelowej na dziesięć lat.

Jak ja patrzę na Google Cloud?

Nie traktuję Google Cloud jako odpowiedzi na każde pytanie infrastrukturalne.

To ogromny zestaw narzędzi.

Wartość pojawia się wtedy, kiedy odpowiednio dobierze się tylko te elementy, które rozwiązują konkretny problem.

Dla jednego projektu może to oznaczać:

jedną małą usługę serverless.

Dla innego:

rozbudowaną architekturę działającą w kilku strefach i przetwarzającą miliony operacji.

Oba rozwiązania mogą być prawidłowe.

Najpierw patrzę na cały proces

Jeżeli aplikacja ma integrować sklep, ERP i system logistyczny, nie zaczynam od pytania:

Którą usługę Google Cloud wybierzemy?

Najpierw sprawdzam:

• gdzie powstają dane,
• który system jest źródłem prawdy,
• co powinno wydarzyć się przy błędzie,
• które operacje muszą działać natychmiast,
• które mogą zostać wykonane w tle.

Dopiero wtedy można sensownie zaprojektować warstwę chmurową.

Google Cloud nie usuwa podstawowych zasad dobrej architektury

Nadal trzeba zadbać o:

• bezpieczeństwo,
• backup,
• monitoring,
• wydajność,
• dokumentację,
• kontrolę kosztów.

Cloud ułatwia wiele rzeczy.

Nie podejmuje za projektanta decyzji.

Najważniejsza zasada Google Cloud

Chmura nie jest celem. Jest sposobem dostarczania infrastruktury i usług.

Jeżeli zwykły hosting rozwiązuje problem dobrze, nie trzeba migrować do Google Cloud tylko po to, aby system był bardziej „nowoczesny”.

Jeżeli jednak projekt potrzebuje:

• elastycznej mocy,
• automatycznego skalowania,
• zaawansowanej analityki,
• integracji,
• zarządzanych usług,

Google Cloud daje dostęp do infrastruktury, której samodzielne zbudowanie byłoby dla większości firm bardzo trudne albo całkowicie nieopłacalne.

Największą przewagą chmury nie jest to, że „serwer znajduje się w Google”. Jest nią możliwość potraktowania infrastruktury jak elastycznego zasobu, który można tworzyć, zmieniać, automatyzować i skalować wraz z potrzebami systemu.