Przyszłość pracy z chmurą publiczną

Przeglądając moją prezentację z przed kilku lat, uznałem, że dotknąłem tam ciekawego tematu. O ile jest on nadal dość burzliwy (hura, mikroserwisy), o tyle, dotarło do mnie, że bardziej interesuje mnie coś innego. A mianowicie przyszłość pracy z chmurą obliczeniową. To krótkie studium różnych architektur serwisów uświadomiło mi, że każda z nich, to kolejny krok w ewolucji. Zacząłem się więc zastanawiać jak może wyglądać przyszłość. Jako początkującego twórcę fantastyki naukowej, temat mnie zafascynował.

W poszukiwaniu dalszej inspiracji, zacząłem się rozglądać, co na ten temat mają do powiedzenia inni. A najlepiej tacy, którzy są dużo mądrzejsi niż ja. Wynik tych poszukiwań nie był zbyt imponujący. Ludzie głównie piszą bardzo optymistycznie na temat aplikacji natywnych dla chmur, albo na temat automatyzacji. Inni wręcz poklepują się po plecach, gratulując sobie i innym, jaką to świetną robotę robimy. Moim zdaniem, rzeczywistość jest nieco bardziej pesymistyczna.

Jak zmieniała się architektura aplikacji?

Żeby móc przewidzieć to, co się może stać w przyszłości, musimy najpierw zerknąć wstecz. Ale, ponieważ nie chcę Cię zanudzać technicznymi aspektami działania aplikacji, tylko oględnie opiszę jak to wyglądało nie tak jeszcze dawno temu.

W dużym skrócie: Najpierw pojawiły się aplikacje działające na pojedyńczym komputerze, później pojawiła się komunikacja pomiędzy aplikacjami przez sieć. Następnie okazało się, że aby aplikacja nadal działała sprawnie pod większym ruchem, musimy nauczyć się skalować.

W tym celu mogliśmy kupić większy, szybszy komputer, lub zaadaptować aplikację tak, aby mogła działać równolegle na kilku maszynach. Serwisy w tym momencie nadal były jeszcze wielkimi molochami (monolit) łączonymi z sobą bezpośrednio (przez różnego rodzaju API) lub za pośrednictwem mniej lub bardziej zaawansowanych kolejek (ESB, Enterprise Service Bus).

Dzisiaj aplikacje już są rozbijane na mniejsze części, które są autonomicznymi, małymi serwisami, co powszechnie znamy jako mikroserwisy. Interakcja między nimi odbywa się albo przez API (czyli stanowo, bezpośrednio), albo bezstanowo za pośrednictwem kolejek lub serwisem wysyłającym notyfikacje do subskrybentów.

Nowszym trendem w temacje jest architektura bezserwerowa. Wykorzystuje się w niej wiele małych aplikacji, jeszcze mniejszych niż mikroserwis, które powszechnie nazywa się Lambdami lub funkcjami. Przesuwamy się w ten sposób coraz bardziej od zarządzania serwerami i infrastrukturą do zarządzania aplikacją złożoną w wiele małych, łatwych do zamienienia elementów.

Przypomina Ci to coś?

Proces produkcji

Przyszłość pracy z chmurą

Fajnie. Mamy więc aplikację w mikroserwisach lub nawet lambdach. Dziesiątki lub setki małych serwisów, które komunikują się z sobą asynchronicznie (czyli bezstanowo) czuwają nad sprawnym działaniem całego systemu. A dzięki monitoringowi, jednym rzutem oka sprawdzamy kondycję aplikacji. Ale czy to wszystko na co nas stać?

Oczywiście, że nie! Przynajmniej moim zdaniem. Aktualna zmiana, którą (mam nadzieję) wprowadzają teraz jeszcze ociągające się organizacje, to przesunięcie z zarządzania serwerami na zarządzanie serwisami.

Mikroserwisy

Odpowiedzią na potrzebę zmniejszenia zależności od nudnych zajęć ustawiania sieci, uruchamiania maszyn, konfigurowania, pilnowania, żeby maszyna działa prawidłowo… jest architektura mikroserwisowa lub nawet bezserwerowa. O ile przy mikroserwisach, nadal ocieramy się o zarządzanie serwerami, o tyle pójście w serverless, czyli odejście od utrzymywania serwerów, pozwala bardziej skupić się nad robotą, którą powinniśmy robić.

Mikroserwisy to głównie kontenery. Najpopularniejszy jest oczywiście Docker i wszelkie projekty, które na nim bazują. Jest to Docker Swarm, Mesos lub Kubernetes. Alternatywą jest CoreOS i rkt. Użycie kontenerów ma jedną zasadniczą przewagę nad klasycznym modelem używania serwera. Otóż, po zbudowaniu kontenera, możemy go kopiować w nieskończoność i gdziekolwiek go uruchomimy, otrzymamy dokładnie takie samo środowisko, w którym działa nasza aplikacja. 100% powtarzalności, do komputera programisty, przez środowisko testowe, po produkcyjne.

Jednak mankamentem tego rozwiązania jest to, ze pod spodem musimy nadal obsługiwać serwery (lub maszyny wirtualne), z których każdy z całą pewnością będzie się (mimo, że nieznacznie), różnił. Będzie miał dyski, które będą się przepełniać i psuć. Pamięć ram, która będzie się kończyć. Czyli zwykłe problemy z maszynami.

Serverless!

Natomiast używając samych funkcji (usługa Lambda w AWS), zostajemy sam na sam z kodem i nie interesuje nas to, na jakim serwerze będzie on uruchomiony. No, prawie. Nadal musimy wpiąć się w jakąś sieć. Zdefiniować zależności. Możliwe, że podłączyć do bazy danych. Będziemy musieli też przyznać naszej funkcji jakieś uprawnienia (np. dostęp do S3). Kiedy jednak to wszystko będzie już za nami, zajmujemy się tylko naszym serwisem.

Nie obędzie się jednak bez minusów. Serverless (jak i mikroserwisy) jest bardzo pociągającą ideą, wręcz wyzwalającą z kajdan. Jednak przyjdzie nam za to zapłacić oddaniem kontroli. Nie mamy już dostępu do serwerów, więc nici z logów – musimy logować do innego serwisu. Lambda to mała funkcja, która powinna działać bardzo szybko. Za czas procesora w końcu płacimy. W odróżnieniu do mikroserwisu, naszych funkcji, spełniających małe, konkretne zadania, będzie dużo (serio), dużo więcej. Sposób działania aplikacji natychmiast przechodzi ze złożonej, dobrze naoliwionej maszyny, w „to skomplikowane”.

Utrzymując naszą aplikację, czy to w architekturze mikroserwisów, czy bezserwerowej, będziemy zmuszeni utrzymać dodatkowe serwisy wspierające agregację logów i monitoring. Bez tych dwóch rzeczy, nie będziemy mogli zmierzyć, ani zobaczyć co się dzieje w naszym systemie.

Kolejnym krokiem do przodu, moim zdaniem, będzie zarządzanie danymi, zamiast serwisami.

Zarządzadnie danymi

No dobra, ale co ja w ogóle gadam? Że niby serwery przestaną być potrzebne?

Nie. Serwery nadal będą potrzebne. I te fizyczne, i maszyny wirtualne. Jednak uważam, że dla większości z nas, przesunie się punkt, którym będziemy najbardziej zainteresowani. A mianowicie, czy aplikacja działa jak byśmy sobie tego życzyli, czy użytkownicy są zadowoleni, jaki jest procent konwersji (np. sprzedaży w stosunku do ilości użytkowników na stronie). Zmiany będziemy dokonywali raczej modyfikując dane aplikacji, zamiast sam kod. Na przykład, douczając nasz program, jakie zachowania są pożądane, a jakie nie.

Już teraz widzę trend odchodzenia od konieczności logowania się do serwerów i uważam, że to jest dobry kierunek rozwoju i trend bardziej się pogłębi.

Blockchain

Powstanie Bitcoina wywołało sporo zamieszania. Sam Blockchain, o którym muszę dowiedzieć się znacznie więcej, niż wiem teraz, jest fascynującą technologią. Jej rozwój jest w miarę dynamiczny i powstało kilka ciekawych projektów opartych właśnie na Blockchainie.

Prócz samych wirtualnych pieniędzy, Blockchain może być wykorzystany do wielu innych zastosowań. Przykładowo projek Sia bazuje na udostępnianiu miejsca serwerowego (jak w bucketach S3), dzięki czemu możemy zarabiać. U podstaw projektu leży właśnie Blockchain. Technologię tą potencjalnie można zaprząc do wielu różnych rzeczy: rosproszona baza danych, transakcje oparte o akcje użytkownika, ustalenie prawdziwości informacji.

Uczenie maszynowe

Rozwiązywanie problemów technologicznych stanie się coraz bardziej skomplikowane, nie łatwiejsze. Przez to, potrzebujemy nowych narzędzi do ich rozwiązania. Uczenie maszynowe (Machine Learning) może nam pomóc rozwiązać to, co zajęło by lata przy użyciu standardowych metod… czyli po prostu tworzenia algorytmów. Wyobraź sobie, że piszesz algorytm do gry w szachy. Skomplikowanie kodu rosło by wręcz wykładniczo przy nanoszeniu każdego jednego możliwego przypadku. Wręcz niewyobrażalne jest napisanie programu, który potrafi grać w Go. A jednak, dzięki uczeniu maszynowemu, komputer potrafił, nie tylko grać, ale i wygrać w obie gry.

W czym może nam jeszcze pomóc uczenie maszynowe?

  • rozpoznawanie mowy
  • rozpoznawanie obrazów
  • generowanie głosu bardzo podobnego do ludzkiego
  • rozpoznawanie słów z wideo
  • samoadaptujące się systemy – inteligentny dom, zmniejszenie zużycia energii
  • rozpoznawanie możliwych ataków na nasz serwer

Więcej zastosowań nadal odkrywamy.

Oddanie kontroli nad systemami

W konsekwencji, sądzę, że fizyczne serwery będą coraz bardziej przykrywane warstwami abstrakcji. W dobie automatyzacji, same centra danych mogą (i na pewno w końcu zostaną) zostać wyposażone w roboty dokonujące utrzymania infrastruktury fizycznej. Człowiek będzie na pewno jeszcze jakiś czas konieczny do wykonywania bardziej wymagających rzeczy, których maszyny jeszcze nie będą potrafiły zrobić.

Na wyższym poziomie, przy utrzymaniu aplikacji, możemy dojść do punktu, gdy z aplikacją będziemy komunikować się głosowo, prosząc o jakieś dane, dodając parametry, co z tymi danymi zrobić i tak dalej. Brzmi jak obrazek ze Star Treka? Dla mnie, owszem. Takie programy już powstają: Google Home, Amazon Alexa, Microsoft Cortana, Apple Siri.

Owszem, te programy uczące się muszą zostać przez kogoś napisane, ale pamiętaj, że czas rozwoju się skraca i przewiduję, że będzie potrzebnych mniej programistów, aby podobne programy rozwijać.

Poniżej jeden slajd z webinaru Google na temat Machine Learning obrazujący jak bardzo im się skrócił czas rozwoju oprogramowania przy zastosowaniu ML.

Machine Learning

Więcej na temat przyszłośći IT:

Wszyscy umrzemy!

To na pewno! Ale najpierw zmniejszy nam się zapotrzebowanie na administratorów, później  „zwykli” programiści pójdą bardziej w stronę wielozadaniowości (DevOps!), w końcu zacznie się zmniejszać ilość takich specjalistów, bo nie będzie ich już tylu potrzebnych.

Co zrobić? Moim skromnym zdaniem, już teraz powinniśmy specjalizować się w zakresie uczenia maszynowego i uważnie obserwować trendy. Być może za 10 lat okaże się, że jednak trzeba uczyć się komputerów kwantowych, kto wie?

Póki co, spokojnie. To się zbyt szybko nie zmieni.

Myślisz, że mam rację? Może absolutnie się mylę? Napisz w komentarzu co o tym myślisz! 🙂

Podobne

Kiedy warto migrować do chmury?
przeczytano 28
W stronę Amazon Web Services, Google Cloud Engine i Microsoft Azure, czołowych graczy w branży rozwiązań popularnie zwanych chmurami, spogląda coraz w...