W listopadzie zeszłego roku firma Forrester przewidywała, że w 2020 roku wartość rynku chmury publicznej wzrośnie do 299,4 mld USD. W związku z tym nie powinno dziwić, że firmy chcą czerpać korzyści z zalet przetwarzania w chmurze przez tworzenie aplikacji typu cloud-native. Dzięki temu można uzyskać wyjątkowo elastyczne aplikacje, które mogą być tworzone i wdrażane szybciej niż kiedykolwiek przedtem.
| REKLAMA | ||
 |
Ponadto, przejście na model cloud-native pozwala organizacji stopniowo przenieść swoje stare usługi na skonteneryzowane platformy oparte na usługach i interfejsach API. Nadzór nad nimi sprawowany jest przez zautomatyzowane procedury zespołu DevOps.
Model tworzenia aplikacji natywnych dla chmury można stosować zarówno podczas tworzenia, jak i wdrażania produktu lub usługi. Wymaga to jednak uwzględnienia wielu nowych procedur. Jedną z najbardziej wymagających jest kultura DevOps.
DevOps
DevOps to kultura pracy wykorzystująca zestaw procedur i procesów, które łączą działy tworzenia oprogramowania i działy operacyjne. Programiści i administratorzy podobnie rozumieją swoją pracę i wspólnie czują się za nią odpowiedzialni, co owocuje o wiele bardziej zintegrowanym podejściem do budowy i wdrażania aplikacji.
Wdrożenie kultury i procedur DevOps może się okazać nie lada wyzwaniem. Zmiana codziennych zadań pracowników z natury powoduje zakłócenia, zwłaszcza wtedy, gdy łączy się kulturę, procesy i przepływy pracy dwóch różnych działów w jeden, z inną strukturą, misją i zestawem procesów.
Mimo że wdrożenie podejścia DevOps wymaga czasu i wysiłku, liderzy IT zdają sobie sprawę z tego, że długoterminowe korzyści z tej transformacji przeważają nad początkowymi trudnościami. Ewolucja na pewno pochłonie dużo czasu, ale po jej ukończeniu firma będzie czerpać korzyści z szybszego tworzenia oprogramowania i będzie dysponować bardziej elastycznymi aplikacjami.
Rozwój modułowej architektury
Kolejną częścią zagadnienia cloud-native jest wdrożenie modułowej architektury, w której funkcje aplikacji są podzielone na niezależne moduły. Jednym ze sposób prowadzących do tego celu jest wdrożenie architektury mikrousług, gdzie aplikacje są podzielone na jak najmniejsze, niezależne od siebie części. Architektura ta dobrze sprawdza się w aplikacjach chmurowych, ponieważ tak jak one charakteryzuje się elastycznością i modułowością.
Większość udanych wdrożeń mikrousług polega na przełamaniu monolitycznej aplikacji i podzieleniu jej na mniejsze komponenty. Dzięki analizie dotychczasowego monolitu programiści mogą zobaczyć, w jaki sposób poszczególne „części” aplikacji ze sobą współpracują, co pomaga im określić, gdzie powinny znajdować się granice mikrousług.
Dotychczasowych aplikacji monolitycznych nie można jednak tak po prostu wyrzucić — wiele z nich sprawnie realizowało swoje funkcje w danej organizacji przez wiele lat. W przypadku tych aplikacji należy skupić się na stopniowym przechodzeniu do modelu cloud- native, a nie na dostosowywaniu ich na siłę do standardu. W miarę możliwości należy także zidentyfikować, które części monolitu mogą być udostępniane przez interfejsy API. Dopiero potem można zacząć dzielić monolityczne aplikacje na mikro- lub miniusługi.
Infrastruktura automatyzacji i samoobsługi
Zadania IT wykonywane ręcznie to ogromna strata czasu dla programistów i działów operacji. Automatyzacja tej pracy może zapewnić zespołowi więcej czasu i zasobów, dzięki czemu oprogramowanie będzie można budować i wdrażać o wiele szybciej. W związku z tym stosowanie metod zarządzania infrastrukturą i narzędzi do automatyzacji pracochłonnych procesów wykonywanych ręcznie, jest kluczową częścią strategii cloud-native.
Tak samo ważne jest dbanie o możliwość ponownego wykorzystywania kodu w procesie tworzenia aplikacji. Ponowne tworzenie np. usług buforowania, mechanizmów przepływów pracy lub konektorów integracji może być dużą stratą czasu. Nowoczesne oprogramowanie middleware wykorzystuje kontenery i mikrousługi, a programiści powinni z nich korzystać, ponieważ ich możliwości zostały już zoptymalizowane i zintegrowane z bazową infrastrukturą opartą na kontenerach.
Filozofia ta obejmuje również infrastrukturę, której używa firma. Samoobsługowa infrastruktura na żądanie pomaga zespołom szybko tworzyć spójne środowiska, dzięki czemu programiści mogą skupić się na budowie aplikacji bez tracenia czasu. Kontenery i technologia orkiestracji kontenerów pomagają uprościć dostęp do bazowej infrastruktury aplikacji oraz umożliwiają zarządzenie cyklem życia aplikacji w różnych środowiskach — w chmurach prywatnych i publicznych lub w centrach przetwarzania danych.
Małe kroki
Przejścia na programowanie cloud-native nie dokonuje się z dnia na dzień. Należy je raczej postrzegać jako stopniowy proces oraz okazję do nauki. Oprócz kilku wyjątków (takich jak start-upy) większość przedsiębiorstw ma złożoną infrastrukturę informatyczną, w skład której wchodzą zarówno aplikacje lokalne, jak i usługi chmurowe. Ponadto połączenie wszystkich systemów i platform w jedną architekturę jest dla większości organizacji nierealne — w każdym razie nie naraz. Nowe aplikacje można od razu uruchomić w chmurze, natomiast przeniesienie tam dotychczasowych aplikacji to dłuższy proces.
Kluczem do pomyślnego wdrożenia podejścia cloud-native jest metoda małych kroków. Warto zacząć od migracji monolitów i aplikacji do chmury — w centrum danych przedsiębiorstwa lub poza nim. Następnie należy skonteneryzować obciążenia i wdrożyć platformę orkiestracji kontenerów. A potem trzeba przyjrzeć się monolitom i ocenić, które z nich można podzielić na mikrousługi lub funkcje serverless.
W miarę uruchamiania nowych usług także wcześniej wykorzystywane aplikacje zaczynają czerpać korzyści z usług chmurowych, jak choćby integracja, automatyzacja procesów biznesowych czy zarządzanie interfejsami API. Chmura staję się w tym przypadku narzędziem dającym nowe możliwości monolitom.
W następnym etapie najważniejsze jest zaś ciągłe uczenie się i wprowadzanie udoskonaleń. W miarę jak zespół IT będzie coraz bardziej obeznany ze zmianami wiążącymi się z podejściem cloud-native, można dostosować procesy i zwiększyć produktywność zarówno programistów, jak i samego oprogramowania.
Źródło: Red Hat
Model tworzenia aplikacji natywnych dla chmury można stosować zarówno podczas tworzenia, jak i wdrażania produktu lub usługi. Wymaga to jednak uwzględnienia wielu nowych procedur. Jedną z najbardziej wymagających jest kultura DevOps.
DevOps
DevOps to kultura pracy wykorzystująca zestaw procedur i procesów, które łączą działy tworzenia oprogramowania i działy operacyjne. Programiści i administratorzy podobnie rozumieją swoją pracę i wspólnie czują się za nią odpowiedzialni, co owocuje o wiele bardziej zintegrowanym podejściem do budowy i wdrażania aplikacji.
Wdrożenie kultury i procedur DevOps może się okazać nie lada wyzwaniem. Zmiana codziennych zadań pracowników z natury powoduje zakłócenia, zwłaszcza wtedy, gdy łączy się kulturę, procesy i przepływy pracy dwóch różnych działów w jeden, z inną strukturą, misją i zestawem procesów.
Mimo że wdrożenie podejścia DevOps wymaga czasu i wysiłku, liderzy IT zdają sobie sprawę z tego, że długoterminowe korzyści z tej transformacji przeważają nad początkowymi trudnościami. Ewolucja na pewno pochłonie dużo czasu, ale po jej ukończeniu firma będzie czerpać korzyści z szybszego tworzenia oprogramowania i będzie dysponować bardziej elastycznymi aplikacjami.
Rozwój modułowej architektury
Kolejną częścią zagadnienia cloud-native jest wdrożenie modułowej architektury, w której funkcje aplikacji są podzielone na niezależne moduły. Jednym ze sposób prowadzących do tego celu jest wdrożenie architektury mikrousług, gdzie aplikacje są podzielone na jak najmniejsze, niezależne od siebie części. Architektura ta dobrze sprawdza się w aplikacjach chmurowych, ponieważ tak jak one charakteryzuje się elastycznością i modułowością.
Większość udanych wdrożeń mikrousług polega na przełamaniu monolitycznej aplikacji i podzieleniu jej na mniejsze komponenty. Dzięki analizie dotychczasowego monolitu programiści mogą zobaczyć, w jaki sposób poszczególne „części” aplikacji ze sobą współpracują, co pomaga im określić, gdzie powinny znajdować się granice mikrousług.
Dotychczasowych aplikacji monolitycznych nie można jednak tak po prostu wyrzucić — wiele z nich sprawnie realizowało swoje funkcje w danej organizacji przez wiele lat. W przypadku tych aplikacji należy skupić się na stopniowym przechodzeniu do modelu cloud- native, a nie na dostosowywaniu ich na siłę do standardu. W miarę możliwości należy także zidentyfikować, które części monolitu mogą być udostępniane przez interfejsy API. Dopiero potem można zacząć dzielić monolityczne aplikacje na mikro- lub miniusługi.
Infrastruktura automatyzacji i samoobsługi
Zadania IT wykonywane ręcznie to ogromna strata czasu dla programistów i działów operacji. Automatyzacja tej pracy może zapewnić zespołowi więcej czasu i zasobów, dzięki czemu oprogramowanie będzie można budować i wdrażać o wiele szybciej. W związku z tym stosowanie metod zarządzania infrastrukturą i narzędzi do automatyzacji pracochłonnych procesów wykonywanych ręcznie, jest kluczową częścią strategii cloud-native.
Tak samo ważne jest dbanie o możliwość ponownego wykorzystywania kodu w procesie tworzenia aplikacji. Ponowne tworzenie np. usług buforowania, mechanizmów przepływów pracy lub konektorów integracji może być dużą stratą czasu. Nowoczesne oprogramowanie middleware wykorzystuje kontenery i mikrousługi, a programiści powinni z nich korzystać, ponieważ ich możliwości zostały już zoptymalizowane i zintegrowane z bazową infrastrukturą opartą na kontenerach.
Filozofia ta obejmuje również infrastrukturę, której używa firma. Samoobsługowa infrastruktura na żądanie pomaga zespołom szybko tworzyć spójne środowiska, dzięki czemu programiści mogą skupić się na budowie aplikacji bez tracenia czasu. Kontenery i technologia orkiestracji kontenerów pomagają uprościć dostęp do bazowej infrastruktury aplikacji oraz umożliwiają zarządzenie cyklem życia aplikacji w różnych środowiskach — w chmurach prywatnych i publicznych lub w centrach przetwarzania danych.
Małe kroki
Przejścia na programowanie cloud-native nie dokonuje się z dnia na dzień. Należy je raczej postrzegać jako stopniowy proces oraz okazję do nauki. Oprócz kilku wyjątków (takich jak start-upy) większość przedsiębiorstw ma złożoną infrastrukturę informatyczną, w skład której wchodzą zarówno aplikacje lokalne, jak i usługi chmurowe. Ponadto połączenie wszystkich systemów i platform w jedną architekturę jest dla większości organizacji nierealne — w każdym razie nie naraz. Nowe aplikacje można od razu uruchomić w chmurze, natomiast przeniesienie tam dotychczasowych aplikacji to dłuższy proces.
Kluczem do pomyślnego wdrożenia podejścia cloud-native jest metoda małych kroków. Warto zacząć od migracji monolitów i aplikacji do chmury — w centrum danych przedsiębiorstwa lub poza nim. Następnie należy skonteneryzować obciążenia i wdrożyć platformę orkiestracji kontenerów. A potem trzeba przyjrzeć się monolitom i ocenić, które z nich można podzielić na mikrousługi lub funkcje serverless.
W miarę uruchamiania nowych usług także wcześniej wykorzystywane aplikacje zaczynają czerpać korzyści z usług chmurowych, jak choćby integracja, automatyzacja procesów biznesowych czy zarządzanie interfejsami API. Chmura staję się w tym przypadku narzędziem dającym nowe możliwości monolitom.
W następnym etapie najważniejsze jest zaś ciągłe uczenie się i wprowadzanie udoskonaleń. W miarę jak zespół IT będzie coraz bardziej obeznany ze zmianami wiążącymi się z podejściem cloud-native, można dostosować procesy i zwiększyć produktywność zarówno programistów, jak i samego oprogramowania.
Źródło: Red Hat
