Key Takeaways
Trend czy tradycja?: DevOps nie jest już przełomowym trendem, lecz ugruntowanym sposobem prowadzenia działalności, zakorzenionym w praktykach zarówno programistów, jak i specjalistów IT. Oznacza to jego ewolucję od radykalnego pomysłu do powszechnie stosowanej metodyki.
Filozofia DevOps: DevOps oznacza połączenie tworzenia oprogramowania i operacji IT w celu przyspieszenia dostarczania oraz poprawy jakości oprogramowania. Opiera się na kulturze współpracy i ciągłej ewolucji, dążąc do przełamania tradycyjnych podziałów na odizolowane zespoły.
Ewolucja technologii wspiera DevOps: Rozwój konteneryzacji, ekosystemów natywnych dla chmury oraz infrastruktury jako kodu (IaC) wzmocnił ruch DevOps, zapewniając większą elastyczność i wydajność procesów tworzenia oraz wdrażania oprogramowania.
Bezpieczeństwo zyskuje ważne miejsce: Pojawienie się DevSecOps integruje bezpieczeństwo z początkowymi etapami tworzenia oprogramowania, podkreślając zmianę w kierunku priorytetowego traktowania wczesnego wykrywania podatności w celu minimalizacji ryzyka.
Kultura i narzędzia idą w parze: Choć DevOps znacząco korzysta z postępu technologicznego, takiego jak sztuczna inteligencja i uczenie maszynowe, jego istota koncentruje się na budowaniu pozytywnej kultury, która stawia na pierwszym miejscu ludzi, współpracę i ciągłe doskonalenie.
Kiedy trend technologiczny przestaje być trendem i po prostu staje się codziennością biznesową?
Moglibyśmy długo dyskutować o tym konkretnym punkcie zwrotnym – nie ma jednej „poprawnej” odpowiedzi na to pytanie. Wystarczy powiedzieć, że gdy „trend” wkracza już w drugą dekadę – jak ma to miejsce w przypadku kultury i praktyk DevOps – staje się po prostu sposobem wykonywania pracy. (Według większości źródeł DevOps zaczął przybierać swój obecny kształt około 2007 roku.)
W naszym Kompletnym przewodniku po DevOps zdefiniowaliśmy to pojęcie w następujący sposób: „DevOps to zestaw praktyk i filozofii łączących tworzenie oprogramowania (Dev) i operacje IT (Ops), mających na celu skrócenie cyklu życia tworzenia systemów oraz zapewnienie ciągłego dostarczania oprogramowania o wysokiej jakości. To podejście kładzie nacisk na współpracę, komunikację i integrację między programistami a specjalistami IT”.
We wcześniejszych fazach dla niektórych specjalistów IT brzmiało to dziwnie i przerażająco – wręcz radykalnie. Dziś jest tak powszechne, że stało się codziennością. W raporcie CD Foundation „Stan CI/CD” 83% programistów stwierdziło, że angażuje się w działania związane z DevOps. To jeszcze nie wszyscy, ale z pewnością jesteśmy już blisko.
Jednocześnie DevOps – który jest w równym stopniu kulturą, co dowolnym konkretnym zestawem narzędzi lub procesów – z samej swojej natury nieustannie ewoluuje.
W tym artykule przyjrzymy się temu, jak dotarliśmy do obecnego punktu – oraz jak DevOps nadal ewoluuje. Najpierw ważne jest zrozumienie, dlaczego DevOps w ogóle istnieje.
Dlaczego DevOps jest ważny?
DevOps łączy pojęcia „tworzenie oprogramowania” i „operacje” – dwie od dawna istniejące dziedziny technologii. Głównym celem DevOps jest wspieranie wysokiego stopnia integracji między tymi dwoma ważnymi elementami systemu IT, ze szczególnym naciskiem na ciągłe dostarczanie i testowanie jakości oprogramowania. Tradycyjnie funkcje te były rozdzielone i odizolowane – powodowało to wąskie gardła, opóźnienia w dostarczaniu, problemy z jakością, wzajemne obwinianie się (gdy coś szło nie tak), luki w zabezpieczeniach i inne problemy.
DevOps – zarówno jako termin, ale przede wszystkim jako kultura i praktyka – odzwierciedla potrzebę, aby organizacje tworzące oprogramowanie budowały je i wdrażały szybciej oraz częściej, bez poświęcania jakości, niezawodności ani bezpieczeństwa.
Jak dotarliśmy do obecnego punktu: trendy DevOps z przeszłości
Ogromny rozwój DevOps w ciągu mniej więcej ostatniej dekady zbiegł się z wieloma powiązanymi trendami technologicznymi, które umożliwiły stosowanie praktyk DevOps i wyrosły z zasad i kultury DevOps. Do najważniejszych czynników, które doprowadziły nas do obecnego punktu, należą:
Konteneryzacja: Obserwujemy coraz szersze wykorzystanie Dockera i innych narzędzi do konteneryzacji oprogramowania, co pomogło zapewnić przenośność aplikacji między różnymi platformami, takimi jak rozmaite publiczne i prywatne platformy chmurowe (w tym Amazon Web Services, Microsoft Azure i Google Cloud Platform), a także infrastruktura lokalna.
Ekosystem natywny dla chmury: Zaobserwowaliśmy gwałtowny wzrost liczby natywnych dla chmury platform do tworzenia aplikacji, które zapewniają skalowalność infrastruktury i usług. Aby ująć cały krajobraz technologii natywnych dla chmury w jednym miejscu, potrzebna byłaby tablica wielkości billboardu — nawet w przeglądarce internetowej prawdopodobnie trzeba będzie przewijać stronę, aby zobaczyć wszystko!
Cyberbezpieczeństwo: Choć początkowo DevOps mógł koncentrować się na ściślejszym powiązaniu prac programistycznych i operacyjnych, uwydatnił również potrzebę nadania priorytetu bezpieczeństwu na wczesnym etapie cyklu życia tworzenia oprogramowania (SDLC). DevSecOps wyłonił się jako ważny trend, integrując bezpieczeństwo z potokiem DevOps zamiast traktować je jako odrębny element. Między innymi usprawniło to wczesne wykrywanie podatności, minimalizując ryzyko i skalę skutków w środowisku produkcyjnym.
Infrastruktura jako kod (IaC): DevOps uczynił automatyzację pełnoprawnym elementem środowisk IT, a trend ten był szczególnie widoczny w obszarze infrastruktury; zarządzanie infrastrukturą zwykle było bardzo ręcznym i powtarzalnym zadaniem, jednak wprowadzenie infrastruktury jako kodu (IaC) zapewniło wydajne, niezawodne i powtarzalne mechanizmy zarządzania infrastrukturą, na której działają aplikacje.
Kultura: DevOps nigdy nie dotyczył wyłącznie technologii. Jego celem było raczej nadanie priorytetu ludziom i uwolnienie ich od niepotrzebnych obciążeń lub problemów w pracy. W rezultacie DevOps pomógł ponownie skupić uwagę na znaczeniu zdrowej i nietoksycznej kultury pracy, kładąc nacisk między innymi na bezpieczeństwo psychologiczne, analizy po incydentach pozbawione obwiniania, wspólne systemy motywacyjne, ciągłe doskonalenie i wiele innych aspektów.
Sztuczna inteligencja i uczenie maszynowe: Choć duże modele językowe (LLM) i generatywna sztuczna inteligencja cieszą się obecnie ogromną popularnością, AI/ML z pewnością nie jest nowością. W szczególności uczenie maszynowe jest już wykorzystywane między innymi do analityki predykcyjnej, wykrywania błędów i automatyzacji procesów w różnych kontekstach DevOps.
Have an account? Log In
Obecne trendy w DevOps
Chociaż większość powyższych wzorców funkcjonuje już od dość dawna, nie oznacza to, że DevOps zatrzymał się w miejscu. Wydaje się równie popularny jak zawsze — i równie poszukiwany z perspektywy rekrutacji. Niedawne ogólnokrajowe wyszukiwanie ofert pracy na stanowisko inżyniera DevOps w Stanach Zjednoczonych na LinkedIn — pojedynczy tytuł stanowiska wśród wielu potencjalnie odpowiednich ról — przyniosło niemal 5000 otwartych ofert pracy.
Wraz z dojrzewaniem DevOps nadal ewoluował. Przyjrzyjmy się pięciu najbardziej widocznym sposobom, na jakie DevOps wciąż się zmienia.
1. Powszechne wdrażanie Kubernetes
Wraz z gwałtownym wzrostem popularności kontenerów stało się jasne, że zespoły DevOps potrzebują lepszego sposobu zarządzania tym wszystkim. Wtedy pojawił się Kubernetes, który stał się standardem w zakresie orkiestracji kontenerów oraz wspólną platformą (dostępną w wielu dystrybucjach lub odmianach) umożliwiającą zespołom zarządzanie aplikacjami i infrastrukturą.
„Kubernetes i kontenery umożliwiły zespołom pakowanie wszystkich niezbędnych środowisk i uruchamianie kodu na standardowej platformie, dzięki czemu zespoły operacyjne muszą martwić się wyłącznie o kondycję platformy Kubernetes” — mówi nam Vitor Avancini, dyrektor ds. technologii w firmie konsultingowej zajmującej się sztuczną inteligencją i danymi, Indicium.
Kubernetes oferuje solidną infrastrukturę automatyzacji, sieciową i pamięci masowej dla obciążeń natywnych dla chmury. To także dzięki niemu jedna z początkowych obietnic konteneryzacji — możliwość przenoszenia obciążeń między środowiskami bez konieczności ich zasadniczej przebudowy — stała się bardziej realistyczna: „Ułatwiło to zespołowi operacyjnemu kopiowanie i wklejanie wielu środowisk, ponieważ nie potrzebujesz różnych środowisk dla różnych stosów aplikacji”.
To pomaga wyjaśnić, dlaczego według badania z 2023 roku przeprowadzonego przez Cloud Native Computing Foundation około dwie trzecie organizacji korzysta z Kubernetes w środowiskach produkcyjnych, a kolejne 18 procent aktywnie ocenia jego wykorzystanie w produkcji.
Narzędzia DevOps, które pomogą: Kubernetes (surowa dystrybucja otwartoźródłowa), a także szeroki wybór komercyjnego i zarządzanego oprogramowania do zarządzania kontenerami.
2. Automatyzacja jest wszędzie w DevOps
Kubernetes jest najlepszym przykładem szerszego trendu, który zakorzenił się we wczesnych dniach DevOps: Automatyzujmy wszystko.
To, co zaczęło się jako mem, zbliża się do rzeczywistości w tym sensie, że automatyzacja wydaje się obecna wszędzie w potokach DevOps, CI/CD i GitOps — od skanowania zabezpieczeń, przez przeglądy QA, po zadania związane z kompilowaniem i wdrażaniem, egzekwowanie zasad i wiele więcej. Widać to również w oszałamiającej różnorodności narzędzi do automatyzacji. Niektóre z nich — mianowicie narzędzia niskokodowe i bezkodowe — nie wymagają nawet wiedzy programistycznej.
„Wraz ze swobodą, jaką [DevOps] daje zespołom, sytuacja może stać się chaotyczna, dlatego narzędzia do [automatyzacji] mogą odgrywać ważną rolę w utrzymaniu porządku i zarządzania” — mówi Avancini, zauważając, że narzędzia IaC, takie jak Terraform, nadal odgrywają tu znaczącą rolę.
Narzędzia DevOps, które pomogą: Terraform, Ansible
Ustalanie priorytetów jest bardzo częstym wyzwaniem, a firmy często odkładają krytyczne zadania związane z chmurą, takie jak optymalizacja baz danych i rozwój infrastruktury, na późniejsze kwartały, a nawet na kolejny rok. Zespoły DevOps chętnie zajęłyby się tymi problemami, ale gdy już zasiądą do pracy, sama liczba zadań często utrudnia ustalenie, które kwestie mają największą wartość i powinny otrzymać najwyższy priorytet.
Właśnie dlatego firma Zesty rozszerzyła swoją ofertę o platformę zawierającą praktyczne rekomendacje, które pomagają firmom ustalać priorytety i skutecznie wdrażać w pierwszej kolejności najcenniejsze usprawnienia. Aby skutecznie ustalać priorytety tych zadań, firmy potrzebują jasnych informacji na temat związanych z nimi nakładów czasowych i finansowych. Platformy automatyzujące te procesy są niezwykle wartościowe, ponieważ umożliwiają podejmowanie lepszych decyzji i efektywniejszą alokację zasobów. Zespoły DevOps coraz lepiej dostrzegają wartość, jaką zapewniają platformy dzięki automatyzacji, widoczności i praktycznym rekomendacjom.
3. Architektura mikrousług jest również wszędzie
Architektura mikrousług – która zasadniczo polega na podziale większych aplikacji na mniejsze, odrębne komponenty działające niezależnie, a jednocześnie współpracujące ze sobą w celu utworzenia większego systemu – nie jest nowym rozwiązaniem. Jednak przez wiele lat takie podejście nie zawsze było realistyczne dla wielu organizacji.
Obecnie trzy czwarte (74%) firm korzysta z mikrousług, według firmy Gartner, a niemal wszystkie pozostałe (23%) planują zacząć to robić w najbliższej przyszłości.
„Mikrousługi dały zespołom możliwość wyboru własnych stosów narzędzi, podczas gdy wcześniej centralne zespoły operacyjne musiały zapewniać zespołom deweloperskim różne środowiska testowe i wdrożeniowe” – mówi Avancini.
Można tu rozpocząć dyskusję o tym, co było pierwsze – kura czy jajko – ponieważ architektura mikrousług naturalnie pasuje do kontenerów i Kubernetes. Dojrzałość pierwszego rozwiązania prawdopodobnie przyczyniła się więc do upowszechnienia drugiego, podobnie jak ogólny rozwój technologii natywnych dla chmury i procesu tworzenia oprogramowania. (Nowe aplikacje, czyli aplikacje tworzone od podstaw, powstające obecnie, są częściej projektowane z myślą o środowiskach natywnych dla chmury, a mikrousługi stanowią jedną z głównych opcji architektonicznych).
Architektura mikrousług rozwijała się również równolegle z przetwarzaniem bezserwerowym (czyli architekturą bezserwerową). Są to odrębne, ale często powiązane ze sobą koncepcje – prostym sposobem na ich rozróżnienie jest stwierdzenie, że mikrousługi to podejście architektoniczne do projektowania oprogramowania, podczas gdy architektura bezserwerowa to podejście architektoniczne do sposobu, w jaki to oprogramowanie faktycznie działa.
Narzędzia DevOps pomocne w pracy: Prometheus, Compass, AWS Fargate
4. Inżynieria platformowa to nowy DevOps (w pewnym sensie)
W porządku, nagłówek jest nieco przesadzony – inżynieria platformowa i DevOps to różne dziedziny, ale ich wzajemne powiązania stale się rozwijają. Przykładem potwierdzającym tę obserwację jest fakt, że wieloletni raport Puppet „Stan DevOps” miał w 2024 roku podtytuł: „Ewolucja inżynierii platformowej”.
Inżynieria platformowa to dziedzina polegająca na tworzeniu platform wewnętrznych – z dużym naciskiem na samoobsługę – aby zapewnić deweloperom i innym specjalistom technicznym wszystko, czego potrzebują do tworzenia aplikacji i usług. Podobnie jak w przypadku DevOps, duży nacisk kładzie się na automatyzację infrastruktury, ustandaryzowane zestawy narzędzi i przepływy pracy oraz inne podobne rozwiązania. Na przykład udostępnienie środowiska programistycznego lub testowego nie powinno wymagać wysłania zgłoszenia do całkowicie odrębnego zespołu zarządzającego infrastrukturą.
„[W]ażnym trendem jest inżynieria platformowa, która zapewni narzędzia i praktyki umożliwiające zespołom deweloperskim nie tylko tworzenie aplikacji, ale także ich testowanie, monitorowanie i przywracanie poprzednich wersji” w ujednolicony, spójny sposób – mówi Avancini – bez konieczności regularnego proszenia specjalistów ds. operacji o infrastrukturę i usługi potrzebne do realizacji tych zadań.
Avancini zauważa również ogólną zmianę w DevOps w kierunku scentralizowanych procesów – co na pierwszy rzut oka może wydawać się sprzeczne z intuicją, biorąc pod uwagę organiczny rozwój wielu kultur DevOps. Inżynierię platformową można jednak postrzegać właśnie w tym kontekście: DevOps nie oznacza anarchii. Deweloperzy i inni specjaliści IT nadal potrzebują narzędzi, infrastruktury i – tak – mechanizmów kontroli.
W tym kontekście można również czasami spotkać terminy Wewnętrzna platforma deweloperska (IDP) oraz Zintegrowane środowisko programistyczne (IDE).
Narzędzia DevOps pomocne w pracy: Kubernetes, Humanitec
More Articles
5. AI będzie odgrywać coraz większą rolę w DevOps
Powstające zastosowania AI – ostatnio reprezentowane przede wszystkim przez nową klasę aplikacji generatywnej AI opartych na LLM, które w ostatnim czasie przyciągnęły dużą uwagę – prawdopodobnie znajdą również zastosowanie w procesach i łańcuchach narzędzi DevOps. Istnieje nawet określenie opisujące to połączenie: AIOps.
Być może najprościej jest zastanowić się nad tym, gdzie AI okaże się przydatna, z szerszej perspektywy automatyzacji: jeśli coś można zautomatyzować albo jeśli ludzką inteligencję i wysiłek można w jakiś sposób wykorzystać, AI może (i prawdopodobnie będzie) odgrywać w tym rolę.
„Wsparcie AI odegra ważną rolę w DevOps, głównie w zakresie wsparcia podczas przeglądu kodu, analizy jakości i bezpieczeństwa kodu oraz automatycznego opisywania wszystkich skutków, jakie może mieć nowy kod po wdrożeniu” – mówi Avancini.
Rzeczywiście, istnieje cała lista potencjalnych zastosowań, z których wiele dopiero się pojawia. Należy spodziewać się, że produktywność programistów i automatyzacja bezpieczeństwa będą w najbliższej przyszłości dwoma głównymi obszarami zainteresowania.
Narzędzia DevOps, które mogą pomóc: GitHub Copilot
Podsumowanie
Kultura i praktyki DevOps przetrwały próbę czasu – ale nie oznacza to, że pozostają niezmienne. Jakie są najnowsze trendy DevOps w Twojej organizacji? W jakim kierunku, Twoim zdaniem, będzie rozwijać się DevOps w nadchodzących latach? Dołącz do biuletynu The CTO Club, aby otrzymywać więcej wiadomości i informacji branżowych oraz brać udział w dyskusjach!
