Czym różni się „przetwarzanie w chmurze” od „klient-serwer”?

Obserwując CEO nowej firmy zajmującej się chmurą, opisującej swoją firmę w programie finansowym dla telewizji, powiedział coś w stylu „Chmura jest lepsza niż staromodne obliczenie klient-serwer”.

Teraz jestem zdezorientowany. Czy ktoś może wyjaśnić, co oznacza „przetwarzanie w chmurze” w przeciwieństwie do klient-serwer?

O ile rozumiem, przetwarzanie w chmurze jest bardziej modelem usług sieciowych, na przykład nie posiadam ani nie utrzymuję fizycznego sprzętu. „Chmura” to wszystko zaplecze. Ale nadal mogę mieć aplikację, która komunikuje się ze środowiskiem „chmurowym”. A jeśli uruchomię witrynę internetową, która zawiera formularz, który użytkownik wypełnia, naciska przycisk na stronie i zwraca raport wygenerowany przez serwer internetowy, czy to nie to samo, co przetwarzanie w „chmurze”? I czy nie uważałbyś mojej przeglądarki za „klienta”?

Pamiętaj, że moje pytanie jest specyficzne dla pojęcia „przetwarzania w chmurze” w odniesieniu do „klient-serwer”.

Przepraszamy, jeśli jest to nieodpowiednie pytanie dla tej witryny; jest to najbliższy w stosie i to jest mój pierwszy raz tutaj. Jestem starym timerem, programuję od czasów komputerów mainframe pod koniec lat 70-tych.

Ściśle mówiąc, nie ma „chmury”. Nie w tym, co mówił ten CEO. Oczywiście jest Internet. Istnieją usługi hostowane. Są VPS. Istnieją systemy dostarczania treści. My (technicy) dostosowaliśmy się do tego terminu, aby odwoływać się do niektórych modeli usług hostowanych. Ale „chmura” w mediach konsumenckich jest w dużej mierze terminem marketingowym tłumaczonym luźno jako „internet”. Częściej niż nie oznacza to również, że „obciążę cię do miesiąca”.

Masz rację, że te dwa terminy, „chmura” i „klient-serwer” nie są ze sobą powiązane. Posiadanie usługi hostowanej „w chmurze” (zawsze chcę dodać dramatyczny „dun-dun-daaaaaaa” po użyciu tego wyrażenia) nie powoduje, że aplikacja klient-serwer jest mniej klient-serwer-y. Na przykład „sieć” wykorzystuje przede wszystkim model klient-serwer. Przeglądarka internetowa jest klientem. Serwer WWW to serwer. To, że serwer sieciowy jest hostowany „w chmurze”, nie zmienia faktu, że relacja między przeglądarką a serwerem sieciowym jest klient-serwer.

Zatem termin klient-serwer definiuje relację między dwoma podmiotami w systemie. Nie ma znaczenia, gdzie jednostki są fizycznie hostowane.

Zasadniczo masz rację. Te dwa nie są porównywalne.

„Przetwarzanie w chmurze” to ogólny termin mający na celu zrobienie dwóch rzeczy: po pierwsze, aby streścić wszystkie możliwe zastosowania modelu klient-serwer za jednym terminem, w przeciwieństwie do bardziej szczegółowych przypadków użycia, takich jak „serwery plików”, „serwery baz danych”, „serwery sieciowe”, „serwery aplikacji” itp .; po drugie, aby wyodrębnić samą architekturę serwera pod względem sprzętu, topologii, lokalizacji, a nawet własności.

W tradycyjnym modelu klient-serwer, który jest nadal powszechnie używany, klient łączy się z serwerem wykonującym określone zadanie. Na tym serwerze może znajdować się baza danych, seria udziałów plików lub strona internetowa. Gdy klient łączy się z tym serwerem, domyślnie rozumie się rodzaj komunikacji i transmisji danych między dwoma komputerami. Może być również zrozumienie przez klienta lub użytkownika końcowego możliwości sprzętu serwera i jego ograniczeń. To stosunkowo „ścisłe połączenie” między komputerem klienckim a jego serwerem może powodować problemy dla administratora systemu, który musi zdjąć serwer w celu konserwacji; wszystkie aplikacje zależne od zasobów udostępnianych przez ten serwer muszą być skierowane na inny serwer,

W modelu chmurowym sprzęt, topologia, podział pracy, a nawet liczba rzeczywistych zaangażowanych maszyn są wyodrębniane za jednym punktem końcowym. Analogię można odnieść do nowoczesnej „aplikacji internetowej”, w przeciwieństwie do starszych generacji „strony internetowej”, które były bardziej statyczne. Możemy zgadywać, że za kulisami jest serwer aplikacji i serwer DB, ale tak naprawdę nie musimy się tym przejmować; serwer internetowy, jako część swojej pracy polegającej na udostępnianiu pełnej aplikacji użytkownikom spoza „krawędzi”, zapewnia ujednolicony punkt końcowy umożliwiający kontrolowany dostęp do wszystkich danych i usług świadczonych przez inne maszyny za tymi drzwiami wejściowymi.

Rezultatem jest to, że z jednym punktem końcowym ujawnionym w celu zapewnienia funkcjonalności aplikacji, to wszystko, o co klient aplikacji musi się kiedykolwiek martwić, zamiast tego, gdzie uzyskać dane, gdzie wywołać taki i taki zdalny proces aplikacji itp .; oznacza to, że administratorzy i architekci usługodawcy w tej chmurze mają mniej lub więcej swobodę zmiany maszyn, topologii i innych szczegółowych szczegółów implementacji tej „usługi w chmurze”, przy czym klienci nie są mądrzejsi. Facebook mógłby, gdyby uważał to za rozsądne, odbudować cały system przechowywania danych od zera za pomocą innego DBMS i wszystkich nowych serwerów, i dopóki strona pozostanie dostępna podczas przejścia, nikt nie będzie mądrzejszy; w rzeczywistości Facebook robił to właśnie wiele razy,

Kluczową częścią „przetwarzania w chmurze” jest narzędzie do zarządzania wdrażaniem.

W „klasycznych” wdrożeniach zamówiono konkretną maszynę dla określonej aplikacji i wykonano dość stałą konfigurację.

W środowisku chmurowym w puli znajduje się mniej lub bardziej znormalizowany sprzęt oraz interfejs API, który tworzy i konfiguruje na nim maszyny wirtualne z jakiejś formy szablonów. W ten sposób wadliwe systemy można łatwo wymienić, skalować lub zmniejszać w zależności od potrzeb, a sprzęt może być przydzielany w razie potrzeby, na przykład w sposób zautomatyzowany.

Oczywiście właściwi administratorzy też to robili wcześniej, ale oprócz czystego marketingu, istnieje podstawa znormalizowanych API (Aamzons AWS API, który jest również oferowany przez narzędzia takie jak Eucalyptus do „prywatnych chmur”) i pojawiające się narzędzia (tj. Marionetka).

W „tradycyjnej” architekturze klient-serwer masz statycznie przypisane zasoby (lub przynajmniej są one przedstawiane jako takie - nie mam doświadczenia z okresu sprzed chmury, więc popraw mnie, jeśli się mylę i polegam na fałszywym marketingu). Serwer bazy danych nazywał się db.twojafirma.com i twój serwer komunikował się z nim. Jeśli chcesz zwiększyć zasoby, możesz dodać kolejny dedykowany serwer WWW i zapewnić równoważenie obciążenia itp.

Z drugiej strony w chmurze kładziono nacisk na abstrakcję niższych poziomów i oznaczają one budowę „serwera”. Na przykład masz:

• HAAS (Hardware As A Service) - klient (firma) otrzymuje hostowany komputer, na którym może zainstalować dowolny system operacyjny. Różnica polega na tym, że nie „naprawdę” mają komputer, ale maszynę wirtualną na farmie. Ponieważ jest zwirtualizowany, nie muszą dbać o szczegóły niższego poziomu, takie jak ilość mocy obliczeniowej, płacić rachunki niezależnie od tego, czy maszyna jest używana, jak jest podłączona itp
• PAAS (Platform As A Service) - poziom wyżej - piszesz aplikację, która gdzieś działa. Ponieważ interfejs API jest wystarczająco ogólny, dostawcy usług w chmurze mogą alokować zasoby na żądanie, więc jeśli twoja aplikacja zostanie ukośnikowana, będziesz płacić za więcej zasobów, a nie cierpieć z powodu złośliwego DDOS.
• SAAS (Software As A Service) - jeszcze wyższy poziom - nie piszesz aplikacji - korzystasz z niej. Nie obchodzi Cię, w jaki sposób jest wdrażany ani z jakich zasobów korzysta. Jest dostępny wszędzie i o każdej porze.

Należy pamiętać, że chociaż w większości przypadków sugeruje się, że faktyczna usługa jest zlecana dużej firmie (powiedzmy Amazon lub Google), nie jest to konieczne - duże firmy lub uniwersytety wdrażają własne wewnętrzne chmury, aby umożliwić łatwiejsze zarządzanie zasobami. Umożliwia to dodawanie zasobów do aplikacji, które zostaną dodane w razie potrzeby. Jeśli nowy wewnętrzny start się powiedzie, nie muszą się martwić, że serwery zostaną przeciążone. Jednak jako ekonomia skali gra się zwykle tylko wtedy, gdy istnieją specjalne wymagania (na przykład dotyczące bezpieczeństwa).

Z punktu widzenia użytkownika jest przezroczysty i ma wygląd architektury klient-serwer. Serwer WWW może żyć „w chmurze”, używając zwykłego starego protokołu HTTP. Problemy i rozwiązania pomysłów faktycznie sięgają wstecz do komputerów z lat 50. i obecnie powracają bardziej jako kontrast do grubych komputerów klienckich.

Powiedziawszy, że może to być również modne hasło w danym zdaniu, stwierdzając, że firma jest dynamiczna i koncentruje się na swoich podstawowych kompetencjach, jednocześnie umożliwiając swoim pracownikom.

Czy ktoś może wyjaśnić, co oznacza „przetwarzanie w chmurze” w przeciwieństwie do klient-serwer?

To zależy od twojej perspektywy. Dla firm przetwarzanie w chmurze jest dobre, ponieważ (zazwyczaj) pozwala być bardziej elastycznym w stosunku do liczby maszyn obsługujących twoje usługi. Ta elastyczność pozwala być bardziej responsywnym, co powinno zaoszczędzić pieniądze. Firmy mogą również skorzystać z możliwości tworzenia kopii zapasowych przez dostawcę chmury, odzyskiwania po awarii, bezpieczeństwa fizycznego i wszystkich innych elementów infrastruktury, z którymi nie chcą sobie poradzić. Zwykle prowadzi to do oszczędności i lepszej jakości.

Z punktu widzenia konsumenta poprawa jakości i niezawodności połączenia jest dobra. Niektórzy dostawcy usług w chmurze pomagają również w dystrybucji serwerów, aby pomóc konsumentom w opóźnieniu.

Dla programistów ... jest to prawie programowanie klient-serwer, w którym dostęp do serwera jest trudny, a czasami trzeba użyć specjalistycznych interfejsów API.

Myślę, że można uczciwie powiedzieć, że „przetwarzanie w chmurze” i „klient-serwer” są bardzo podobne. Z mojego punktu widzenia przetwarzanie w chmurze wydaje się polegać bardziej na serwerze niż na modelu „klient-serwer”. Teoretycznie niektóre formy przetwarzania w chmurze mogą się zdarzyć niezależnie od połączenia klienta. Korzyści płynące z aplikacji działającej tylko w chmurze bez komunikacji z klientem nie wydają się bardzo pomocne, dlatego warto stworzyć jakąś formę komunikacji z klientem na tym serwerze.

Zasadniczo myślę, że zależy to głównie od tego, gdzie odbywa się większość mocy obliczeniowej. Serwer ma ogólnie lepszą specyfikację pod względem sprzętu i mocy obliczeniowej niż standardowy komputer użytkownika, aby po prostu zarządzać wieloma połączeniami klientów i równoległymi operacjami obsługującymi te połączenia. Przetwarzanie w chmurze wykorzystuje tę zaletę, przenosząc kod, który zwykle byłby uruchamiany przez klienta, na serwer i pozwalając klientowi być tak „głupi”, jak to możliwe. Wymaga to mniej zasobów użytkownika do obsługi tego samego rodzaju operacji.

To może nie być najlepsza odpowiedź, ale tak to widzę.