Budować infrastrukturę swojej witryny własnoręcznie czy oddać ją w cudze ręce? Przed tym dylematem stoi niejeden twórca zyskującego na popularności serwisu WWW. Spróbujemy przyjrzeć się obu opcjom i opisać ich najważniejsze cechy.
Poniższy artykuł został przygotowany wspólnie z firmą Oktawave, dostawcą usług hostingu w chmurze.
Tworząc lub modernizując infrastrukturę odpowiedzialną za zapewnienie prawidłowego funkcjonowania popularnej aplikacji WWW, mamy do wyboru kilka różnych rozwiązań. Z jednej strony możemy samodzielnie zbudować całą platformę w oparciu o własny sprzęt i doświadczenie, z drugiej możemy zdecydować się na całkowite przenosiny do chmury. Spójrzmy na wady i zalety obu rozwiązań i przyjrzyjmy się wynikowi migracji do chmury dużego serwisu WWW.
Jak obsłużyć popularną aplikację WWW
Zbudowanie środowiska zapewniającego wysoką dostępność i wydajność popularnej aplikacji WWW nie jest prostym zadaniem. Jeśli sami tworzymy całą potrzebną infrastrukturę, to musimy pomyśleć o wielu elementach układanki. Na warstwie sieciowej potrzebujemy:
- rozdzielne fizycznie łącza o odpowiedniej przepustowości od niezależnych dostawców z wysokim SLA,
- własny system autonomiczny w związku z koniecznością wdrożenia BGP,
- load balancery zapewniające dystrybucję ruchu,
- rozwiązania filtrujące i blokujące niepożądany ruch sieciowy.
W celu zagwarantowania dostępności wszystkie rozwiązania sieciowe muszą być co najmniej zdublowane. Z kolei na warstwie mocy obliczeniowej musimy zapewnić:
- serwery aplikacyjne zapewniające ogólnie pojętą logikę aplikacji np. frontend i backend,
- serwery bazodanowe,
- serwery serwujące elementy statyczne aplikacji, odciążające serwery aplikacyjne z przetwarzania zapytań dotyczących grafik, zdjęć czy dokumentów.
Podobnie jak w przypadku elementów sieciowych również te elementy muszą zostać zwielokrotnione, aby zapewnić odpowiednią dostępność oraz wydajność. Optymalne wyskalowanie potrzebnych zasobów, a w szczególności liczby procesorów oraz pojemności pamięci jest bardzo trudnym zadaniem. Brak możliwości rzetelnego przewidzenia skali wzrostu ruchu czy chociażby nagłych jego zmian sprawia, że łatwo popełnić jeden z dwóch rodzajów błędów: przeszacować potrzeby i ponieść koszty niewykorzystanych zasobów lub niewystarczająco oszacować potrzeby i nie móc dostarczyć na czas odpowiedniej mocy i pojemności.
Ostatnim niezbędnym elementem naszej aplikacji jest przestrzeń dyskowa. Podobnie jak w przypadku mocy obliczeniowej musimy dobrze ocenić zapotrzebowanie pojemnościowe i wydajnościowe oraz podjąć decyzje odnośnie konkretnych zasobów dyskowych. Błędy w ocenie będą miały, podobnie jak na warstwie mocy obliczeniowej, negatywne skutki dla budżetu lub wydajności aplikacji.
Wybierając drogę samodzielnej budowy swojej infrastruktury, warto także pamiętać, że istotnymi pozycjami w budżecie takiego projektu mogą być licencje hypervisora, koszty konserwacji sprzętu czy podzespoły przechowywane na wypadek awarii.
A może do chmury
Podejściem diametralnie odmiennym od budowy własnego środowiska jest wykorzystanie chmury publicznej oraz jej wbudowanych mechanizmów i narzędzi.
Różnice między tworzeniem rozwiązania w środowisku cloudowym widać już w warstwie sieciowej, w której nie musimy się martwić zapewnieniem dostępności. Wysoko dostępne łącza o dużej przepustowości wraz z urządzeniami brzegowymi zapewnia nam dostawca chmury. Można także wykorzystać gotowe mechanizmy balansowania ruchu takich protokołów jak HTTP, HTTPS czy np. SIP. Jednocześnie możemy korzystać z dodatkowych mechanizmów, np. badających stan aplikacji oraz różnych algorytmów balansowania ruchu, takich jak „Least Connection” czy „Least Response Time”.
Największą zmianę w architekturze widać od warstwy mocy obliczeniowej w dół, ponieważ elementy fizyczne przestają w ogóle być przedmiotem zainteresowania administratora. Procesory czy pamięć są po prostu dostępne i jesteśmy w stanie nimi swobodnie zarządzać w ramach każdej instancji serwera.
Możemy nimi zarządzać na kilka sposobów. Podstawowym jest ręczna modyfikacja parametrów przy użyciu portalu administracyjnego. Bardziej zaawansowane możliwości oferuje Autoskaler. Dzięki jego mechanizmowi mówimy już nie tylko o zarządzaniu mocą obliczeniową poszczególnych serwerów, ale o zarządzaniu wydajnością aplikacji. Autoskaler umożliwia skalowanie infrastruktury zarówno horyzontalnie – poprzez dodawanie nowych instancji klonowanych serwerów – jak również wertykalnie, poprzez dodatkowe procesory lub pamięć. Operacje te mogą się odbywać w sposób automatyczny na podstawie zdefiniowanej polityki, a platforma podejmuje decyzje o zmianie parametrów na podstawie ich aktualnego wykorzystania.
Drugim mechanizmem ułatwiającym pracę administratora jest Scheduler, który umożliwia w naszej infrastrukturze zaplanowanie zadań do wykonania. Dobrym przykładem wykorzystania Schedulera jest sytuacja, gdy określony moduł aplikacji jest potrzebny w danych dniach tygodnia lub widoczne jest zwiększenie ruchu w konkretnych godzinach. Dzięki Schedulerowi możemy zaplanować najpierw włączenie konkretnych instancji, a następnie ich wyłączenie, gdy nie są już potrzebne.
Innym pomocnym narzędziem, które dostaniemy do dyspozycji w chmurze, jest RESTful API. Możemy je wykorzystać zarówno w przypadku realizacji powtarzalnych czynności na wielu instancjach serwerów, jak i do skalowania naszej aplikacji. Istotną zaletą jest możliwość wykorzystania API wspólnie z narzędziami takimi jak Ansible, Chef, Puppet czy Salt.
Jeżeli nasze potrzeby dotyczące automatycznego skalowania środowiska wykraczają poza standardowe funkcjonalności Autoskalera, dobrym rozwiązaniem będzie wykorzystanie do tego celu API. Aplikacja może np. badać czasy odpowiedzi, a po przekroczeniu zadanych parametrów wywołać stosowne metody.
Duża zmiana wiąże się też z zastosowaniem obiektowej przestrzeni dyskowej (OCS), która zastąpi całą grupę serwerów odpowiedzialnych za serwowanie elementów statycznych aplikacji. Dzięki zastosowaniu bibliotek programistycznych dostępnych dla praktycznie wszystkich języków programowania (.NET, C/C++, PHP, itp.) aplikacja zyskuje możliwość dostępu do OCS. Taka integracja umożliwia wykorzystanie obiektowego storage’u do przechowania elementów statycznych w formie obiektów wraz z ich metadanymi. Ważną zaletą takiego podejścia jest także eliminacja wielu maszyn wirtualnych, wymagających nakładu pracy związanego z ich utrzymywaniem.
Korzyści pojawiają się również w zakresie przestrzeni dyskowej. Przede wszystkim znikają ograniczenia związane z fizycznym rozmiarem posiadanych zasobów. Jeżeli zaistnieje potrzeba ich zwiększenia, po prostu stworzymy nowy zasób i zaczniemy z niego korzystać.
W scenariuszu z wykorzystaniem chmury przestaje być problemem wydajność przestrzeni dyskowych. Jesteśmy w stanie tworzyć zasoby odpowiadające naszym potrzebom, dysponując dostępem do pięciu poziomów, od Tier-1 o wydajności 1000 IOPS do Tier-5 z wydajnością 200 000 IOPS,. Co niezwykle istotne – możliwa jest zmiana wydajności np. z Tier-2 na Tier-3 w locie oraz w sposób przezroczysty dla systemu operacyjnego. Parametrami możemy zarządzać zarówno z panelu, jak i za pomocą API. Podobnie jak w przypadku mocy obliczeniowej aplikacja może sama weryfikować stan dysków i odpowiednio wywołać metody odpowiedzialne za zmianę Tieru lub rozmiaru dysku OVS.
Kiedy chmura publiczna nie jest rozwiązaniem
Oczywiście korzystanie z publicznej chmury ma także swoje wady. Jedną z podstawowych jest fakt, że firmowe dane przechowywane są w cudzej infrastrukturze. Nie dla każdego jest to problemem, jednak istnieją firmy i organizacje, które ze względów prawnych lub strategicznych nie mogą lub nie chcą oddawać kontroli nad swoimi informacjami innym podmiotom. Istnieją także serwisy, w których dostępność nie jest bardzo ważna lub firmy, które działają na skalę umożliwiającą wdrażanie własnych platform chmury prywatnej. Decyzja o tym, czy przenosić swoja infrastrukturę do chmury, musi zawsze być poparta solidną analizą zysków i strat.
Fotosik, czyli w kierunku elastyczności
Spójrzmy na przykład firmy, która podjęła decyzję o przenosinach. Fotosik.pl to jeden z największych polskich serwisów hostujących zdjęcia i jednocześnie klient Oktawave. Serwis przeniósł do chmury sporą infrastrukturę, składającą się z ponad 13 terabajtów zdjęć i wideo, ponad 65 milionów plików oraz ponad 20 dedykowanych maszyn. Przed migracją serwisu do chmury infrastruktura aplikacji zbudowana była z:
- load balancera rozdzielającego ruch na cztery serwery dedykowane, obsługujące stronę WWW,
- czterech serwerów baz danych w tym dwóch działających w trybie master/slave,
- serwera kopii bezpieczeństwa baz danych,
- serwera statystyk,
- dwóch serwerów do generowania różnych formatów zdjęć,
- 15 serwerów serwujących pliki statyczne (zdjęcia).
Po migracji infrastruktura została zoptymalizowana do:
- load balancera rozdzielającego ruch na dwa serwery obsługujące stronę,
- dwóch serwerów baz danych,
- czterech serwerów serwujących pliki statyczne,
- dwóch serwerów obsługujących wspólne dyski dla serwerów aplikacyjnych i serwujących pliki statyczne.
Już na pierwszy rzut oka widać skalę uproszczenia i optymalizacji środowiska. Wiąże się z nią także znaczna redukcja kosztów utrzymania. Dzięki automatycznemu zarządzaniu wymaganą mocą serwerów administrowanie stało się łatwiejsze i mniej czasochłonne. Korzyści są także widoczne z punktu widzenia użytkownika końcowego – pomimo rosnącej liczby użytkowników serwis zwiększył szybkość działania. Na stronie Oktawave znajdziecie także dokument zawierający więcej szczegółów dotyczących migracji.
Podsumowanie
Chmura zdejmuje z nas ograniczenia sprzętowe w zakresie warstwy sieciowej, serwerowej i przechowania danych. Nie musimy kupować ani utrzymywać urządzeń, a w dalszej perspektywie myśleć o ich wymianie w związku ze zużyciem. Unikamy ryzyka niewłaściwego oszacowania potrzebnych zasobów, a co za tym idzie ponoszenia dodatkowych kosztów. Otrzymujemy bezpieczną, redundantną infrastrukturę zapewniającą parametry dokładnie takie, jakie są nam w danej chwili potrzebne.
Przy okazji otrzymujemy także dostęp do narzędzi, które pozwalają łatwo oraz elastycznie zarządzać infrastrukturą oraz szybko uruchamiać ją np. na potrzeby krótkookresowych projektów. W procesie ciągłego rozwoju aplikacji jesteśmy w stanie przeprowadzać automatyczne testy funkcjonalne lub wydajnościowe wykorzystując narzędzia takie jak GIT czy Jenkins. Zyskujemy także możliwość uruchamiania środowisk testowych o zróżnicowanych parametrach oraz wygaszania ich po zakończonych pracach.
Takie podejście do zarządzania infrastrukturą znacznie przyspiesza i ułatwia dostarczenie aplikacji WWW, uwalnia od niepotrzebnych kosztów sprzętu, jego składowania i serwisowania, a w połączeniu z rozliczaniem godzinowym sprawia, że ponosimy tylko koszty mocy obliczeniowej, której faktycznie potrzebujemy.
Czy wiesz, że po przesiadce do Oktawave Fotosik zredukował swoje koszty aż o 40%? Jakie korzyści może przynieść Tobie chmura obliczeniowa? Przekonaj się sam!
Dla pierwszych 200 czytelników Zaufanej Trzeciej Strony udostępniamy kod na 50 zł na przetestowanie chmury obliczeniowej Oktawave.
Aby wykorzystać swój kod, zarejestruj konto w Oktawave, a następnie zaloguj się do panelu administracyjnego. W menu po prawej stronie wybierz zakładkę BILLING i wybierz formę płatności KOD PROMOCYJNY oraz wpisz w odpowiednie okienko kod rj6km8D2, następnie kliknij przycisk DALEJ. Po zaakceptowaniu transakcji Twoje konto w Oktawave zostanie zasilone kwotą odpowiadającą wartości kodu promocyjnego.
Kod jest ważny do 15 sierpnia 2016. Sprawdź chmurę już dziś!
Dla zachowania pełnej przejrzystości – za publikację tego artykułu otrzymujemy wynagrodzenie od Oktawave.
Komentarze
Dlaczego nie poruszacie wogóle tematu kosztów? Przedstawcie proszę roczny koszt utrzymania serwera średniej klasy w chmurze. Niech kalkulacja zawiera wszystkie bajery, o których piszecie, poczynając od umowy z wysokim SLA, szybkie łącza, opłaty za szacowany ruch sieciowy, za miejsce na dysku, load-balancery i redundancję caĺego systemu. Wyjdzie więcej niż 10 000$ rocznie?
Nie poruszają, bo różni dostawcy będą mieli różne koszta. Dali informację że dla takiego fotosika dało to 40% spadku kosztów.
Napisz do jakiegoś dostawcy chmurowego, zrobi Ci wyceny.
Kolego, artykuł dotyczy oferty jednego providera cloudowego…
Widzę że już zespół sponsora artykułu się odezwał.
I kolego, oczekujesz że podadzą Ci swoje koszty operacyjne? …
No przecież jakoś cennik chyba jest, c’nie? Nie wyobrażam sobie ustalania cen usług chmurowych indywidualnie.
Witaj Maciejos,
ideą chmury obliczeniowej jest rozliczanie wszystkich parametrów poprzez monitorowanie zużycia.
Cele takiego podejścia są dwa:
1) umożliwienie klientowi opłacania tylko realnie wykorzystanych zasobów,
2) sprawowanie pełnej kontroli nad całą infrastrukturą, co pozwala gwarantować SLA.
Nie ukrywamy żadnych kosztów, wszystkie tabele kosztowe są dostępne tutaj: https://www.oktawave.com/pl/cennik, a cennik wsparcia premium tutaj: https://www.oktawave.com/pl/wsparcie_techniczne
Pozdrawiamy!
Witaj Maciejos,
zapraszamy Cię do udziału w naszym konkursie na Fb, gdzie można zaprojektować infrastrukturę oraz wygrać jej trzymiesięczny hosting w chmurze Oktawave: http://bit.ly/KonkursDlaAdminów
Wówczas będziesz mógł się przekonać, jak Twój projekt będzie działać w chmurowej infrastrukturze.
A w odniesieniu do kosztów: wszystko zależy od indywidualnego przypadku, o którym chętnie możemy porozmawiać.
Jeśli korzystasz z alternatywnej infrastruktury dla swojego projektu i chciałbyś nam podać, gdzie oraz na czym, to chętnie to zanalizujemy oraz zaproponujemy jej odpowiednik w chmurze.
Pozdrawiamy
zespół Oktawave
Za zaproszenie dziękuję, ale z racji trzymania się z dala od Facebooka nie skorzystam.
Z ciekawości tylko zapytam, co czyni waszą ofertę lepszą od oferty konkurencji, czym się wyróżniacie? Dlaczego miałbym pójść do Was a nie do Amazona albo Softlayera?
@Maciejos, odpowiadając na pytanie o nasze wyróżniki, na pewno wskazalibyśmy na:
– nieprzeciętną wydajność dyskową w naszej chmurze, oferującą zmianę parametrów w trakcie pracy maszyny. Nasz użytkownik już na starcie otrzymuje wydajność 8 dysków SAS połączonych w RAID 10 (Tier 1 do 1000 IOPS), a to można skalować w trakcie pracy aż do 200 000 IOPS (Tier 5),
– 2 rodzaje autoskalerów: horyzontalny, zmieniający liczbę maszyn wirtualnych w puli oraz wertykalny, który zmienia parametry maszyn wirtualnych,
– support premium dla zainteresowanych oraz zespół doświadczonych adminów, który na co dzień realizuje projekty dla najbardziej wymagających klientów,
– fakt, ze jesteśmy polską firmą z centrum danych na terenie Polski, co oznacza, że dokładnie wiesz, gdzie są Twoje dane oraz jaki porządek prawny je reguluje,
– to ma znaczenie choćby dlatego, że polskie prawo w zakresie ochrony danych osobowych jest bardziej restrykcyjne niż unijne czy amerykańskie,
– jesteśmy pierwszą polską publiczną chmurą typu IaaS z certyfikatem bezpieczeństwa ISO 27001. Podchodzimy serio do kwestii bezpieczeństwa i spełniamy restrykcyjne normy GIODO w zakresie przetwarzania danych osobowych.
Jesteśmy jednak zdania, że najlepiej jest się przekonać samemu. Skorzystaj z kodu rj6km8D2 i przetestuj naszą chmurę.
Pozdrawiamy
zespół Oktawave
„Podchodzimy serio do kwestii bezpieczeństwa i spełniamy restrykcyjne normy GIODO w zakresie przetwarzania danych osobowych.”
Are you kiddyn?
GIODO nie ma norm. Normy to inna bajka – skoro macie 27xxx to chyba czujecie o czym rzecz. Wytyczne są w regulacjach aktów wykonawczych do ustawy z 97 roku. m.in wskazuje ona 3 poziomy zabezpieczeń w którym poziom wysoki oznacza stosowanie haseł 8 znaków (duże, małe litery, znaki specjalne itd). Hasła się zmienia co 30 dni oraz wymóg posiadania kopii zapasowych i szyfrowania transmisji.
To są restrykcyjne normy? Wyście widzieli kiedyś restrykcyjne wytyczne? Kto wam takie bzdety przygotował?
Dodaj jeszcze koszt utrzymania pomieszczeń (a czasem wybudowania), konserwacji i certyfikatów bezpieczeństwa. Koszty należało by obliczyć z uwzględnieniem kilku lat działalności. Chmura ma jedną zaletę: umożliwia jedynie obniżenie kosztów początkowych działaności.
No i gdzie ten kodzik na testy?
Link jest refem i dostajesz go po zarejestrowaniu.
Jednak znalazł się zaginiony kodzik: rj6km8D2 :]
Panowie, panowie, panowie. Domyśliłem się po URL. Ale po rejestracji nic nie dostałem.
Kolejny artykuł sponsorowany :/
Nie ma nic za darmo. Chcesz czytać darmowe teksty? – oglądaj i czytaj reklamy. Nie chcesz reklam? – płać za teksty.
Kupując teksty i tak czytam reklamy (gazety).
I co w tym złego? Na takim dobrym serwisie należy zarabiać. Dla przejrzystości czytelników napisane jest na samym początku dwa razy że to artykuł sponsorowany i na samym końcu również. Skoro przeszkadza Ci czytanie takich rzeczy – możesz to pominąć. Totalnie nie rozumiem o co Ci chodzi.
NIe narzekałbym gdyby nie fakt, że to drugi z rzędu (nie licząc weekendowej lektury).
Czemu niby nie liczysz weekendowej lektury? :) Obiektywnie, jest to jeden z najbardziej wartościowych cykli / prasówek w polskim internecie.
Serwery Amazona (AWS) są lepsze
Chmura zabiera pracę adminów ;_;
https://www.oktawave.com/pl/kariera ;-)
A widelki jakie dla sysadmina (Linux/Networking)?
A jak serwer jest w chmurze to sie sam adminuje?
A koparka zabiera pracę szpadlowym. Posiadanie własnego samochodu zabiera pracę taksówkarzom, kierowcom autobusów i kolejarzom. Samochód kombi pracę sklepikarzom. Tanie szwalnie zabrały pracę producentom maszyn do szycia, a masowa produkcja butów zabrała pracę szewcom.
jakby ktoś chciał pomóc, to oto mój nr polecającego 8519 (własnie założyłem konto)
będę rozsądnie wydawał (Wasze) pieniądze
Jak ktos szuka JanuszChmury to niech sobie w Arubie kupi 4-5 VPSow za 5 zl msc w roznych regionach i bedzie mial swojego AWS :D
Dziękujemy JanuszChmury za wspomnienie o nas. Wybranie kilku VPSów w różnych DC w infrastrukturze ArubaCloud, to naprawdę dobry pomysł, ale dalej nie będzie to AWS ;)
Cenimy jednak poczucie humoru :)
Z tym nazewnictwem poziomów wydajności storage to spotkałem się z odwrotnym stopniowaniem (im wyższa cyfra tym wolniejszy storage). To jest jakoś standaryzowane czy to po prostu kwestia przyjętej nomenklatury?
Fajnie art. sponsorowany co widać i ok jeść każdy musi ja to rozumiem i popieram.
Ale mam pewne ale.
O czym jest art. ? O przenosinach aplikacji do chmury? czy o hostingu strony internetowej?
Potem mi klient czyta taki art. i wpada na genialny skądinąd pomysł że skoro trzeba serwer dla cdn wymienić to może on go do chmury… Przecież na z3s napisali że można aplikacje i będzie taniej….
I zaczynają się schody w wyliczeniu.
Przecież niezawodne i nie trzeba łączy zapasowych o których truję od dawna…
Problem w tym że to nie prawda.
Owszem dostępność dla pracowników mobilnych będzie pewniejsza ale dla tych siedzących w firmie spadnie. A ich jest więcej.
Więc jak najbardziej łącze zapasowe jest musem ale dla 40 osób a nie dal 10…. A jest to niewykonalne w danej lokalizacji bo nie ma dostawców.
A nawet jak to nadal trzeba mieć dwa dobre łącza żeby mieć pewność dostępu do usługi.
Oczywiście pominę przez grzeczność bezpieczeństwo takiego rozwiązania. Oczywiście zapewne sponsor art. jest w stanie zapewnić odpowiednią infr. żeby to bezpieczeństwo było zapewnione ale to wzrost kosztów.
Troszeczkę mnie drażni pisanie o przenoszeniu stron internetowych do chmury i traktowanie tego jak przenoszenie aplikacji.
Jest to niebezpieczne uproszczenia.
Pierwsze w chmurkach są od zawsze drugie są nieraz krytyczne i o wiele trudniej je przenieść w sposób bezpieczny.
I pytanie gdzie po optymalizacji wyleciał serwer kopi?
Nie ma? Czy jest „w ramach usługi”?
Rozumiem zaufanie do firmy ale mieliśmy kilka spektakularnych padów w ostatnim czasie. Jedne głośniejsze inne przykryte kupą gruzu i nie koniecznie głośne.
A jeśli firma sponsor po prostu zbankrutuje?
Więc trzeba mieć serwer kopii w drugiej lokalizacji u innego dostawcy albo lokalnie. Te kopie tanie nie będą.
Kilka sporych firm miało problemy po problemach serwerowni.
Problemy które odczuwalne były już globalnie.
Dla małej firmy takie problemy mogą być końcem i o tym trzeba jasno mówić w kwestii chmur i zabezpieczenia się w momencie przenoszenia do nich infr.
Powstał niebezpieczny mit bezpieczeństwa chmury.
Wielokrotnie na pytanie o kopie słyszałem że trzymają przecież dane w chmurze więc są bezpieczne!
Ale do tej pory nie spotkałem się z firmą która dawała by 100% gwarancję na to ze danych nie stracą i ze usługa będzie dostępna.
Wszystkie mają wyłączenie odpowiedzialności w razie „W”
Wiec jak dane wyparują to klienci będą delikatnie mówiąc w ciemnej bo było sie zabezpieczyć. Ale to jest w umowie którą czyta co któryś a rozumie jeszcze może 10% z czytających.
Oczywiście taki portal jak opisany aż prosi się o wrzucenie do jakiegoś „dobrego dostawcy” dającego faktyczną infr.
Ale warto w takim art. rozróżnić pewne aspekty i pokazać wady i zalety przenoszenia i pokazać różnice miedzy portalem a np aplikacją wewn. albo wprost danymi firmowymi.
Widziałem już firmy które przeniosły się do chmury i po nie całym mc uciekały ponosząc olbrzymie koszty bo handlowcy nie mieli jak łączyć się z bazą. Cóż nie wszędzie w Polsce jest internet a oferent nie brał tego pod uwagę i nie zapewnił rozwiązania problemu który był wcześniej rozwiązany. Co więcej nie umiał go rozwiązać „na kolanie”.
Niestety takie sytuacje sa bardzo częste a ze świecą szukać w art. ostrzeżenia przed tymi ryzykami.
Tu wielki plus że pojawił się w artykule wątek giodo który większość skrzętnie zamiata pod dywan.
I na koniec to taka uwaga…
Ten artykuł nie opisuje przeniesienia czegokolwiek do chmury…
Przecież fotosik w chmurze był od zawsze ;)
To przykład zapewne modelowego przeniesienia do dostawcy.
Potem dzwonią ludzie mający infr opartą o tani router i 5 kabli i z emocjami w głosie stwierdzają ze oni przeniosą stronę do chmury bo to przyszłość… No to powodzenia w przesiadce z jednej chmurki do drugiej…
Czytając artykuł na tak zacnym portalu chciałbym żeby takich kwiatków nie było. Żeby było jasno pisane co zostało zrobione a nie mamienie chmurami.
O wiele ciekawsze i lepsze dla sponsora było by napisanie jak przechodziła migracja jak zapewniono bezpieczeństwo procesu jak zwiększono i dlaczego bezpieczeństwo danych jak zapewniono klientowi bezpieczeństwo na wypadek padu firmy dostawcy (bo zakładam ze odpowiedzialny dostawca ma taki plan jakby jednak padł) ewentualnie czy poinformowano klienta o ryzykach.
Jak zostało zrealizowane przerzucenie sporych ilości danych?
Ktoś latał z wiaderkiem po internecie czy może fizycznie dyski w wiaderku noszono? Przecież fotosik to spora studnia internetu ;)
Jaka była ciągłość usługi…
No i te kopie…
Sporo danych spory problem i koszt też.
Najbardziej interesuje mnie cena za usługę „przeprowadzania automatycznych testów funkcjonalnych lub wydajnościowych wykorzystując narzędzia takie jak GIT”… WTF?
Witaj Manto,
doprecyzowując zdanie: „W procesie ciągłego rozwoju aplikacji jesteśmy w stanie przeprowadzać automatyczne testy funkcjonalne lub wydajnościowe, wykorzystując narzędzia takie jak GIT czy Jenkins” –
chodzi o użycie repozytorium kodu GIT w połączeniu z możliwościami Jenkinsa i innych narzędzi zewnętrznych.
To oznacza, że można na krótki czas przygotować środowisko testowe, sprawdzić zachowanie aplikacji pod obciążeniem i po dowolnym czasie (np. godzinie lub dwóch) skasować całe środowisko.
Nazywamy tę możliwość „efemerycznością instancji”.
Pozdrawiamy,
zespół Oktawave
Nie, nie przenosimy – nie nalezymy do idiotow.
Pomijając już kwestię artykułu sponsorowanego, to nie jest takie wszystko proste.
Po pierwsze – na co komu elastyczna infrastruktura, jeśli aplikacja nie będzie miała odpowiedniej architektury żeby dała się skalować?
Po drugie – nie ma prostej dychotomii chmurawszystko in-house. Można np. wstawić swoje graty do kolokacji. Nie każdy potrzebuje być AS-em – można po prostu kupić adresy od operatora i zdać się na operatora (zwłaszcza w kolokacji). Każdemu według potrzeb.
Po trzecie – jak się robi np. backupy off-site w chmurze? U siebie/w kolokacji podchodzę do szafy, wyjmuję magazynek taśm, wsadzam nowy i ziu. A w Oktawave?
Po czwarte – mam aplikację webową, chcę przed nią wpiąć np. jakiegoś WAF-a dostępnego jako appliance. Jak to zrobić w chmurze?
Itede itepe.
Cześć Ymię,
Ad.1. Poza elastycznością jest jeszcze odporność na awarie, którą w chmurze łatwiej zbudować nawet dla aplikacji o standardowej architekturze. Poza tym uzupełnieniem są takie narzędzia jak autoskaler, który działa nie tylko na poziomie liczby wirtualnych maszyn, ale także na poziomie CPU/RAM w pojedynczej wirtualnej maszynie – to może być przydatne dla aplikacji o nierozproszonej architekturze.
Trzeba pamiętać też o wszystkich możliwościach związanych z automatyzacją (co wyraźnie może przełożyć się na koszty i jakość) za pomocą API.
Ad2. Samochody też można składać samemu, a jednak ludzie tego raczej nie robią (oprócz fanów). Zależy od podejścia: czy chcemy sobie dokładać pracy, wydawać więcej środków i sprawować 100% kontroli, czy też chcemy ułatwiać sobie życie?
Nie wszyscy mają też ku temu odpowiednią wiedzę. Poza tym chmura to brak kosztów wejścia i jeśli z jakiegoś powodu będziemy musieli się wycofać z inwestycji, to korzystając z rozwiązań chmurowych jest to bardzo proste. Kupując swoje graty i wstawiając do DC już niekoniecznie. Są też tacy, którzy lubią mieć swoje światełka i mrugające diody – tak jak napisałeś – każdemu wg potrzeb.
Ad.3. To zależy od konkretnej chmury, ale u nas możesz ustawić codziennie backupy do OCS’a i stamtąd pobrać sobie gotowe pliki .ovf do siebie i nagrać na taśmy, dyski czy cokolwiek. W ten sposób jeden backup leży w usłudze OCS (oddzielnej od reszt usług ), a drugi u Ciebie w szufladzie.
Ad.4 Bardzo prosto, skoro WAF jest dostępny jako appliance, to można go zainstalować na instancji albo zaimportować gotowego OVF’a bądź wręcz pobrać gotową z naszego marketu, np. https://www.oktawave.com/marketplace/Pages/Templates/Template.aspx?templateid=479 (Barracuda) czy https://www.oktawave.com/marketplace/Pages/Templates/Template.aspx?templateid=416 (Netscaler) lub https://www.oktawave.com/marketplace/Pages/Templates/Template.aspx?templateid=418 (Alteon)
Pozdrawiamy
zespół Oktawave
Ad.1 Owszem, nie twierdzę, że „w chmurze” nie ma zalet. Ale czasem te zalety nie rekompensują wad. Zwłaszcza jeśli nie potrafimy ich wykorzystać (sorry, dla jednowątkowej aplikacji zwiększanie liczby procesorów nic nie da, a pamięci ponad to, co mamy w żelazie i tak nie dasz).
Ad.2 Malownicze porównania z branżą samochodową są… no właśnie, są głównie malownicze i nic więcej. Jak zaczniemy mieć wymaganą homologację na każdy komputer podłączany do sieci, zaczniemy się martwić.
Ad.3 „stamtąd pobrać sobie gotowe pliki .ovf do siebie i nagrać na taśmy, dyski czy cokolwiek”. No właśnie – „pobrać”. Przy danych rzędu terabajtów to już konkretne koszty na łącza i obsługę ruchu. Powyżej pewnego poziomu prościej jest po prostu zamontować bibliotekę taśmową w serwerowni i raz na tydzień jeździć wymieniać magazynki. W rozwiązaniu wirtualnym, jakbyście się nie spinali, takiej możliwości nie ma (no, chyba że dostarczacie klientom dedykowane urządzenia backupowe, ale nie sądzę).
Ad.4 Pisałem o appliance, a nie „virtual appliance”. OVF-a zainstalować „każdy gupi potrafi”. Tu chodzi o realizację infrastruktury w oparciu o fizyczne klocki, które nie występują w opcji wirtualnej. Nie musi to być koniecznie WAF. Zgadzam się, że dużo (nie wiem czy można zaryzykować użycie słowa „większość”) rozwiązań występuje w opcjach „pudełkowej” i „wirtualnej”, ale równocześnie producenci zazwyczaj mocno zalecają wykorzystanie pudełek (i świadczą dużo lepsze wsparcie).
Za dużo śledzi! Pamiętajcie, że łatwiej jest korelować ruch, w tym z TORa, gdy wiele serwisów jest w rękach jednego usługodawcy chmury. Nie chodzi tylko o śledzenie po IP i czasie żądania i ciasteczkach samej witryny, ale też po dodatkowych ciasteczkach i właściwiściach dodawanych przez serwery tych chmur. Tak dla chmur obliczeniowych, stanowcze NIE dla chmur hostingowych.