Machine learning z Tensorflow w chmurze na AWS EC2 z GUI!

Pomysł

Nie zawsze twój komputer jest na tyle wydajną maszyną by było to dla ciebie wygodne środowisko programistyczne. Czasami zdarza się tak, że trzeba sięgnąć jednak po coś szybszego. Nie zawsze chcesz kupować nowy komputer tylko na potrzeby jednego projektu, prawda? Niezależnie od powodów zakładamy, że skoro czytasz ten wpis to chcesz zająć się uczeniem maszynowym z Tensorflow na EC2 czyli AWSowym serwisem – Elastic Compute Cloud. Co więcej, będziemy chcieli by dostęp do systemu odbywać się przez GUI co daje o wiele większe pole manewru przy Machine Learning, który przecież może dotykać każdego medium, czy to tekst, dźwięk, obraz czy wideo.

robot playing piano
Photo by Franck V. on Unsplash

Pisałem o Tensorflow, ale w niemalże identyczny sposób możesz wykorzystać EC2 do programowania przy użyciu innych popularnych bibliotek, takich jak:

  • PyTorch
  • Apache MXNet
  • Chainer
  • Microsoft Cognitive Toolkit
  • Gluon
  • Horovod
  • Keras

(aktualna lista https://aws.amazon.com/machine-learning/amis/)

https://aws.amazon.com/machine-learning/amis/

Warunki wstępne

Założenie konta nie powinno sprawić ci większych trudności. AWS dość dobrze i dokładnie tłumaczy jak to zrobić.  Jeżeli dopiero teraz zakładasz konto, na pocieszenie pamiętaj o wykorzystaniu bonusów z AWS Free Tier  https://aws.amazon.com/free/ . Jest to na prawdę ciekawa możliwość na przetestowanie wielu serwisów AWS-a przez pierwszy rok za darmo (a niektórych nawet dłużej niż rok). Oczywiście to ‚testowanie’ jest poddane ograniczeniom jednak często w zupełności wystarcza do stworzenia prostych serwisów.
Ale teraz do meritum.

https://aws.amazon.com/ec2

Pierwsze kroki

Zakładając, że masz już konto na AWS. Możemy przejść do ciekawszych spraw. 
W konsoli AWS, przechodzimy do serwisu EC2 i tworzymy nową instancję. Jaki region wybrać? Proponuje Frankfurt ew. Irlandia (prawy górny róg).

Wybór regionu

Przechodzimy do uruchamiania instancji.

Naszym oczom ukazuje się obraz wyboru obrazu, którego chcemy użyć. Wybieramy odpowiedni AMI, czyli Amazon Machine Image. Wpisujemy w pole wyszukiwania ‚Deep Learning’. To specjalnie przygotowane obrazy z narzędziami do Machine Learning jak np. tytułowy Tensorflow. Oczywiście moglibyśmy zainstalować wszystko od zera. Moglibyśmy też kupić sobie maszynkę i nie używać chmury itd… 🙂 W każdym razie, powinniśmy zobaczyć ekran:

Ja np. wybrałem maszynkę z najnowszym Ubuntu i jeżeli nie masz swoich preferencji to wybierz ją także.

 Rodzaj instancji

Kuszące może być skorzystanie z wersji ‚micro’ by wykorzystać ww. Free Tier. Jednak szczerze to odradzam tego rodzaju skąpstwo. Używamy AWS gdyż zapewnia nam wygodne skalowanie maszyny do problemu, ale na maszynie ‚micro’ raczej nie rozwiążemy żadnego problemu. Na początek możesz wybrać np. t2.xlarge. Jest to instancja generalnego przeznaczenia i traktujemy ją jak playground. Później w każdej chwili możemy przesiąść się na coś bardziej dedykowanego pod Machine Learning.
Pamiętaj, żeby przed użyciem maszyny zapoznać się z cennikiem, tak żeby nie było, że nie uprzedzałem https://aws.amazon.com/ec2/pricing/

Warto nadmienić, że w następnym wpisie mogę pokazać ci jak znacząco ograniczyć koszta poprzez wykorzystanie tzw. ‚spot instances’ jednak tutaj nie chcę nadmiernie komplikować rozwiązania.
Klikamy kolejno na ‚Review and Launch’
I potem ‚Launch’

Credentials

Dobrą praktyką będzie stworzenie osobnych kluczy, wybieramy ‚Create a new pair’

Jeżeli teraz spróbujemy użyć kluczy, możemy napotkać na problem z kompatybilnością ich formatu. Jeżeli tak się stanie, a dla mnie się to stało, to będziemy potrzebować aplikacji putty  https://www.putty.org/ więc proszę ściągnij ją. Odpalamy narzędzie puttygen.exe przychodzące w zestawie z putty i ładujemy klucz ściągnięty z AWSa. 

I zapisujemy w formacie ppk. Uff mamy klucz do drzwi. Ale gdzie są drzwi???!


Wracamy do naszej świeżo wypieczonej instancji EC2. Na stronie z instancjami EC2 mamy na dole panel ze szczegółami dotyczącymi naszej instancji. Nas przede wszystkim interesuje adres publiczny IP i adres prywatny IP. To przez te adresy spróbujemy połączyć się z naszego komputera do instancji. 

Putty


Tak, zwracamy się o pomoc do Pana Putty. 

Naszym oczom ukazuje się ekran niczym z … dobra nie hejtujmy, putty to na prawdę świetne rozwiązanie. 

w pole Host Name wpisujemy nasz publiczny adres i przechodzimy do Connection>SSH>Auth i klikamy Browse wybrać klucz który uprzednio skonwertowaliśmy 

Teraz otwieramy zakładkę ‚Tunnel’ i tworzymy tunel do naszej instancji, jako port źródłowy podajemy dowolny wolny port, u mnie np. 8080 i jako cel tunelu: prywatne IP instancji EC2 oraz port 3389. Dzięki temu ruch na nasz localhost:8080 zostanie przekierowany przez Putty do AWS do naszej prywatnej maszynki przez port 22 na adres prywatny i port 3389 (RDP).

Ważna sprawa, po każdej zmianie zapisujemy sesję, by nie stracić dotychczasowego nakładu pracy:

Dobra ale nasza instancja nie jest jeszcze gotowa by pokazać swój desktop. By ją do tego przygotować otwieramy naszą sesję (Open) i pokaże nam się okno w stylu:

Przy pierwszym połączeniu jest to oczekiwany rezultat. Przechodzimy dalej klikając Yes.

Na następnym ekranie wita nas już terminal naszego systemu. Login to: ubuntu
Jeżeli widzisz ekran taki jak

to brawo, udało się, jesteśmy połączeni. Teraz możemy przystosować naszą instancję by umożliwić tryb GUI.

Pamiętaj żeby zachować hasło, które podasz za chwilę, w przeciwnym wypadku połączenie będzie niemożliwe.

sudo apt update &&  sudo apt upgrade

sudo sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config

sudo /etc/init.d/ssh restart

sudo passwd ubuntu

sudo apt install xrdp xfce4 xfce4-goodies tightvncserver

echo xfce4-session> /home/ubuntu/.xsession

sudo cp /home/ubuntu/.xsession /etc/skel

sudo sed -i '0,/-1/s//ask-1/' /etc/xrdp/xrdp.ini

sudo service xrdp restart

źródło powyższego skryptu: youtube  https://www.youtube.com/watch?v=6x_okhl_CF4

Po wykonaniu powyższych instrukcji przystępujemy do ostatniego etapu. Uruchamiamy Remote Desktop Connection (RDP) i podajemy adres localhost:8080 (lub jakikolwiek inny port skonfigurowany w putty)

Mamy to! Tryb GUI na AWS EC2!

Tak wygląda ekran naszego ubuntu

Jeszcze tylko włączmy odpowiednie środowiko uczenia maszynowego i jesteśmy w domu. Przebyliśmy dziś długą drogę, ale na szczęście aktywacja Tensforflow na naszej maszynie będzie bardzo prosta dzięki obrazowi (AMI), który wybraliśmy (Deap learning).
Wykorzystujemy najnowszą wersję Tensorflow przy użyciu:

source activate tensorflow2_latest_p37

i w konsoli możemy już zaczynać pracę.

Jeżeli wolisz jakąś inną wersję Tensorflow-a, bądź też całkiem inny pre-instalowany framework, zawsze możesz wykorzystać komendę listującą dostępne środowiska i wybrać coś innego:

Po wyborze i aktywacji odpowiedniego środowiska możemy przetestować, że wszystko poszło po naszej myśli. W moim wypadku w konsoli python-a wpisuję:

import tensorflow
print(tensorflow.__version__)

Wszystko gra. Przed nami otwierają się nowe możliwości.

Aha, no i przypominam, że z wykorzystaniem AWSa wiążą się koszty, czasami całkiem konkretne, zapoznaj się z cennikiem https://aws.amazon.com/ec2/pricing/, po skończonej pracy wyłączaj maszyny, używaj spot instances, minimalizuj wykorzystane volumes i generalnie czytaj cenniki rzeczy których używasz i trzymaj rękę na pulsie przez umieszczenie alarmów na wykorzystane środki na AWS

Linki:

Pobij Netflixa

Skoro już cię przekonałem dlaczego warto używać chmury oraz dlaczego to może być AWS następnym logicznym krokiem jest przedstawienie jakiegoś przykładowego rozwiązania bazującego na chmurze AWS. Dziś na warsztat weźmiemy rozwiązanie streamingowe, które pozwoli ci pobić Netflixa 😉

woman lying on bed while eating puff corn

 

Domena

Dla uproszczenia dziedziny problemu, przyjmijmy, że chcielibyśmy mniej więcej odzwierciedlić podstawowe funkcjonalności Netflixa (oczywiście zrobimy to lepiej!), czyli dostarczyć rozwiązanie pozwalające na oglądanie wideo na życzenie oraz platformę, która owe wideo serwuje. 
Użytkownik w dzisiejszych czasach jest bardzo wybredny. Mając do czynienia z rozwiązaniami typu HBO Go czy Netfix musimy dostarczyć serwis, która będzie:

Niezawodny

Powiedzmy sobie szczerze ile razy nie działał ci Netflix z ich winy?

Szybki

Jeżeli użytkownik będzie musiał czekać na buforowanie wideo zbyt długo to pójdzie tam gdzie nie musi czekać. To nic osobistego.

Relatywnie tani

Oczywiście możemy kupić najlepsze dostępne serwery, bazy danych itd, ale kiedy przyjdzie nam obsługiwać ruch tysięcy użytkowników to rachunki szybko poszybują na poziomy takie, że szybko zrezygnujemy z naszych ambitnych planów.

Skalowalny

Użytkownika mało obchodzi to, że akurat dziś ruch na naszych serwerach jest 2-3 czy 10 razy większy niż zwykle. To się zdarza, naszym zadaniem jest na to się przygotować.

Ogólna architektura

Pomijając zbędne szczegóły architektura takiego przekrojowego rozwiązania może wyglądać następująco:

Omówmy sobie po kolei wszystkie komponenty

Warstwa API Gateway

Odpowiada za odbiór żądań ze strony urządzeń. Jak mówi nazwa to interfejs do naszego systemu. Wszelkiego rodzaju przeglądarki, smartfony czy też TV będą komunikować się właśnie przez tą warstwę. Tutaj załatwimy sprawę cache-owania żądań, kontroli dostępu i przekierujemy żądania do warstwy serwerów aplikacyjnych.

Warstwa serwerów aplikacyjnych

Tutaj umieścimy obliczenia i całą logikę odpowiedzialną za obsługę żądań. Główny kod odpowiedzialny za synchroniczne przetwarzanie zapytań tak by dostarczyć użytkownikowi odpowiednie „ekrany” i ich zawartość. Od strony infrastruktury, logika odpalana jest oczywiście na serwerach czy też ich klastrach. Częściowo mogą być to lambdy przy podejściu bardziej serverless. Zwłaszcza na początku gdy dopiero rozpatrujemy różne możliwości jest to kuszące rozwiązanie. Mamy tu także wykorzystanie kolejek zadań, cache, baz danych, oraz oczywiście innych mikroserwisów czy to naszych, czy też zewnętrznych rozwiązań – SAAS.

Warstwa zadań asynchronicznych.

Wszystkie zapytania, które nie należą do naszej aplikacji bezpośrednio, ale też muszą się zadziać. Jeżeli chcesz zrobić system chociaż w niewielkim stopniu podobny do Netflixa, czy też go pobić, trzeba sobie uświadomić sobie ogrom pracy jaka jest wykonywana „pod spodem”, czyli po prostu na backendzie.

Co musimy przygotować dla użytkowników?

  • Wideo w odpowiednim formacie. Każde urządzenia to inne wymagania odnośnie formatu czy też rozmiaru. Nie mówiąc o tym, że musimy serwować różne pliki w zależności od szybkości łącza użytkownika.
  • Rekomendacje. Kiedyś to może byłby fajny dodatek, teraz to wymóg by prezentować rekomendacje dla użytkowników, jeżeli trafimy w gusta, +5 punktów dla nas!
  • Newslettery. Byle nie za dużo spamu.
  • Bieżąca obsługa. Reset hasła, usunięcie konta itd

Przestrzeń chmurowa (cloud storage) i CDN

Forma przechowywania danych wideo to jedno z bardziej krytycznych zadań. Trzeba pamiętać o tym, że danych tych będzie bardzo dużo (pamiętasz, że mamy wiele kopii tych samych filmów?) Potencjalne koszty będą tutaj silnie skorelowane właśnie z rozmiarem danych. Z drugiej strony nie możemy sobie pozwolić by dostęp do nich był wolny, inaczej użytkownik szybko wybierze konkurencję. Innymi słowy potrzebujemy hybrydy przestrzeni chmurowej i CDNa. Przestrzeń chmurowa to po prostu serwer plików, a CDN, czyli Content Delivery Network lix-a to rozproszona sieć buforująca często używane zasoby poprzez ich kopiowanie na odpowiednie serwery będące blisko użytkownika końcowego. Będąc w Polsce, możemy szybciej streamować film, jeżeli znajduje się od na serwerze we Wrocławiu, niż gdy znajduje się w Los Angeles, prawda?

Uczenie maszynowe

Tutaj umieszczamy cokolwiek, byle by móc powiedzieć, że „robimy machine learning” i ściągnąć zainteresowanie inwestorów i klientów 😛 A tak na prawdę to skoro chcemy serwować naszym użytkownikom wspomniane wcześniej rekomendacje to dobrze jest móc to robić w oparciu nie o sztywne reguły, a właśnie modele wykorzystujące uczenie maszynowe. Dzięki temu będziemy mogli analizować podobieństwo między różnymi użytkownikami oraz podobieństwo miedzy filmami i na tej podstawie decydować czym dana osoba może być zainteresowana. To wszystko powinno przełożyć na trafniejsze rekomendacje i wzrost zainteresowania naszym rozwiązaniem.

Hurtownia danych

Raporty, analiza danych, musisz trzymać rękę na pulsie. Hurtownia to miejsce gdzie dane te są zorganizowane w przystępnej formie.

AWS

Przestwawię teraz przykładową implementację powyższych komponentów w AWSie. Od razu zaznaczam, że pewne kwestie zostały pominięte dla prostoty diagramu, przykładowo logowanie czy monitoring. Jeżeli chodzi o dobór konkretnych rozwiązań to też mamy do wyboru wielorakie rozwiązania na rynku. Nic nie stoi na przeszkodzie by część z nich było poza AWS, jednak formuła tego artykułu jest taka, że tylko do tej chmury zawęzimy nasz wybór. Dobra, koniec gadania:

Wersja w lepszej rozdzielczości: tutaj

Omówię teraz po krótce kluczowe decyzje.

Warstwa API Gateway

Jak wcześnieś zauważyliśmy, chcemy odpowiednio zopytmalizować wrażenia użytkowników różnych platform. Stąd też podejście typu backend for frontend, czyli warstwa API Gateway posiada wyspecjalizowane dedykowane AWS API Gatewaye w zależności od platformy klienckiej.

Warstwa serwerów aplikacyjnych

Sercem rozwiązania są klastry ECS, czyli Elastic Cloud Server. Tak, konteneryzacja zawitała i do nas! Żądania przychodzą od strony load balancer-a. Do tego SQS do kolejkowania zadań. Jako baza danych może posłużyć nam DynamoDB o ile dobrze czujemy się w środowisku baz NoSQL. Zaletą DynamoDB jest łatwa skalowalność, która jest dla nas niemalże przeźroczysta. Alternatywnie możemy posłużyć się RDS Aurorą.

 Warstwa zadań asynchronicznych

Preview(opens in a new tab)

Od strony infrastruktury wygląda to podobnie jak w przypadku warstwy serwerów aplikacyjnych. Różnicą będzie dużo większe wykorzystanie kolejek SQS, potencjalnie także topic-ów SNS to komunikacji zorientowanej na wiadomości, której będzie tutaj dużo.

Jedno z kluczowych zadań do wykonania w tej warstwie to transcoding wideo, który może wyglądać następująco:

Na wejściu mamy nieskompresowany plik wideo, wrzucony być może przez samego autora filmu. Na wyjściu mamy plik dostosowany przez nas process do odpowiedniego urządzenia końcowego.

Przestrzeń chmurowa (cloud storage) i CDN

Troche już w punkcie poprzednim zostało opowiedziane przy okazji omawiania transcodingu. S3+CloudFront załatwiają sprawę. 

Alternatywne rozwiązania – AWS Media Services

Pewną alternatywą dla nas mogą być AWS Media Services

Z naszej perspektywy użyteczne mogło by być zwłaszcza AWS Elemental MediaConvert, które zapewnia właśnie usługę transcodingu. Dużym plusem jest to, że płacimy tutaj za użycie, czyli tak jak w infrastrukturze powyżej, gdzie brudną robotę wykonują za nas EC2-ki. Myślę, że AWS Elemental MediaConvert możemy rozważyć jako element naszego MVP a docelowo możemy kierować się jednak ku ECS/EC2 gdyż pozwoli nam to na większą elastyczność rozwiązania i zoptymalizowanie kosztów. Zasadniczo reguła kciuka mówi nam, że im bardziej wysokopoziomowe rozwiązanie, tak jak w przypadku AWS Elemental MediaConvert, cena rośnie w sposób adekwatny.

Podsumowanie i dalsze kroki

Tak jak pisałem wyżej. Poza zaprezentowanymi rozwiązaniami pozostaje do doprecyzowania zostaje wiele kwestii pobocznych. Przykładowo do logowania możemy użyć serwisu Cloud Watch. To właśnie Cloud Watcha użyjemy także do monitorowania naszych zasobów oraz podnoszenia odpowiednich alarmów gdy przykładowo będziemy mieli do czynienia z jakimś problemem. Nie chcemy przecież by tak błache rzeczy jak np. brak pamięci na serwerze, błęd w logice serwisu czy tego typu sprawy zaprzepaściły nasz cały wysiłek i popsuły wizerunek pogromcy Netflixa.

Do przesyłu danych może przydać się Kinesis streams. Autentykacja użytkowników może przebiegać w Cognito. Potrzebujemy też dobrego cache-a, Amazon ElastiCache, poratuje. A no i nie obędzie się bez kontroli tego co który serwis może robić a czego nie może zrobić. Tu do gry wkracza IAM. Na tym chyba poprzestanę 🙂


Z pewnością tego typu przekrojowa architektura może nieco odstraszać, aczkolwiek pozwala sobie jednak zdać sprawę jak skomplikowane tworzenie systemów może być gdy nie mamy do dyspozycji tych gotowych serwisów i chcielibyśmy implementować skalowalny system przy pomocy softwareu instalowanego na naszych maszynach.

Chmura obliczeniowa – dlaczego? Zalety i wady

Cloud computing to często pojawiający się temat w dyskusjach o miejscu prowadzenia swojego biznesu w chmurze. Jednakże, przed podjęciem decyzji o wskoczeniu do AWS, Azure czy Google Cloud, warto zaznajomić się z konsekwencjami takiego wyboru.
Przygotowałem zestawienie, które może pomóc osobom borykającym się z dylematem co do wejścia na chmurę.

Zalety

  1. Niski próg wejścia. Jest to niezwykle istotne zwłaszcza w przypadku startupów nie przynoszących jeszcze zysków. Jesteśmy w stanie zaproponować i zwalidować nasze MVP (Minimum Viable Product) często nawet zerowym kosztem. Przykładowo AWS oferuje nam AWS Free Tier – https://aws.amazon.com/free/ a Azure https://azure.microsoft.com/pl-pl/free/
  2. Bezpieczeństwo dostępu do danych. O ile używamy usługi w chmurze w rozsądny sposób mamy do dyspozycji mechanizmy dzięki którym możemy w nocy spać spokojnie. Oczywiście należy być świadomym, że dane nie leżą u nas „na serwerze pod biurkiem” tylko są w bliżej nieokreślonym miejscu w chmurze i to po naszej stronie stoi odpowiedzialność za kontrolę dostępu do danych czy też ochrona haseł.
  3. Mniej kodu związanego z infrastrukturą. Używamy infrastruktury udostępnionej dla nas i możemy skupiać się na tym co jest istotne dla naszego systemu. Dzięki chmurze rozpowszechnił się popularny trend serverless.
  4. Brak potrzeby własnych serwerów. Poza finansowymi aspektami związanymi z zakupem, nie musimy się przejmować awariami tego sprzętu czy też serwisowaniem.
  5. Łatwa skalowalność. W zależności od konkretnej usługi często może dziać się automatycznie w zależności od aktualnego obciążenia systemu. Co to znaczy dla naszego biznesu? Jeżeli obłożenie jest nierównomierne w czasie (a zazwyczaj tak jest) to możemy cieszyć się niższymi rachunkami w czasie mniejszego obciążenia i jednocześnie być w stanie obsługiwać nawet kilkunastokrotnie zwiększone zapotrzebowanie na zasoby.
  6. Dostępność. Dzięki zarządzanym serwisom ciężar utrzymywania wysokiej dostępności jest w wielu aspektach zapewniany poprzez dostarczyciela usług w chmurze. SLA jest zazwyczaj na wysokim poziomie, zadowalającym dla 99% systemów. W przypadku systemów gdzie dostępność jest na prawdę rzeczą krytyczną można stosować podejścia zmniejszające ryzyko takie jak wykorzystanie więcej niż jednego dostawcy usług chmurowych.
  7. Koszty proporcjonalne do wykorzystania zasobów. W zależności od serwisu możemy dostosowywać koszt systemu poprzez zmianę parametrów wykorzystywanych usług takich jak przydział CPU, RAM, wielkość dysku. W przypadku innych serwisów możemy mieć możliwość płatności tylko za wykonaną pracę, czyli liczbę (mili)sekund w których nasz kod był wykonywany.
  8. Łatwe backupy. Tworzenie kopii zapasowych w przypadku baz danych, plików jest znacząco ułatwione, a serwisy często udostępniają możliwość eksportu danych do plików przechowywanych w innych usługach.
  9. Wielorakość serwisów pozwalających na wykorzystanie funkcjonalności: 
    1. Uruchamiania kodu w formie bezstanowych serwisów (np. Azure Functions, AWS Lambda) bądź też wirtualnych serwerów (np. Azure Virtual machines, AWS Elastic Compute Cloud – EC2)
    2. Baz danych (np. AWS RDS, DynamoDB, Azure Cosmos DB)
    3. DNS (np. AWS Route53, Azure DNS)
    4. CDN (np. AWS CloudFront, Azure Content Delivery Network)
    5. Serwer plików
    6. Fulltext search
    7. Kolejki wiadomości
    8. Wysyłka wiadomości
    9. Code integration/deployment
    10. Konteneryzacja (Docker)
    11. Big data i hurtownie danych, zarówno w procesie zbierania, przesyłania, przetwarzania jak i przechowywania danych
    12. Analiza danych
    13. Machine learning
    14. Zarządzanie, konfiguracja i monitoring naszych usług
    15. Internet of Things
    16. Usługi multimedialne 

Wady:

  1. Bezpieczeństwo danych. Tak tak, podobny punkt był też w zaletach 🙂 Brak kontroli z naszej strony co do tego w jaki sposób nasze są przetwarzane. W pewnych aspektach opieramy się na zaufaniu co do dostawcy usług chmurowych.
  2. Koszty
    1. Potrzebna jest ciągła analiza i kontrola kosztów tak by szybko identyfikować miejsca w których pieniądze zbyt szybko są spalane. Na szczęście mamy do dyspozycji narzędzia dzięki, którym nie wymaga to nie wiadomo jakiego nakładu pracy.
    2. Architektura systemu musi być rozwijana w oparciu o analizę przyszłego rozwoju projektu tak by dobrać odpowiednie rozwiązanie które spełnia wymagania i nie jest zbyt kosztowne.
  3. Vendor lock-in. Im więcej używamy usług danego dostawcy tym łatwiej dobrać kolejną usługę tego samego dostawcy (dzięki łatwej integracji między nimi), a tym samym tym bardziej jesteśmy uzależnieni od dokładnie tej chmury.
  4. Brak kontroli i uzależnienie od dostawcy. Nie mamy kontroli co do decyzji podejmowanych przez dostawcę usług chmurowych, który w jednej chwili może zdecydować o:
    1. likwidacji jednej z usług na której my polegamy
    2. wycofaniu się z interesu
    3. znaczącym podwyższeniu cennika usług
  5. Bezradność po wystąpieniu awarii. Jeżeli odpowiednio nie przygotujemy się na problemy z dostępnością danego serwisu to w przypadku wystąpienia danej trudności nie możemy już zbyt wiele zrobić niż czekać i przepraszać naszych klientów.
  6. Ochrona danych osobowych. Wiele z przepisów obowiązujących w danym kraju może obostrzać naszą swobodę w zakresie co do tego gdzie i w jaki sposób te dane mają być przechowywane.

Ogólny bilans, moim zdaniem, wychodzi zdecydowanie na plus. W generalnym rozrachunku przejście na zarządzane usługi z których składamy nasz system jest po prostu tańsze, jeżeli podejdziemy do tego tematu umiejętnie. Go cloud!