Po czym poznać dobrego specjalistę IT?
… jest leniwy. Leniwy, w pozytywnym tego słowa znaczeniu, czyli robi wszystko w taki sposób, żeby zminimalizować ilość pracy przeznaczonej na dane zadanie, ale na tyle porządnie, żeby mu się to nie odbiło przysłowiową czkawką.
Podobnie organizacje podchodzą do tematu transformacji cyfrowej. W większości przypadków, zamiast uwolnić się od wszystkich obciążeń związanych z monolityczną architekturą aplikacji i przepisać ją po nowemu, w oparciu o mikroserwisy, działając zgodnie ze zwinnymi metodykami w obszarze rozwoju oprogramowania i jego późniejszego utrzymania, robimy coś zupełnie innego – konteneryzujemy.
Podejście lift&shift – co to jest?
Podejście lift&shift, czyli zamknięcie naszej monolitycznej aplikacji w kontenerach, bez modyfikacji, jest drogą na skróty do upragnionej zwinności. Kontenery dają nam bardzo szybko namacalne efekty. Aplikacja zyskuje, tak bardzo potrzebną w środowiskach multi-cloud, przenaszalność. Deweloperzy przestają być zależni od infrastruktury i dostają swoje upragnione API, za pomocą którego mogą obyć się bez pomocy administratora i powołać do życia potrzebne zasoby samemu. Co potrzebujemy zrobić, żeby wdrożyć warstwę kontenerów, na której nie będziemy się bali położyć aplikacji produkcyjnych? Przede wszystkim musimy wybrać samą platformę, wygospodarować trochę przestrzeni na naszych zasobach wirtualnych i zarezerwować kawałek sieci. Jeżeli zaimplementowaliśmy już w naszej organizacji podejście ITaaS (IT as a Service) w postaci chmury, trzeba jeszcze dodać usługi związane z kontenerami do naszego katalogu serwisów i voilà, można używać. Zmiana po stronie procesów i kultury organizacyjnej jest zupełnie niewymagana. Deweloperzy wreszcie nie czekają na infrastrukturę, a dzięki procesom automatyzacji platformy kontenerowej infrastruktura nie musi się zajmować składaniem stosu technologicznego dla deweloperów. Utopia? Nie do końca… Pakowanie tradycyjnych, monolitycznych aplikacji w kontenery, jest odwlekaniem nieuniknionego, czyli zmiany architektury całej aplikacji, na taką, która będzie działała natywnie w środowiskach chmurowych. Coś co może być rozwiązaniem dobrym w chwili obecnej, z czasem zmieni się w tykającą bombę. Prędzej czy później będziemy musieli przeznaczyć czas na wykonanie tego zabiegu, tylko czy wtedy konkurencja nie będzie już daleko z przodu?
Cloud Native jako alternatywa
Jak wygląda odmienne podejście? Takie, w którym rozwiązujemy nasze problemy tu i teraz, a nie zostawiamy ich na przyszłość udając, że ich nie ma. Podejście Cloud Native jest dużo trudniejsze do wykonania i czasochłonne. Musimy przeprojektować architekturę naszych aplikacji. Oczywiście nie wszystkie uda się objąć taką zmianą, ze względów technologicznych czy biznesowych, ale generalnie transformacja w obszarze technologii jest stosunkowo prosta. Dużo większe wyzwania czekają nas przy wdrożeniu zwinnych metodyk, które są niezbędne do dopełnienia części technicznej i szybkiego reagowania całej organizacji na czynniki zewnętrzne. Co jest nam potrzebne od strony szeroko pojętej infrastruktury? Potrzebujemy minimum platformy kontenerowej, a idealnie PaaSa aplikacyjnego, rury wdrożeniowej, które zapewnią nam Continuous Deployment (CD), centralne repozytorium kodu i IaaSa, na którym to wszystko zostanie zainstalowane. Mając do dyspozycji tak zautomatyzowane środowisko, zespoły deweloperskie pracujące zgodnie ze zwinnymi metodykami i biznes nadający kierunek, jesteśmy w stanie być dużo bardziej konkurencyjni na rynku i szybciej reagować na zmiany.
Lift&shift czy Cloud Native?
Które droga jest lepsza? Tykająca bomba czy organizacyjny „big bang”? Na poziomie taktycznym lift&shift zapewni nam, bardzo szybko i bez dużego nakładu pracy, tak poszukiwaną dzisiaj przez firmy zwinność infrastruktury. W późniejszym czasie i tak trzeba będzie wykonać transformację do Cloud Native. Z kolei holistyczna strategia Cloud Native zaprocentuje dużo później, ale jej efekty będą długoterminowe i mocno przełomowe dla naszej firmy – zwinność organizacyjna i technologiczna na wszystkich poziomach, dojrzałość architektury aplikacji i przede wszystkim możliwość skupienia się na innych inicjatywach np. IoT, AI, ML czy czymkolwiek innym co będzie w danej chwili na czasie.
Bo tak działa dzisiejszy świat IT, trzeba „odhaczyć” projekt i zabierać się szybko za następny, bo pewnie i tak już jesteśmy spóźnieni…
Filip Kata, Enterprise Architect, Dell Technologies Polska.
