ewangelista.IT
Mariusz KędzioraIT Pro EvangelistMicrosoft Polska
Nazywam się Mariusz Kędziora i pracuję w polskim oddziale Microsoft w dziale Developer & Platform Group (DPG) jako IT Pro Evangelist.
W blogu postaram się przekazywać Wam ciekawe informacje o technologiach Microsoft w trochę luźniejszej formie niż to jest w dokumentacji czy na oficjalnych stronach Microsoft.
This post is provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft or any other company or organization. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
Nawet nie wiecie jak trudne jest napisanie o chmurze od A do Z. Tym bardziej, że chciałbym to zrobić w sposób jednocześnie prosty, ciekawy ale też w miarę szczegółowy. No i taki, żeby jak najwięcej osób zrozumiało koncepcję chmury (nie tylko tą w wykonaniu Microsoft!).
Zanim więc przejdę do chmury od strony funkcjonalnej i technicznej to jeszcze jeden post wyjaśniający to, co się działo z usługami IT w ostatnim czasie oraz jakie rodzaje chmury działają już od dłuższego czasu oraz co pojawiło się stosunkowo niedawno.
Na początku może zacznę od pewnego założenia, z którym można oczywiście dyskutować i zgadzać się lub nie. Ale ułatwi nam to trochę późniejsze wyjaśnienia.
Otóż według jednej z teorii chmura to przeniesienie pewnych zasobów (serwerów, danych, aplikacji) z naszej firmy/serwerowni w inne miejsce. I to bez względu na to czy to będzie tylko sprzęt, czy to będzie maszyna wirtualna, czy to będą dane, czy to będzie cała aplikacja. Oczywiście nie dotyczy to chmury prywatnej (o tym na końcu).
Jest to dosyć mocno uproszczona definicja (i tak, znam jej słabe punkty), ale pozwala nam szerzej spojrzeć na szczegóły, które już za chwilę.
Przy takiej uproszczonej definicji (jak wyżej) zobaczycie, że w pewnym sensie chmury istnieją już od dawna, tylko stają się coraz bardziej zaawansowane. Po prostu dostosowują się do potrzeb rynku.
Zacznę od pewnego schematu (nie przerażajcie się skrótami!), a później go omówię krok po kroku:
Tak jak wspominałem chmura zaczyna się kiedy chcemy coś wynieść z własnej firmy/serwerowni (w uproszczeniu).
Kolokacja to najstarsza i najprostsza forma usług w “chmurze”. Ktoś daje nam miejsce w serwerowni, prąd, klimatyzacje i oczywiście “rurę” do Internetu.
O całą resztę zatroszyć musimy się sami. Kupujemy więc sprzęt, zabezpieczenia (firewall czy load balancery), system operacyjny, oprogramowanie i aplikacje - oraz sami o to wszystko dbamy.
Tu płacimy po prostu za użyczenie miejsca w serwerowni.
Kolejny w kolejce jest IaaS, czyli rozszerzenie kolokacji o zapewnienie sprzętu przez dostawcę.
To dostawca daje nam sprzęt i dodatkowo czasem również zabezpieczenia. Naszym zadaniem jest dostarczyć system operacyjny, oprogramowanie i aplikacje.
Pewną grupą, którą pewnie już znacie mogą być serwery dedykowane, które u wielu dostawców można sobie kupić od dawna.
To co się zmieniło od pewnego czasu, to że dzięki wirtualizacji, to co dostarczamy dostawcy to najczęściej po prostu maszyna wirtualna.
Dzięki temu my dostarczamy jedną paczkę, a dostawca może nam zapewnić np. przenoszenie maszyny na mniej obciążone fizyczne serwery, łatwiejsze usługi utrzymania (mniej przestojów), itp.
W starszym przypadku (dedykowany serwer) płacimy za określony sprzęt (jako pudełko). W wypadku nowszym (wirtualne maszyny) płacimy trochę wygodniej, bo za faktycznie zużytą moc serwerów.
W tym nowszym podejściu tak działa m.in. chmura Amazon EC2 (chyba pierwsza “prawdziwa” chmura).
PS. Czasami IaaS nazywany jest też HaaS (Host as a Service). To tak w ramach tego, jakbyście jeszcze taki właśnie skrót zobaczyli.
W wypadku PaaS bierzemy to wszystko co było w IaaS, ale dostawca dorzuca nam do tego całą platformę aplikacyjną.
Przestajemy się martwić o system operacyjny (w tym jego utrzymanie, zarządzanie, patchowanie) a zajmujemy się tylko pisaniem aplikacji i ich utrzymaniem. Aplikacje możemy użytkować sami lub po prostu je sprzedawać jako usługi.
To daje nam Microsoft w postaci Windows Azure, gdzie system operacyjny jest zapewniony przez Microsoft. Dodatkowo zapewniona jest baza danych (SQL Azure) oraz kilka innych elementów.
Ważne jest to, że Microsoft zapewnia również oczywiście platformę do pisania aplikacji – czyli .NET Framework. Ale co równie ciekawe - aplikacje w chmurze Microsoft mogą być również napisane w językach takich jak PHP, Python czy nawet Java!
M.in. o tym będę pisał w przyszłości w cyklu o chmurze. Więc teraz nie będę się w to już zagłębiał.
Dodam tylko, że podobny rodzaj chmury oferuje również Google (choć w dużo mniejszym zakresie i o dużo mniejszych możliwościach, ale o tym też już wkrótce).
W tym wypadku rozliczamy się za zużycie zasobów (czas procesora, miejsce na dysku, liczbę zapytań czy transfer danych).
I dochodzimy do tego co jeszcze nam zostało w całej układance, czyli sytuacja kiedy to dostawca zajmuje się wszystkim. Od sprzętu, poprzez system operacyjny aż do finalnej aplikacji.
My korzystamy tak naprawdę tylko z określonej aplikacji i jej funkcjonalności. Czyli kupujemy trochę gotowe pudełko z aplikacją, tyle, że nie instalujemy jej u nas na komputerze a korzystamy z niej w chmurze (przez Internet).
W tym wypadku rozliczamy się najczęściej w modelu – opłata za jednego użytkownika za miesiąc korzystania z aplikacji. Minusem jest to, że nie zmienimy sobie nic w tej aplikacji ani nie mamy wpływu na jej rozwój (a przynajmniej nie decydujący wpływ).
I to z jednej strony jest coś w czym Microsoft “siedzi” od lat – bo mamy przecież Hotmail (największa na świecie aplikacja w chmurze) czy inne tego typu aplikacje (Live, SkyDrive, itp.).
Z drugiej strony w obecnej chwili tak dużo się o tym mówi, bo Microsoft przenosi swoje koronne i kluczowe aplikacje (działające do tej pory na komputerze/serwerze lokalnym) do chmury.
Widoczne się to stało m.in. 12 kwietnia – kiedy w Polsce miała miejsce premiera (na razie dosyć cicha) pakietu BPOS, czyli: Exchange Online, SharePoint Online, Office Communication Server Online i Live Meeting. Ale teraz nie będę o tym pisał, bo to temat na osobnego posta.
Co bardzo ważne – Microsoft zainwestował mnóstwo pieniędzy i zasobów w to, aby większośc produktów “pudełkowych” była w niedługiej przyszłości dostępna w chmurze. Inwestycje są rzędu 2.3 miliarda dolarów (!) w ostatnim roku oraz 30.000 inżynierów (!) pracujących nad tymi aplikacjami.
Dla pełnego obrazu dodam, że tego typu chmurę ma aktualnie też m.in. Google (ze swoimi Google Apps) oraz Salesforce.com (ze swoim systemem CRM, znanym bardziej na świecie niż w Polsce). Ale o porównaniu i różnicy w ich możliwościach też już wkrótce.
Do całego obrazu brakuje nam jednego dodatkowego wyjaśnienia. Chodzi o wymieszanie tego co mamy teraz (czyli serwery w firmie, aplikacje na komputerach) z tym co daje chmura (serwery i aplikacje poza firmą).
Generalnie często nazywa się to właśnie jako Software + Services. Czyli z jednej strony możliwości korzystania z klasycznego oprogramowania (Software), z drugiej strony możliwośc skorzystania z tego na zasadzie usługi (Service). Czyli czy zainstaluję sobię Exchange na moim serwerze czy będę z niego korzystał w chmurze (Exchange Online).
To od nas ma zależeć co dla nas jest lepsze. Bo wcale nie zawsze chmura będzie super rozwiązaniem. Ale też nie zawsze kurczowe trzymanie się tego co mamy u siebie (serwerów czy aplikacji) będzie najlepsze. A może mix będzie w tym wypadku najlepszy? Pewnie dosyć często tak. Tu każdy musi zdecydować sam.
A w obecnej chwili TYLKO Microsoft ma możliwość dania nam tego wyboru. Bo w swojej ofercie ma zarówno klasyczne pudełka (z oprogramowaniem wszelkiego rodzaju) jak i ich odpowiedniki w chmurze (tych na razie jest kilka, niedługo będzie pewnie zdecydowana większość).
Ale o tym też będzie osobny post :)
Jest jeszcze jedna rzecz, o której trzeba by teraz powiedzieć – czyli chmura prywatna. Jak pewnie możecie się domyśleć będzie to rozwiązanie, w którym weźmiecie to co w tej chwili daje Wam dostawca w chmurze (specjalnie przygotowane systemy operacyjne i aplikacje) i uruchomicie to u siebie.
Podejrzewam, że to rozwiązanie sprawdzi się w niewielu sytuacjach. Bo będą to albo naprawdę duże firmy, które stać na postawienie odpowiedniej serwerowni u siebie. Albo ewentualnie firmy, które nie mogą całości danych czy aplikacji wynieść z firmy/serwerowni (banki?) a chciałby skorzystać z tej skalowalności, którą daje chmura.
Jeśli znajdę więcej informacji o chmurze prywatnej (bo na razie zbyt wiele o tym nie wiem), to być może powstanie o tym osobny post w przyszłości.
Dobrze, czas na podsumowanie, bo post urósł chyba do niezłej długości. Ale myślę, że warto było o tym opowiedzieć w trochę ustrukturyzowanej formie.
Bo ja przyznam się, że wszystkie te pojęcia i skróty słyszałem już nie raz (!), a nigdy nie potrafiłem ich dobrze zrozumieć.
Ale sposób w jakim Wam to wyjaśniłem - do mnie przemówił i bardzo mi rozjaśnił to wszystko o co chodzi z chmurą i jakie są różnice między pewnymi rodzajami chmury (tym co Amazon nazywa Cloud Computing, a tym co Google czy Microsoft).
Mam nadzieję, że również i Wy macie pewien dodatkowy pogląd na chmurę. Jeśli udało mi się choć trochę pomóc wyjaśnić temat i sądzicie, że powinienem kontynuować ten cykl to dajcie znać w komentarzach (no dobra, jak nie dacie znać to i tak to będę opisywał :))
Chciałem dosyć szybko przejść do konkretów, ale chyba jeszcze przed omówieniem jednej części już działającej chmury Microsoft (czyli wspomnianym BPOS) omówię jeszcze jak to się dzieje, że taka chmura działa.
Czyli to wszystko co stoi przed usługami, platformą i aplikacjami – sprzęt, zasoby, ludzie, zarządzanie. Teoretycznie nie powinno Was to interesować (bo Wy kupujecie te zasoby, żeby się nie przejmować nimi), ale myślę, że w ramach ciekawostki pokaże Wam to zaplecze Cloud Computingu i jego skalę oraz możliwości.
Czym różni się wobec tego azure od powiedzmy serwera wirtualnego, jaki oferują liczne firmy w sieci, Dreamhost, na przykład?
I czym się różni od konta shellowego, na którym możemy uruchomić dowolne aplikacje, serwer baz danych, www itp, pomijając oczywiście etap wirtualizacji? Sprzęt i system zapewnia dostawca, konkretne oprogramowanie które nam jest potrzebne (aplikacja) dostarczamy my. Taką usługę pełni chociażby rootnode.net. Tylko rootnode nie wykorzystuje w tym wszystkim wirtualizacji.
Rozumiem, że główną różnicą od tej drugiej opcji jest to, że nie mamy kontroli na którym serwerze stoi 'nasze' środowisko. W odróżnieniu od obu opcji jest inny model płatności. Są jeszcze jakieś różnice?
Intryguje mnie również, czy w ramach używania powiedzmy pythona jesteśmy ograniczeni do jednej implementacji, czy możemy wybrać sobie inną? cpython lyb jython zaimast ironpythona, dla przykładu. Może pythonowe silniki są zbliżone, to różnice wydajności silników ruby są już bardzo duże. I dają dużo większe możliwości (jruby wykorzystywany razem z javą).
@mt30: No i takich pytań się obawiałem a jednocześnie BARDZO się cieszę, że się pojawiają.
Cieszę się, bo po pierwsze oznacza to, że to dla Was interesujący temat, a po drugie ja miałem dokładnie te same pytania :) Więc takich odpowiedzi też szukałem i szukam.
A obawiałem się, nie dlatego, że są ciężkie czy niewygodne (bo nie są!), ale dlatego, że chciałem to wszystko opisać w kolejnych odcinkach :) Dokładnie wtedy kiedy dojdę do szczegółów z każdej wersji chmury.
Ale odpowiem teraz w skrócie - choć pewnie w przyszłości w kolejnych odcinkach/postach będę się musiał powtórzyć. Z jednej strony różnice są duże, a z drugiej stosunkowo małe :)
Serwer wirtualny to trochę taki PaaS, czyli platforma na której można pisać aplikacje. Konto shellowe to trochę taki IaaS, czyli infrastruktura na której możesz zrobić coś więcej (łacznie z instalacją dodatkowych rzeczy, itp.)
Ale różnice w stosunku do chmury ogólnie są dwie (przynajmniej te duże): płatność i skalowalność.
Płatność. W wypadku serwera wirtualnego czy takiego z shellem - płacisz najczęściej pewną opłatę raz na rok. I jest ona stała bez względu na to co robisz na tym serwerze. Jest zależna tylko ewentualnie od ilości miejsca na dysku czy wliczonego transferu.
W wypadku chmury płacisz za określone zużyte zasoby - czas procesora, zajęte miejsce, ilość transakcji czy transfer. I robisz to najczęściej raz w miesiącu.
Upraszczając to trochę tak jak w telefonii komórkowej. Możesz płacić abonament, być rozliczanym za minutę rozmowy i mieć pewną uśrednioną ofertę (której czasem nawet całej nie wykorzystasz). A możesz też płacić w zależności od potrzeb, być rozliczanym co do sekundy i mieć ofertę pod siebie (płacisz dokładnie za to z czego korzystasz), a na dodatek móc zerwać kontrakt w każdej chwili (a nie czekać 2 lata).
Teraz skalowalność. Taka nasza-klasa.pl miała na początku serwer wirtualny/dedykowany (nie ważne). Nagle przyszła popularność i nic nie pomogło. Pan Gąbka był stałym gościem portalu. Gdyby to było do razu w chmurze nie byłoby takich problemów.
To samo ze stronami zapisu dzieci do przedszkola czy kupowania biletów na popularne koncerty. Owszem można mieć mega infrastrukturę kupioną, ale dla 3 pików w roku (kiedy jest kosmiczne zainteresowanie) - chyba nie warto. W chmurze to żaden problem obsłużyć takie piki (i tylko za nie zapłacić więcej).
Scenariuszy pod skalowalność jest kilka, ale o nich pozwól, że napiszę w odpowiednim odcinku :)
Jeśli chodzi o pytanie z pythona - odpowiem wprost - nie mam pojęcia :) Nie wgryzałem się w szczegóły obsługi innych języków i innego środowiska. Co nie znaczy że nie mogę się wgryźć. Postaram się do czasu odcinka o platformie programistycznej znaleźć odpowiedź na Twoje pytanie :)
A mnie zastanawia w chmurach jedna rzecz - odporność na ataki DoS. Załóżmy, że ktoś atakuje moją aplikację znajdującą się w chmurze. Jeśli ataki są dobrze przeprowadzone, atakujący może mnie puścić z torbami, ponieważ będę płacił za "pusty" ruch.
Jak chmury sobie z tym radzą?
@Masakra: dzięki, usystematyzowałeś trochę moje pojęcie o chmurach!
@Batman: Google wyznaczyło limit wejść na stronę, którego nie można bez uprzedzenia przekroczyć. Przekroczenie blokuje dostęp do witryny i tym samym zatrzymuje wzrost kosztów. G prosi też, żeby zgłaszać przypadku DDOSów do indywidualnego rozpatrywania. Jak Microsoft to rozwiąże? Ciężko powiedzieć. Nie znalazłem jeszcze wprost podanej informacji o tym. Może źle szukałem?
Fakt faktem, że DDOS jest słabym punktem chmur. Przy hostingu wirtualnym w najgorszym wypadku każą się wynieść. W przypadku chmury - mogą nam sporo policzyć za bycie ofiarą ataku.
@batman: Pozwól, że zostawię sobie ten temat na specjalny, dedykowany post o bezpieczeństwie w chmurze (z różnych punktów widzenia) :)
@m3to: Cieszę się, że udało mi się to w miarę jasno wytłumaczyć.
@masakra
Czekam z niecierpliwością.
Dobrze, że ktoś w końcu zbierze wszystkie informacje o chmurach w jednym miejscu.
super
Witam.Jestem nowy w tym temacie i dopiero się uczę jak przetwarzać dokumenty w chmurze i co do tego mam pytanie jakie są zalety tworzenia w chmurze no i oczywiście jakie może mieć wady. Z góry dziękuję za odpowiedź.
Więc chodzi o to,że zamias trzymać rzeczy na twardym i instalować programy będzie to dostępne w sieci, do wynajmu, użytku itp?
@simekx: Bardzo dużo zależy o jaką chmurę pytasz? Każdy rodzaj chmury ma inne zastosowania i może być przydatny w innym aspekcie. Proponuję przeczytać mój post - wyjaśniam w nim która chmura do czego służy. Jakbym miał spróbować odpowiedziec na Twoje pytanie - to zalety chmury to skalowalność, płacenie tylko za to z czego skorzystasz i dużo szybsze skorzystanie niż kupowanie swojej infrastruktury.
@Yo: I tak i nie... Nie będziesz raczej mógł zainstalować sobie np. gry czy Photoshopa na serwerze w chmurze i korzystać z niego jak na swoim komputerze. Ale jakbyś chciał mieć np. Office'a w chmurze - to możesz go sobie wykupić w chmurze i korzystać tam. Możesz też napisać swoją aplikację i trzymać ją w chmurze. Wszystko zależy od rodzaju chmury z jakiej chcesz (czy może lepiej - potrzebujesz) skorzystać.
To całe gadanie o chmurach jest przereklamowane - nowa nazwa na stare rzeczy. Wcześniej to się nazywało system rozproszony, a 20 lat temu używaliśmy terminali tekstowych lub graficznych żeby korzystać z aplikacji na serwerze/serwerach.
@maciej: Co do przereklamowania - może w jakiejś części masz rację, że wiele z tego już było kiedyś... ALe nie powiesz mi, że technologia stoi w miejscu i jest to dokładnie ta sama technologia i to samo wykonanie :) I to, że podłączasz się zdalnie do aplikacji - nie zawsze znaczy, że to już jest chmura... Chmura to w głównej mierze - skalowalność i granularne rozliczanie.
Czy przy podłączaniu się do terminali te 20 lat temu, mogłeś w 3 minuty odpalić nagle dodatkowe 1000 serwerów (teraz to możliwe z chmurą Microsoft)? Czy te 20 lat temu mogłeś powiedzieć, że potrzebujesz mega zasobów (1000 serwerów) na 2 dni a później z tego zrezygnować?
I owszem koncepcja dosyć podobne, ale dosyć znacząco się różniąca w szczegółach implementacyjnych.
Wow, nareszcie ktoś pisze po polsku, inaczej mówiąc: po ludzku, bo to co dotychczas czytałam, żeby się dowiedzieć o co chodzi z tymi chmurami (czy pisane po angielsku czy - teoretycznie - po polsku) mogłoby być równie dobrze pisane po chińsku. I nie ma to nic wspólnego z tym, że jestem kobietą, natomiast nie jestem informatykiem, a interesują mnie nowe możliwości przetwarzania danych z punktu widzenia potencjalnego użytkownika, który chciałby wiedzieć dość dokładnie co może zyskać, a ważniejsze - co może stracić (dane są dziś istotnym towarem i niejeden chce na tym zarobić, nie zawsze uczciwie).
Nie tylko zatem informatycy się interesują takimi kwestiami, więc WIELKIE DZIĘKI i mam nadzieję postudiować tę tematykę dalej, dzięki Twojemu przewodnictwu.
Gratuluję też pasji - to jest widoczne, że piszesz o czymś co sprawia Ci frajdę :))
Tylko dlaczego tak trudno Cię znaleźć?
"(nie tylko tą w wykonaniu Microsoft!)."
Winno być "tę"
Od ostatniej reformy językowej może być już zamiennie - tę lub tą. Ale faktycznie ja też wolę po staremu - tę.