Azure, AWS czym tak naprawdę jest chmura?

Odpowiedz Nowy wątek
2019-08-10 17:12
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?

Pozostało 580 znaków

2019-08-10 21:02
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.

Pozostało 580 znaków

2019-08-10 21:08
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.


edytowany 1x, ostatnio: Freja Draco, 2019-08-10 21:09

Pozostało 580 znaków

2019-08-10 21:10
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ą.

Nie mówię o sytuacji, kiedy stawiasz sobie własną serwerownię, tylko kupujesz gotową usługę. - Freja Draco 2019-08-10 21:23

Pozostało 580 znaków

2019-08-10 21:13
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"?

edytowany 1x, ostatnio: WeiXiao, 2019-08-10 21:14

Pozostało 580 znaków

2019-08-10 21:13
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

Między serwerem, który stoi u mnie pod biurkiem, a chmurą jest szereg rozwiązań pośrednich, takich jak właśnie serwery wirtualizacji, automatyczne backupy, itp. Chmura nie jest rewolucją tylko ostatnim etapem ewolucji. - GutekSan 2019-08-10 21:32

Pozostało 580 znaków

2019-08-10 21:16
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.

Pozostało 580 znaków

2019-08-10 21:22
1
WeiXiao napisał(a):

@GutekSan:

Zatem, co jest "pod spodem" jak niefizyczna 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.

Pokaż pozostałe 13 komentarzy
@poniatowski: zależy jakiego rodzaju biznes prowadzisz. Jak masz 10 mikroserwisów to pewnie lepiej kupić sobie te serwery. U mnie jest wiele systemów, które same mają po kilkadziesiąt mikroserwisów, i każdy taki system trzeba postawić kliknięciem. Liczba wszystkich mikroserwisów idzie w tysiące. Nikomu nie chciało by się bawić w ręczne zarządzanie czymś takim. - GutekSan 2019-08-10 21:49
Wy się chyba nie rozumiecie :D Gutkowi chodzi o komfort użycia, stawianie 1 kliknięciem itd, a poniatowskiemu o nowości / rozwój technologii pod spodem, nie wiem - "nextGen virtualization", czyli frontend i backend :D Przynajmniej ja to tak rozumiem - WeiXiao 2019-08-10 21:52
Fakt, zgadzam się. Tylko nie wiem po co nazwa chmura i czemu tooo takie drogie. Dla mnie to troche zdzierstwo. Za wszsytko placisz. Nawet za takie rzeczy tj cloudtrail. - poniatowski 2019-08-10 21:53
@poniatowski: powiem tak: z punktu widzenia Radomia wybudowanie tam lotniska też wydaje się drogie. Ale już w Londynie czy Pekinie nie ;) Drogie to pojęcie względne. - GutekSan 2019-08-10 21:57
@GutekSan: https://news.ycombinator.com/item?id=19246668 Pinterest, which had paid in advance for AWS’s services, had to buy additional capacity at a higher price. That contributed to Pinterest spending roughly $190 million on AWS last year, $20 million more than it had initially expected, according to a person close to the company and figures seen by The Information. pewnie tanio :P - WeiXiao 2019-08-10 21:58

Pozostało 580 znaków

2019-08-10 21:31
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.

edytowany 7x, ostatnio: WeiXiao, 2019-08-10 21:39
Ale replikacje były juz kiedyś, bez chmur. Robisz mirror i listener, jak pada jeden serwer podłączasz drugi. Oczywiscie wiecej zabawy niż teraz. Ale chodzi, ze to nic nowego. - poniatowski 2019-08-10 21:33
chodziło mi, że te rzeczy się pewnie bardzo rozwinęły wraz z popularyzacją Clouda (no procesory amd też były wcześniej, ale nie tyle corów :P) - WeiXiao 2019-08-10 21:35
Nie było prawda, ale hostingi też używają tych procesorów amd. Więc dalej nie ma różnicy. - poniatowski 2019-08-10 21:36
czego nie było? jeszcze raz, chodzi mi o to, że cloud wpłynął rozwój tych istniejących narzędzi np. do replikacji/backupów, ale tylko obstawiam. - WeiXiao 2019-08-10 21:38

Pozostało 580 znaków

2019-08-10 22:09
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.

W zasadzie słusznie, tylko, że w myśl zawartych tam definicji, to nawet dedyk jest chmurą. Czyli wychodzi, że to po prostu kolejne nowe słowo na nazywanie starych rzeczy, jak np. modna obecnie "sztuczna inteligencja". - Freja Draco 2019-08-10 22:14

Pozostało 580 znaków

2019-08-11 18:33
9

Nie rozumiem Twojej argumentacji @poniatowski.

Piszesz, że wszystko było kiedyś, a "chmura" to nic nowego. Wskaż mi proszę, gdzie kiedyś miałeś wirtualizację używaną na szeroką skalę? Stosowanie wirtualek jako nakładek na fizyczne serwery zaczęło się na dobre jakieś 15lat temu, a praktycznie zaraz po tym raczkować zaczął AWS. Przypuszczam, że sam rozwój AWSa i kolejnych dostawców chmurowych wymusił na serwerowniach uderzanie w stronę IaaS.

To co chmura Ci daje, to redundantność, szybkość reakcji na zmiany, elastyczność, teoretycznie mniejsze koszty i usługi zarządzane. To nie są takie łatwe pojęcia jak Ci się wydaje. Chmura nie jest od tego żeby wprowadzać nowości, chociaż w cholerę fajnych rzeczy wprowadzili, ale od tego żeby agregować wszystkie przydatne i używane funkcje w jedno, łatwo dostępne w krótkim czasie miejsce. Kiedyś jak chciałeś serwer to trzeba się było określić z parametrami, zamówić, miałeś szczęście jak było miejsce w serwerowni żeby wstawić kolejną szafę jeśli była potrzebna, czekać tygodniami, płacić za wszystko z góry i byłeś uwiązany z tym serwerem na dłuższy czas. A gdzie tu jeszcze spięcie tego w sieć, wystawienie publicznie przez jakiś load balancer. Dobrze jeśli wiedziałeś, jaki serwer Ci potrzeba i na ile. A co będzie jak Twoja strona urośnie w pół roku ponad to co się spodziewasz i jednak trzeba ją dalej skalować? A jeśli nie da się wszerz i trzeba wymienić serwery na mocniejsze? Jeśli baza nie wyrabia i trzeba ją postawić na czymś mocniejszym? No to dawaj, zabawa w zamawianie od początku. Jeśli Ci potrzeba High Availability i potrzebujesz mieć dwa osobne data centry, żeby w razie jak jedno padnie to drugie przejęło ruch? Spięcie tego razem to już nie jest proste. Możesz sobie rozprowadzić ruch między te dwie lokacje, ale co będzie jak jedna padnie a druga nie wyrobi z ruchem? Nie zeskalujesz tego bo nie masz jak. Z chmurą, się da. Padnie Zone lub Region to startujesz w innym ze skryptów i działasz dalej.

Wszystkie technologie takie jak replikacja, HA i inne były już wcześniej. Ale nigdy nie było to tak proste, tak szybkie i tak łatwo dostępne.

Ale w jednym się z Tobą zgodzę, chmury są drogie. Zwłaszcza jeśli nie wiesz jak ich używać. Za wszystko płacisz, bo wszystko kosztuje albo jest to sprzęt na którym to działa, albo ktoś do zarządzania albo know how jak to zrobić. To jak w tym kawale o gościu który przyszedł, puknął młoteczkiem, naprawił i wziął 10010 zł - 10 zł za puknięcie a 10000 zł za to że wiedział gdzie puknąć. Jeśli płacicie $50k za usługi w AWSie to prawdopodobnie na bare metalu wyjdzie to dużo taniej. Ale jednak ktoś stwierdził, że albo nie ma na to czasu, albo ludzi którzy by to mogli zrobić i później utrzymywać albo właśnie potrzeba elastyczności i szybkośći. W Polsce jest tendencja do patrzenia jak zrobić coś tanio i hur dur bo AWS drogi, w innych krajach mają inne priorytety, wolą zapłacić $10k miesięcznie więcej ale mieć pewność, że w razie problemów są w stanie postawić zastępcze środowisko w przeciągu godziny. Business continuity jest też ważne dla niektórych firm. Jeśli teoretyczna godzina down time'u kosztuje $100k i stratę reputacji to firma woli zapłacić więcej, żeby mieć zabezpieczenie.
Sam byłem świadkiem właśnie czegoś takiego. Globalna firma z serwerami on-premises, miała awarię, nie zadziałały zabezpieczenia, nie zadziałały zabezpieczenia zabezpieczeń i fuckup trwał dobrze ponad tydzień zanim się udało wszystko postawić na nogi. Straty były ogromne, idące w miliony. Wtedy właśnie została podjęta decyzja, że robią migrację do chmury.
Jeśli chcesz zrobić Lift and Shift i liczysz na to, że w chmurze będziesz miał tanio to się przeliczysz. To nie ten model działania. Wirtualki są drogie w AWS, Azure czy tam Google Cloud. Chcesz tanio to nie ma problemu ze znalezieniem hostingu, który oferuje same serwery np. Digital Ocean, Vultr itd i masz 6x taniej niż AWS. Masz elastyczność za dużą mniejszą cenę. To jest problemem chmur, tanie są te usługi, których oni chcą, żebyś używał. Przeważnie są to usługi, które wiążą Cię z tym konkretnym dostawcą. Usług nie da się przenieść na inne chmury bez przepisania połowy aplikacji.

edytowany 1x, ostatnio: schizo85, 2019-08-11 19:05
Dobra wypowiedz - poniatowski 2019-08-11 18:41
Co do samych kosztów - ludzie często nie mają wiedzy odnośnie ich optymalizacji w chmurze i zwyczajnie marnują zasoby... Przykładów jest ogrom ale chociażby rozwiązania serverless - jeśli masz api, które jest używane stosunkowo rzadko i do tego mogą być duże skoki ruchu to serverless może wyjść duuużo taniejn iż jakaś VM (płacisz za ruch, a nie za stojącą 24h VM która nic nie robi) ale niektórzy i tak postawią VM, bo nie wiedzą albo nie myślą o takich rzeczach. Tak samo z całą infrastrukturą... - FlatEarther 2019-08-16 16:37

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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