Azure, AWS czym tak naprawdę jest chmura?

3

Witam,

Zacząłem swoją przygodę z AWS. I tak się zastanawiam czym tak naprawde jest ta chmura? Czy naprawdę to jest coś czego nie było wczesniej? Czy ktoś z marketingu trochę przegiął pałe z nazewnictwem? Bo dla mnie to w dalszym ciągu nie jest to nic nowego. Zbiór web serviców, które nazwali chmura. Nic nowego jak dla mnie. Jedynie co zauwazyłem jak do tej pory to prostota w uzywaniu. Czy ktoś stworzył coś czego tak naprawde nie ma? Albo było już używane 30 lat temu tylko chce teraz na tym zarobic. Na niewiedzy ludzi?

6

Jak dla mnie to głównie wynalazek marketingowy. Serwer brzmi technicznie i odstraszająco, a chmura jest mięciutka i przytulna.
Może być w tym pewna innowacja, jeśli nie mówimy o pojedynczym serwerze tylko całym ich zespole, chociaż wtedy wolałabym, żeby to nazywali rojem (ale j.w.).

IMHO: podobna sytuacja jak z katalogiem nazywanym obecnie zazwyczaj folderem.

title

2

Nie chcę się wypowiadać technicznie, ale tak na chłopski rozum, z punktu marketingowego "co końcowy użytkownik dostaje" to zaletą chmur miało być chyba to, że dane są wszędzie, więc się nie utracą jak jeden serwer padnie, i w ogóle jak jeden serwer padnie, to drugi przejmie.

Tylko, że ironią jest to, że większość chmur jest pod kontrolą wielkich korporacji, które mogą w każdej chwili wyłączyć dane konto (cenzura polityczna, przypadkowy ban, zakończenie świadczenia usługi, zmiana regulaminu itp.), więc o ile może od strony technicznej chmury są jakoś inaczej rozwiązane niż zwykły serwer (nie chcę już wnikać), to od strony użytkownika zasada jest taka sama - zaufasz jakiejś jednej konkretnej firmie i trzymasz dane na ich serwerach, dopóki ci pozwolą i dopóki sami będą w stanie to robić (czyli dopóki nie nastąpi awaria chmury, bo wtedy nastąpi koniec internetu).

Czyli ta mityczna "chmura" to dzisiaj taki single point of failure trochę, jak na ironię. Ufając chmurze musisz po prostu zaufać jakiejś wielkiej korporacji, która będzie trzymała twoje dane gdzieś i mieć nadzieję, że nie dostaniesz bana, ani nie zmienią regulaminu w przyszłości itp.

3

No nie wiem czy 30 lat temu mogłeś sobie wydzierżawić serwer na godziny tworząc go w dowolnym momencie, i w dowolnym momencie kasując, dostając Grupę Autoskalującą, która inteligentnie dostawia i usuwa instancje, i Load Balancer, który rozdziela przychodzący ruch. Albo od ręki postawić sobie bazę danych dowolnego typu, z dowolnym schematem. Albo po prostu dostępną z różnych miejsc na świecie przestrzeń dyskową. I co ważne, nie mogłeś sobie wtedy zautomatyzować działań związanych ze stawianiem i usuwaniem tych serwerów, wgrywaniem na nie obrazów itp.

Tak w ogóle chmura to element zjawiska, które stosunkowo niedawno pojawiło się w biznesie, i dotyczy nie tylko świata IT, ale wszystkiego: samochodów, mieszkań, programów, filmów, żywienia - chodzi o to, że odchodzi się od kupowania przedmiotu, na rzecz kupowania usługi korzystania z tego przedmiotu. Oczywiście usługi zawsze były, ale nigdy nie były tak wygodne jak dziś. Gdybyś chciał wynająć serwer 30 lat temu, musiałbyś wpierw wysłać zapytanie określając dokładnie wymogi i okres korzystania, musiałbyś czekać na odpowiedź potwierdzającą dostępność, ewentualnie nagiąć się do terminów i zapłacić z góry. Pewnie po tygodniu mógłbyś wreszcie skorzystać, ale bez możliwości przedłużenia, bo już pewnie ktoś inny czekałby w kolejce.

1

Noo tak nieby masz skalowalność, ale to tylko dlatego, żę np AWS bardzo dużo zdzierają kasy za procesor czy pamiec. To nie lepiej od razu wykupić dobry serwer i nie skalowac w ogole? A samo VPC to jest tworzenie hostingu dla aplikacji internetwoje. Wybierasz OS, procesor i pamiec. To wszystko. Dla mnie to głupota. Np moja firma płaci ponad 50 000zł miesiecznie za AWS. Zdzierstwo.

1
GutekSan napisał(a):

No nie wiem czy 30 lat temu mogłeś sobie wydzierżawić serwer na godziny tworząc go w dowolnym momencie, i w dowolnym momencie kasując

Pewnie nie, ale wirtualizacja nie jest tożsama z rozproszeniem.

A 30-40 lat temu mogłeś używać np światowej sieci Usnetu, gdzie post wysłany na jeden serwer był następnie kolportowany na kolejne i nikt nie nazywał tego chmurą Usenetu tylko siecią sewerów usnetowych. Podobnie w przypadku serwerów DNS nikt nie mówił, że adresy stron WWW przechowywane są w chmurze tylko na serwerach DNS.

2

A 30-40 lat temu mogłeś używać np światowej sieci Usnetu, gdzie post wysłany na jeden serwer był następnie kolportowany na kolejne i nikt nie nazywał tego chmurą Usenetu tylko siecią sewerów usnetowych. Podobnie w przypadku serwerów DNS nikt nie mówił, że adresy stron WWW przechowywane są w chmurze tylko na serwerach DNS.

Porównanie takie jak smartfonów z ebonitowymi telefonami z tarczą. No bo przecież z obu można dzwonić...
Usenet nie był chmurą, bo nie oferował takich usług jak obecnie oferują chmury. Oferował jedną usługę - rozpropagowywania emali do subskrybentów hierarchicznych grup dyskusyjnych. DNS też przecież nie oferuje tego co chmura, więc nie rozumiem zupełnie tego porównania.

1
poniatowski napisał(a):

To nie lepiej od razu wykupić dobry serwer i nie skalowac w ogole? A samo VPC to jest tworzenie hostingu dla aplikacji internetwoje. Wybierasz OS, procesor i pamiec. To wszystko. Dla mnie to głupota. Np moja firma płaci ponad 50 000zł miesiecznie za AWS. Zdzierstwo.

A moja firma potencjalnie potrzebuje tysiące odosobnionych środowisk, które muszą być stawiane ad hoc, pełniących role serwisów, build-serwerów, workerów dla Jenkinsa. Ma do tego kupować tysiące maszyn, które trzeba utrzymywać, płacić za prąd itp? Nikt by nawet nie zapanował nad tym, kto z czego w danym momencie korzysta.

Jedyna korzyść z własnych serwerów to serwery z GPU. Przynajmniej nam wyszło, że opłaca się samemu stworzyć farmę obliczeniową niż korzystać z tego typu obliczeń w chmurze.

2

@poniatowski:

To nie lepiej od razu wykupić dobry serwer i nie skalowac w ogole?

Czasem przez 90% czasu potrzebujesz X zasobów, ale na peaku potrzebujesz 2X to możesz sobie to ot tak podnieść, a później obniżyć.

Więc po co płacić za 2X cały czas?

Na bare metalu raczej tak nie zrobisz, co wcale nie oznacza, że twoja firma nie daje się ""dymać"" :P

0

A moja firma potencjalnie potrzebuje tysiące odosobnionych środowisk, które muszą być stawiane ad hoc, pełniących role serwisów, build-serwerów, workerów dla Jenkinsa. Ma do tego kupować tysiące maszyn, które trzeba utrzymywać, płacić za prąd itp? Nikt by nawet nie zapanował nad tym, kto z czego w danym momencie korzysta.

Coo? Przeciec w niemal, że każdym hostingu można teraz utworzyć nowe środowisko przeklikując kilka opcji. Nie kumam, ktoś może?

2

Cloud to buzzword żeby brzmiało nowocześnie, innowacyjne i dobrze się sprzedawało. Co oczywiście w żadnym stopniu nie ujmuje wadom i zaletom takiej "technologii".

0
GutekSan napisał(a):

Usenet nie był chmurą, bo nie oferował takich usług jak obecnie oferują chmury.

A "chmurowość" jest definiowana przez rodzaj usług czy przez strukturę systemu?

Bo chyba każdą chmurową usługę da się zaoferować w oparciu o pojedynczy serwer lub ew. farmę serwerów, jeśli potrzebna jest duża moc obliczeniowa.

0
Freja Draco napisał(a):

A "chmurowość" jest definiowana przez rodzaj usług czy przez strukturę systemu?

Wg mnie i to i to.
Idąc Twoim tokiem rozumowania, wszystko co oferuje Internet można by nazwać "chmurą", bo sam Internet w jakimś sensie taką chmurę stanowi. Ale w ten sposób tylko mieszamy pojęcia. Dla mnie "chmura" jest usługą będącą alternatywą dla jakiegoś istniejącego dotąd rozwiązania "niechmurowego". Przestrzeń dyskowa - dotąd korzystaliśmy głownie z tej na swoim komputerze, ale teraz możesz w chmurze. Baza danych, serwis www - podobnie. "Chmura" dotyczy też usług, które były dotąd postrzegane dość indywidualnie, związanych z konkretną osobą. Usenet czy DNS zaś dotyczył wszystkich.

3

@GutekSan:

Przestrzeń dyskowa - dotąd korzystaliśmy głownie z tej na swoim komputerze, ale teraz możesz w chmurze. Baza danych, serwis www - podobnie.

czym te twoje przykłady różnią się od zwykłego "serwera"?

Czy chmura to nie jest po prostu zwykła userfriendly nakładka na serwer oferująca szerokie możliwości do zarządzania?

0
poniatowski napisał(a):

A moja firma potencjalnie potrzebuje tysiące odosobnionych środowisk, które muszą być stawiane ad hoc, pełniących role serwisów, build-serwerów, workerów dla Jenkinsa. Ma do tego kupować tysiące maszyn, które trzeba utrzymywać, płacić za prąd itp? Nikt by nawet nie zapanował nad tym, kto z czego w danym momencie korzysta.

Coo? Przeciec w niemal, że każdym hostingu można teraz utworzyć nowe środowisko przeklikując kilka opcji. Nie kumam, ktoś może?

Mało, ja pracuję przy projektach gdzie w chmurze jest przepalane 400 tys. euro rocznie, a zaraz nam to skoczy do kilku milionów euro rocznie. Wyobraź sobie, że musisz postawić całą poteżną serwerownię i nią zarządzać i np. nauczyć się tego w niecały rok bo wchodzi nowy kontrakt klienta, który nagle wypalił. Nie byłbyś w stanie po drugie po co? Potrzebowałbyś bardzo dużego zaplecza techicznego i ifranstruktury.

Dodatkowo chmura sobie świetnie radzi przy dużych skokach ruchu.

Kolejny problem - provider, który nie jest chmurą publiczną, może nie mieć najzwyczajniej na świecie wystarczająco dużo maszyn aby zapewnić Tobie ciągłość usługi - bo np. wykorzystasz całą jego "mikro" chmurę.

0
WeiXiao napisał(a):

@GutekSan:

Przestrzeń dyskowa - dotąd korzystaliśmy głownie z tej na swoim komputerze, ale teraz możesz w chmurze. Baza danych, serwis www - podobnie.

czym te twoje przykłady różnią się od zwykłego "serwera"?

Czy chmura to nie jest po prostu zwykła userfriendly nakładka na serwer oferująca szerokie możliwości do zarządzania?

Gdyby to była tylko nakładka na serwer, miałaby wciąż wszystkie wady serwera, a nie ma. Bo serwer to serwer - fizyczna maszyna, o którą ktoś musi dbać, upgrejdować HW i SW, dostarczać prąd. Maszyna z dyskiem o ograniczonej pojemności, który również wypadałoby backapować.W chmurze nie musisz się o to martwić.

1

@GutekSan:

Zatem, co jest "pod spodem" jak nie fizyczna maszyna, o którą ktoś musi dbać, upgrejdować HW i SW, dostarczać prąd. Maszyna z dyskiem o ograniczonej pojemności, który również wypadałoby backapować?

wirtualizacja też istniała w czasach "pre-cloud".

0
WeiXiao napisał(a):

@GutekSan:

Zatem, co jest "pod spodem" jak nie fizyczna maszyna, o którą ktoś musi dbać, upgrejdować HW i SW, dostarczać prąd. Maszyna z dyskiem o ograniczonej pojemności, który również wypadałoby backapować?

wirtualizacja też istniała w czasach "pre-cloud".

Ale chodzi o to, że to nie Twój problem "co jest pod spodem".

2

@GutekSan:

no właśnie, bo masz na to nakładkę, albo po programowemu - abstrakcję.

Gość w serwerowni widzi fizyczne sloty na pamięć, wejścia na dyski itd., a ty suwak na stronie

Chyba :D

3
GutekSan napisał(a):

Czy chmura to nie jest po prostu zwykła userfriendly nakładka na serwer oferująca szerokie możliwości do zarządzania?

Gdyby to była tylko nakładka na serwer, miałaby wciąż wszystkie wady serwera, a nie ma. Bo serwer to serwer - fizyczna maszyna, o którą ktoś musi dbać, upgrejdować HW i SW, dostarczać prąd. Maszyna z dyskiem o ograniczonej pojemności, który również wypadałoby backapować.W chmurze nie musisz się o to martwić.

No i to jest właśnie gadanie typowe dla ludzi, którzy wierzą, że chmury zrobione są z chmur :p

Twój wirtualny serwer nadal chodzi na fizycznym serwerze albo famie serwerów. A o te fizyczne serwery nadal ktoś musi dbać i dostarczać prąd a jej dyski mają ograniczoną pojemność. A postawione na tym wirtualne serwery również trzeba upgrejdować, aktualizować itp. Wirtualizacja (którą z niezrozumiałych dla mnie powodów utożsamiasz z chmurą) dodaje do tego tylko kolejną warstwę abstrakcji i oferuje użytkownikowi większą elastyczność.

3
GutekSan napisał(a):

Ale chodzi o to, że to nie Twój problem "co jest pod spodem".

Kupując fizyczny, dedykowany (albo i nawet współdzielony) serwer również nie musisz się martwić o to co jest pod spodem, bo umowa może zakładać, że admini serwerowni dbają o takie sprawy, a ty po prostu używasz.

4
WeiXiao napisał(a):

@GutekSan:

no właśnie, bo masz na to nakładkę, albo po programowemu - abstrakcję.

Gość w serwerowni widzi fizyczne sloty na pamięć, wejścia na dyski itd., a ty suwak na stronie

Chyba :D

No niby tak ale nie do końca. Bo fizyczna infrastruktura robiąca public clouda jest **ciutkę **bardziej skomplikowana niż serwer czy nawet klaster serwerów w on-premises. Usługi które tworzą public clouda w większości przypadków są georedundantne i najpewniej mogą wyłączyć jedno datacenter w regionie i dalej uciągnąć usługę bez większych problemów. Aby osiągnąć jakkolwiek porównywalny poziom dostępności na własnej infrastrukturze musiałbyś zainwestować grube miliony.

0
AlexPawlak napisał(a):

Gość w serwerowni widzi fizyczne sloty na pamięć, wejścia na dyski itd., a ty suwak na stronie

Chyba :D

No niby tak ale nie do końca. Bo fizyczna infrastruktura robiąca public clouda jest **ciutkę **bardziej skomplikowana niż serwer czy nawet klaster serwerów w on-premises. Usługi które tworzą public clouda w większości przypadków są georedundantne i najpewniej mogą wyłączyć jedno datacenter w regionie i dalej uciągnąć usługę bez większych problemów.

I to jest wreszcie jakaś sensowna argumentacja, z którą mogę się zgodzić.

Aby osiągnąć jakkolwiek porównywalny poziom dostępności na własnej infrastrukturze musiałbyś zainwestować grube miliony.

Niekoniecznie miliony. Samo rozrzucanie ruchu z domeny po różnych IP to jeszcze nie są cuda na kiju. Natomiast dbanie o synchronizację zawartości kilku różnych serwerów, jeśli byłaby ona modyfikowana przez samych użytkowników) faktycznie wymagałoby już trochę zachodu.

0
Freja Draco napisał(a):
GutekSan napisał(a):

Ale chodzi o to, że to nie Twój problem "co jest pod spodem".

Kupując fizyczny, dedykowany (albo i nawet współdzielony) serwer również nie musisz się martwić o to co jest pod spodem, bo umowa może zakładać, że admini serwerowni dbają o takie sprawy, a ty po prostu używasz.

Ale przecież admini serwerowni to moi admini, a nie admini sprzedającego mi ten serwer, więc de facto to wciąż moje zmartwienie.
Poza tym chmura to nie jeden serwer, tylko usługa serwerowa. Serwer ma cały czas wady serwera, może mu się procesor spalić, dysk paść, itp. Jeśli maszyna padnie w momencie gdy z niej korzystam to mam problem. Jeśli padnie fizyczna maszyna w chmurze, to utracę połączenie, ale po kolejnym połączę się z inną.

1

Czyli co, zanim nie było clouda, to topowi gracze na rynku hostingów nie mieli mirrorów w innych swoich serwerowniach?

Warsaw, Paris, Frankfurt, us-east, us-west, itd.

Czy po prostu było to tylko w ramach kontraktu, a nie "must have"?

1

@GutekSan:

W przypadku fizycznej awarii sprzętu - masz serwery wirtualizacji - jeśli jest poprawnie zrobione HA w klastrze - też się połączysz po chwili, być może z restartem guest OS po drodze. IaaS na cloudzie nie będzie się różnić pod tym względem, czarów nie ma - jak kupujesz VMkę to też czasem się musi przenieść na innego hosta. Jeśli chodzi o PaaS / SaaS to już ryzyko jest dużo mniejsze - wtedy dostawca odpowiada za całą infrastrukturę która najczęściej jest skonteneryzowana i odporna na awarie do pewnego stopnia

0
Freja Draco napisał(a):

Niekoniecznie miliony. Samo rozrzucanie ruchu z domeny po różnych IP to jeszcze nie są cuda na kiju. Natomiast dbanie o synchronizację zawartości kilku różnych serwerów, jeśli byłaby ona modyfikowana przez samych użytkowników) faktycznie wymagałoby już trochę zachodu.

Żeby nie było, że tylko chwalę chmurę, akurat synchronizacja w AWS to nie jest coś na czym można polegać. Amazon nie daje żadnej maksymalnego czasu na to, by dane wrzucone na S3 zostały rozpropagowane na wszystkie instancje. W efekcie tak naprawdę nie ma gwarancji spójności danych.

1
WeiXiao napisał(a):

@GutekSan:

Zatem, co jest "pod spodem" jak nie fizyczna maszyna, o którą ktoś musi dbać, upgrejdować HW i SW, dostarczać prąd. Maszyna z dyskiem o ograniczonej pojemności, który również wypadałoby backapować?

wirtualizacja też istniała w czasach "pre-cloud".
Dokładnie, to nic nowego. Nie wiem o co tyle szumu.

0

Wydaje mi się, że Cloud to głównie zmiany od strony klienta, że jest to userfriendly, bierzemy co chcemy, bierzemy ile chcemy, kiedy chcemy itd., tak jakbyśmy zwykłe zakupy przez internet robili, a nie składali zamówienie w jakiejś serwerowni na szafę z X maszynami.

Chociaż obstawiam, że rozwój Clouda miał również duży wpływ na rozwój hardware (np. procesory AMD Epyc) oraz systemów ratowania tyłka - backupów / replikacji pomiędzy serwerowniami itd.

2

Ja bym zajrzał na wiki.
https://pl.wikipedia.org/wiki/Chmura_obliczeniowa
https://en.wikipedia.org/wiki/Cloud_computing
Szybciej uzgodnicie definicje i dyskusja potoczy się dalej.

0 użytkowników online, w tym zalogowanych: 0, gości: 0