Cloud computing – sposób na budowanie środowisk deweloperskich

Wykorzystanie cloud computing w rozwoju oprogramowania rośnie dzięki prawie nieograniczonym zasobom mocy obliczeniowej, jakie możemy otrzymać od dostawców rozwiązań chmurowych, dużej elastyczności w zakresie samoobsługi, a także pełnej gotowości na różnego rodzaju integracje różnych komponentów aplikacyjnych.

Usługi dedykowane, np. kompletne środowisko uruchomieniowe, bazy danych, systemy kolejkowe, rozpoznawanie mowy, rozwiązania bezpieczeństwa i wiele im podobnych, stanowią prawdziwą odskocznię od standardowego IaaS, czyli infrastruktury w modelu samoobsługowym. Skoro świat chmury jest tak obiecujący i w zasadzie powinien być gwarancją sukcesu każdej organizacji, dlaczego wciąż działa jeszcze tyle własnych Centrów Danych? Czemu tak wiele usług nie zostało zmigrowanych do Microsoft Azure, AWS czy innych dostawców chmury publicznej?

Chmura a koszty i dojrzałość

Oczywiście jednym z powodów może być rachunek ekonomiczny, który dla wielu organizacji – aby nie powiedzieć znakomitej większości – jest czynnikiem najważniejszym. Jednak nie tylko finanse wpływają na wykorzystanie Cloud Computing w działach IT. Spośród wielu czynników istotna jest też dojrzałość organizacyjna i gotowość na wykonanie istotnej zmiany w procesie budowy usług. Mamy tu na myśli m.in. przejście z modelu Waterfall na Agile, co w działach technologicznych implikuje zmiany, a czasami nawet rewolucję – i to zarówno technologiczną jak i w obszarze struktury organizacyjnej. W procesie wejścia w świat chmury obliczeniowej oznacza to konieczność przystosowania się do korzystania z różnych komponentów w modelu XaaS, czyli bardzo dynamicznie zmiennym.

W modelu Cloud Computing już nie tylko rodzaj infrastruktury przestaje być istotny, ale kolejne warstwy, jak system operacyjny z bazą danych. Jak to możliwe? Dlatego, że za sprawą usług chmurowych pisząc kod aplikacji programista może – a z powodów ekonomicznych nawet musi – skupić się na zrealizowaniu oczekiwanej funkcjonalności. Dobrze jest zatem, aby jego znajomość silnika bazy danych, czy nawet magazynu dyskowego ograniczyła się do umiejętności użycia właściwych wywołań API. Silnik bazy danych, a tym bardziej system operacyjny, który go utrzymuje traci kompletnie na znaczeniu, ponieważ wymagane dane zostają dostarczone i aplikacja może je już przetwarzać.

Podobnie wygląda sytuacja w przypadku usług kognitywnych. Trudno sobie wyobrazić, aby w środowiskach chmury programista zastanawiał się, z jaką aplikacją ma do czynienia. Po prostu studiuje dokumentację, pozyskuje wiedzę jak wywołać poszczególne funkcje silników rozpoznawania, a następnie wysyła przez API zdjęcie i otrzymuje zwrotnie, przykładowo, znormalizowane emocje, jakie można rozpoznać na twarzy sfotografowanej osoby. Innymi słowy, jeśli liczymy na efektywne wykorzystanie cloud computing, powinniśmy unikać prostego odwzorowania obecne utrzymywanych usług na maszynach wirtualnych w chmurze.

Łatwo powiedzieć, trudniej zrobić!

Migracja developmentu do chmury

Skala trudności projektu migracji platform deweloperskich do modelu chmurowego zależy od stanu początkowego środowisk, które chcemy umieścić w chmurze. Poniekąd przypomina to… remont domu lub mieszkania. Jeśli mamy do czynienia ze stanem deweloperskim, choć może groźnie to wygląda, w zasadzie mamy pełną dowolność w dobieraniu wszystkiego, co będzie nas otaczało w wymarzonym miejscu do życia. Możemy wszystko uszyć na miarę – od podłóg, przez ściany, aż do mebli i wyposażenia.

Nieco trudniej może być wtedy, gdy robimy remont w miejscu, w którym od lat mieszkamy i nie zmieni się to nawet na czas realizacji prac. W tym przypadku ograniczeń jest znacznie więcej, a na dodatek wszystko musi działać w czasie wykonywania wspomnianego remontu. Wygodnie nie będzie nam na pewno. Poniekąd może być relatywnie bezpiecznie, bo – pomimo przenoszenia mebli z pokoju do pokoju – ciągle mamy gdzie mieszkać i ciągle jest to nasz dom.

Bardzo podobnie wygląda sytuacja z podróżą do chmury. Jeśli dopiero zaczynamy rozwijać ten obszar, to wybór modelu cloud wydaje się być oczywisty. Wszystko jest na wyciągnięcie ręki, nie mamy żadnych przyzwyczajeń i naleciałości, z którymi musielibyśmy się zmagać. Potrzebujemy magazyn danych – jest łatwo dostępny, a w dodatku wystandaryzowany np. za pomocą protokołu S3. Potrzebujemy bazę danych, oczywiście jest pod ręką – wystarczy skonstruować kwerendę SQL podając wcześniej parametry połączenia. CRM? Też nie jest problemem. Tylko wyobraźnia może nas ograniczać jak dalece chcemy go parametryzować, modyfikować i integrować z innymi aplikacjami.

Na koniec z tej samej chmury wszystko możemy serwować naszemu klientowi i to w modelu wysokodostępnym (HA – High Availability), bezpośrednio do jego przeglądarki czy aplikacji mobilnej. Gorzej jest, kiedy musimy zmigrować do chmury istniejące i stale wykorzystywane środowisko – szczególnie, jeśli mówimy o dużej organizacji i znacznej ilości aplikacji i komponentów. Wówczas należy rozważyć, jakie usługi i obszary warto przenieść do chmury, jakie są nasze oczekiwania po takiej migracji i jakie następstwa taka zmiana implikuje. Można tu wymienić wiele scenariuszy, ale w modelu hybrydowym najczęściej migrowane są do chmury środowiska deweloperskie i testowe, środowiska zapasowe, a także te usługi, które cyklicznie wymagają dużych mocy obliczeniowych.

Sprawna integracja to podstawa

W zasadzie niezależnie od scenariusza należy zadbać o połączenie środowiska lokalnego z chmurową odnogą naszego IT. Tu z pomocą przychodzą technologie dobrze znane, takie jak dedykowane łącza, Site-to-Site VPN, czy IPSec. W ostatnim czasie szczególnie zwiększonym zainteresowaniem cieszy się SD-WAN (Sotware-Defined Wide Area Network). Aktywność tę wspierają sami dostawcy chmury, np. Microsoft oferując w Azure Marketplace gotowe rozwiązania do terminowania ruchu w warstwie Overlay, charakterystycznej dla SD-WAN.

Powodów rosnącej popularności tej technologii jest kilka, ale by je zauważyć, warto uzmysłowić sobie, jakie efekty zapewnia technologia wirtualizacji sieci rozległej. Jest to mianowicie agregacja połączeń – najczęściej MPLS i klasycznych łączy internetowych uwzględniając także 4G/LTE. Oznacza to, że stosunkowo małym kosztem – przy jednoczesnym uproszczeniu zarządzania siecią WAN – uzyskuje się sensowne łącze, które z punktu widzenia warstw 4-7 modelu OSI jest jednym kanałem komunikacji, choć w istocie łączy w sobie wiele ścieżek w warstwach 1-4.

Konkluzja jest taka, że relatywnie łatwo i tanio można zyskać bardzo wydajne i redundantne połączenie do środowiska chmury obliczeniowej – niezależnie od tego, co dokładniej w niej utrzymujemy. Drugą cechą rozwiązań klasy SD-WAN jest przeniesienie ciężaru zdefiniowania polityk QoS w stronę aplikacji. Oznacza to, że stosując takie rozwiązanie możemy rozmawiać o wydajności aplikacji, a nie poszczególnych adresach IP czy portach TCP/UDP. To istotna zmiana, ponieważ w środowiskach dynamicznych – a do takich z pewnością należą środowiska chmury obliczeniowej – ciężko sobie wyobrazić regulowanie polityk sieciowych co zmianę kodu, bo może to trwać kilka dni lub kilka godzin.

Potrzeba automatyzacji

Powiedzieliśmy zatem o pewnym pomoście sieciowym do chmury obliczeniowej – czas spojrzeć na same aplikacje. SD-WAN pozwoli nam oczywiście optymalnie przesłać pakiety, dokładnie je kategoryzując i nadając im właściwy priorytet. Jeśli jednak chcemy dostarczać naszą usługę aplikacyjną w modelu hybrydowym – to znaczy część serwerów będzie pracowała z własnego Centrum Danych, a jedynie część z chmury – musimy zastosować rozwiązanie typu ADC (Application Delivery Controller).

Na dodatek musi to być komponent, który będzie można zintegrować z automatyką danej chmury. Najczęściej bowiem taki hybrydowy scenariusz jest tworzony z myślą o przetrwaniu wzmożonej aktywności klientów, a zatem również utylizacji naszych zasobów. Flagowy przykład to portale takie, jak Aliexpress, Allegro czy OLX, które przeżywają prawdziwe oblężenie przed Bożym Narodzeniem. Wtedy dodatkowe serwery dostarczające klientom katalog towarów, ale także obsługujące koszyk, czy płatności elektroniczne to zbawienie dla biznesu.

Aby jednak automatyczne skalowanie działało, w praktyce musi doskonale integrować się z chmurą obliczeniową i wyzwalać zarówno tworzenie nowych komponentów, jak i ich konfigurację oraz likwidację. W tym miejscu dochodzimy do niezwykle ważnego obszaru środowisk chmurowych i hybrydowych, jakim jest automatyzacja. Jest ona szczególnie istotna wtedy, gdy chcemy wykorzystać chmurę publiczną, jakże łatwo dostępną i elastyczną pod różnymi względami, do tworzenia oprogramowania z zamiarem jego uruchamiania we własnym centrum danych.

Może się bowiem okazać, że aplikacji stworzonych w środowisku chmurowym nie będzie można przenieść do środowiska klasycznego, ponieważ będą one odwoływały się do automatycznych procesów, które w modelu on-premise bardzo często nie są dostępne. Skoro jednak funkcje takie nie są dostępne w ramach lokalnego środowiska, to zapewne można je wybudować. W pewnym sensie jest to właśnie recepta na stworzenie chmury hybrydowej.

Sięgając po rozwiązania typu VMware vRealize Automation, Microsoft System Center, Ansible, vRealize CodeStream czy Microsoft Team Foundation Server, część automatycznych procesów możemy odwzorować poza chmurą publiczną. Wtedy okaże się, że przepis na aplikacje, który w oparciu o rozwiązania chmurowe przygotował dla naszej usługi programista, da się zrealizować także w lokalnym Data Center, jeśli tylko wskażemy, gdzie znajdują się potrzebne narzędzia, takie jak nośnik instalacyjny do właściwej wersji systemu czy aplikacji, obraz Docker itp.

Może się okazać, że podobnie jak SD-WAN łączy dwa światy w warstwie sieci, tak rozwiązania automatyzujące wykonają podobne co do idei zadania w warstwie aplikacyjnej. Podsumowując, warto sprawdzić, które z elementów używanych w ramach chmurowego środowiska deweloperskiego będą potrzebne w lokalnym Centrum Danych i jakie narzędzia automatyzacji realnie poradzą sobie z ich integracją.

Bez zabezpieczeń ani rusz

Mówiąc o modelu chmury nie sposób pominąć także kwestii bezpieczeństwa. Wszystkie konfiguracje zapór sieciowych czy zapór aplikacji webowych również powinny stanowić integralną część przepisu na sprawne chmurowe środowisko deweloperskie. Szczególnie warto w takim środowisku udostępnić WAF, gdyż jeśli zostanie on właściwie skonfigurowany w procesie tworzenia aplikacji, to na etapie wdrożenia jego włączenie nie spowoduje w zasadzie niczego.

Kolejna sprawa, o której należy myśleć w modelu hybrydowym i takim, w którym w chmurze publicznej tworzymy aplikacje, to obszar AAA, czyli Autentykacja, Autoryzacja i Audyt. Mówimy tu o użytkownikach, ale także o komponentach poszczególnych usług. Decydując się na wykorzystanie cloud computing i tworzenie tam aplikacji musimy pamiętać o tym, jak i gdzie będziemy uwierzytelniać różnego rodzaju konta, użytkowników i usługi, a także w jaki sposób będziemy nadawali im uprawnienia i sprawdzali jakie operacje w rzeczywistości wykonują. To wszystko jest istotne zarówno z perspektywy bezpieczeństwa, ale też w kontekście rozwiązywania potencjalnych problemów. Należy zatem zapewnić spójne środowisko zarządzania tożsamością dla połączonych instancji on-premise oraz cloud.

Licencje i procesy

Warto też wspomnieć o kwestii licencjonowania różnych technologii, które w przypadku wykorzystania chmury publicznej ma niemałe znaczenie – szczególnie w modelach hybrydowych i w czasie migracji. Bardzo istotne jest sprawdzenie, czy możemy, dla jakich komponentów i na jakich zasadach wykorzystać posiadane licencje. Czy można je migrować do chmury? Czy są jakieś ograniczenia w tym zakresie? Jest to istotne dla zapewnienia dynamiki balansowania utylizacji własnego Centrum Danych i chmury dostawcy, ale również na potrzeby kalkulacji ewentualnego wyboru jednego rozwiązania, czyli wyboru jedynie własnej infrastruktury lub pełnej migracji do chmury publicznej. Szkoda byłoby oczywiście stracić kupione już licencje.

Na koniec wróćmy do procesów, szczególnie w zakresie testowania aplikacji i monitorowania jej pracy. Jeśli całość usługi dostarczamy z chmury, to w zasadzie nie ma problemu. Jeśli jednak rozwijamy aplikację w Azure czy AWS, ale uruchamiany ją produkcyjne na własnej infrastrukturze warto jest dobrze sprawdzić współczynniki skalowania wydajności i pojemności. To, co jest dobrodziejstwem chmury, może okazać się zmorą w klasycznym Centrum Danych, nawet jeśli jest ono w pełni zautomatyzowane, monitorowane i właściwie połączone ze środowiskiem cloud.

Otóż wydajność kodu przetestowanego w chmurze może w żaden sposób nie odpowiadać, z powodu złożoności całej usługi, parametrom środowiska on-premise. Znalezienie właściwego sposobu na precyzyjne szacowanie wydajności przy efekcie skali wydaje się mieć kluczowe znaczenie. Pamiętajmy, że środowiska chmur publicznych ograniczają nas tylko… limitem karty kredytowej. Zatem, jeśli napisany kod wymaga do realizacji funkcjonalności większej niż wcześniej zakładana mocy obliczeniowej, to w wielu przypadkach można ją błyskawicznie pozyskać. Aplikacja przeniesiona na produkcję we własnym Centrum Danych już takiego komfortu mieć nie będzie.

Chmura dla software developmentu

Już dzisiaj wiele organizacji sięga po dobrodziejstwa chmury obliczeniowej i to zarówno w modelu całościowym, jak i hybrydowym. Mimo, iż przygoda ta wymaga jeszcze wiele przygotowań i analiz, jesteśmy na dobrej drodze, aby coraz bardziej optymalnie budować rozwiązania i dostarczać nowe wartości biznesowe w oparciu o cloud computing. Oczywiście pozostają jeszcze kwestie formalno-prawne, regulatorzy i rekomendacje, ale to temat na kolejną opowieść.