Cloud computing

Cloud computing wraz z innymi popularnymi technikami produkcji oprogramowania, jak np. programowanie reaktywne, to znak naszych czasów, w których szybki dostęp do sieci Internet, duża moc obliczeniowa procesorów, mobilny charakter korzystania z usług informatycznych, rzucają razem nowe światło na stare, niekiedy bardzo stare koncepcje takie jak architektura systemów rozproszonych, programowanie funkcyjne czy nierelacyjne bazy danych.

Cloud computing to dla każdego coś innego. Użytkownikowi daje możliwość korzystania z aplikacji za pośrednictwem sieci bez konieczności posiadania licencji, trudów instalowania, ograniczeń sprzętowych, a więc z zachowaniem swobody i mobilności użytkowania. Dostawcy oprogramowania pozwala ograniczyć koszty związane z utrzymaniem i zarządzaniem aplikacjami klientów. Studio developerskie zauważy, że chmura na jednym fizycznym serwerze testowym umożliwi wdrażanie wielu systemów operacyjnych i środowisk uruchomieniowych dla budowanych aplikacji, silników baz danych, a także oprogramowania infrastruktury continuous integration. Cloud computing to dla wszystkich wygoda i oszczędność pieniędzy, odpowiednio wytworzona i zaserwowana aplikacja.

Architektura mikroserwisowa

Ciągła Integracja (CI – Continuous Integration) oraz Ciągłe Dostarczanie (CD – Continuous Delivery) – to techniki, które swej skuteczności dowiodły w projektach opartych o zwinny model wytwórczy (AD – Agile Development). W przypadku budowania systemów w architekturze mikroserwisowej są nieocenione. Tam wiele małych aplikacji współpracuje ze sobą, aby spełnić wymagania biznesowe i nie sposób wytwarzać taką aplikację bez konfiguracji środowiska uruchomieniowego i automatyzacji procesu testowania, budowania, uruchamiania i generalnie zarządzania cyklem życia instancji poszczególnych aplikacji (mikroserwisów) już na wczesnym etapie procesu wytwórczego.

Rozbicie jednego monolitycznego systemu na mikroserwisy rozwiązuje wiele problemów.

Ułatwia przebudowę istniejącego kodu – wprowadzanie zamierzonych zmian (refactoring), mających na celu poprawę architektury – poprzez ograniczenie pola eskalacji regresji do granic wyznaczonych przez pojedynczy mikroserwis. Zjawisko regresji to powstawanie trudnych do uniknięcia błędów w pewnych obszarach systemu spowodowanych zamierzonymi zmianami wprowadzanymi w innych obszarach.

Architektura mikroserwisowa pozwala zaoszczędzić zasoby w procesie skalowania, czyli zwielokrotniania instancji mikroserwisów, które zostały zbyt obciążone. Jej celem jest zniwelowanie odczuwalnego przez użytkownika niepożądanego efektu, polegającego na spowolnieniu, a w skrajnym przypadku zdestabilizowaniu działania aplikacji. W przypadku systemu monolitycznego skalowaniu ulega cała aplikacja mimo, iż cechą takich aplikacji jest to, że obciążenie nie rozkłada się równomiernie na wszystkie składowe i za spowolnienie lub destabilizację działania całości odpowiada nadmierne eksploatowanie pewnych fragmentów.

Zarządzanie kontenerami

System skalowania spełnia swoją rolę, kiedy oparty jest o wydajne środowisko wirtualizacji, w którym powielone instancje zamiast dublować, współdzielą pewne elementy systemu operacyjnego. Konteneryzacja – to wydajny system wirtualizacji, w którym izolowane środowiska wspólnie używają tego samego jądra głównego systemu operacyjnego, czyli systemu hosta (host os).

Uznanym w środowisku systemem konteneryzacji jest Docker. Wyznacza standardy w swej dziedzinie i jest wykorzystywany przez systemy orkiestracji, czyli zarządzania kontenerami, takie jak Kubernetes (pierwotnie stworzony przez Google) czy Mesos (powstały pod szyldem Apache Software Foundation w ramach szerszego projektu Mesos) lub OpenShift (rozwiązanie stworzone przez RedHat i bazujące na Kubernetes). System konteneryzacji oraz orkiestracja to podstawy świadczenia usług w chmurze.

NIST (National Institute of Standards and Technology) definiuje trzy tradycyjne modele świadczenia usług w chmurze. Model SaaS (Software as a Service), w którym użytkownik ma zapewniony dostęp do aplikacji w chmurze, czyli przez sieć, i nie musi nic instalować, konfigurować ani martwić się o całą infrastrukturę sprzętowo-systemową. Model PaaS (Platform as a Service), w której sam instaluje oprogramowanie na powierzonej infrastrukturze oraz model IaaS (Infrastructure as a Service), gdzie użytkownik sprawuje kontrolę na infrastrukturą na poziomie wyboru i konfiguracji systemu operacyjnego, a następnie w tak przygotowanym środowisku instaluje oprogramowanie. Konteneryzacja zapewnia we wszystkich trzech przypadkach wzajemną separację aplikacji, a tym samym powstałych wokół nich grup użytkowników.

Kultura DevOps

Nie byłoby studia developerskiego, dostawcy systemów i nie byłoby też użytkownika, gdyby nie było programisty, testera, wdrożeniowca, administratora, kierownika projektu i BDM’a, ponieważ wówczas nie byłoby aplikacji. Taka teza stawia pod znakiem zapytania potrzebę powstania tego artykułu… Załóżmy więc, choć przez chwilę, że te osoby istnieją i na dodatek współpracują ze sobą w jednym zespole. Ucząc się wzajemnie od siebie i wspierając, zapewniają wysoką jakość aplikacji oraz niezawodność środowiska działania. Wtedy możemy śmiało powiedzieć, że w organizacji mamy kulturę DevOps, w której obrośnięte legendami bariery między zespołami developerów, testerów, administratorów oraz średnim nadzorem technicznym zostały zniesione, ponieważ wszyscy stanowią jedną załogę i są świadomi, że mimo pracy w różnych obszarach, mimo posługiwania się różnymi językami i technikami, realizują ten sam cel, jakim jest dostarczenie na czas aplikacji wysokiej jakości, spełniającej potrzeby biznesowe klienta.

Znoszenie podziałów i niwelowanie wzajemnych, nieuzasadnionych niechęci zawsze jest trudne. W inżynierii oprogramowania czynnikiem ułatwiającym osiągnięcie tego stanu jest manifest zwinnego wytwarzania oprogramowania (Manifesto for Agile Software Development) wraz ze stosowaniem technik CI, CD, a idea dzielenia dużej, monolitycznej aplikacji na zbiór małych kooperujących mikroserwisów implikuje wykorzystanie mechanizmu konteneryzacji wraz z orkiestracją i przez to w naturalny sposób zbliża do siebie ludzi zgromadzonych wokół projektu, zmniejsza bariery między nimi, uczy współpracy, wzajemnej komunikacji. Tworzy świadomość i kulturę DevOps. Urzeczywistnia ideę Wieży Babel.