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?
Środowiska developerskie i cloud w skrócie
- W chmurze programiści są niezależni od konfiguracji infrastruktury i mogą w pełni poświęcić się tworzeniu nowych funkcjonalności.
- Jeśli chcemy efektywnie wykorzystać cloud, powinniśmy unikać migracji 1:1 obecnego środowiska lokalnego na maszyny wirtualne w chmurze. Najczęściej migrowane są środowiska deweloperskie, testowe i zapasowe oraz usługi wymagające cyklicznie dużych mocy obliczeniowych.
- Środowisko lokalne i chmurę można połączyć z pomocą dedykowanego łącza, Site-to-Site VPN, IPSec bądź SD-WAN. SD-WAN zyskuje na popularności jako stosunkowo tanie i bardzo wydajne połączenie do chmury. Jeśli chcemy wykorzystać chmurę publiczną do tworzenia oprogramowania, a uruchamiać je we własnym centrum danych, musimy wprowadzić automatyzację procesów.
- Tworząc aplikacje w chmurze musimy pamiętać o procesach nadawania uprawnień, uwierzytelniania kont, użytkowników i usług oraz monitoringu wykonywanych operacji.
Korzystając z chmury i własnego centrum danych należy zwrócić uwagę na posiadane licencje – czy i w jakim zakresie można je wykorzystywać w środowisku cloudowym.
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