Idź do:
Rozwój oprogramowania kiedyś…
Dawno, dawno temu, za czasów, gdy wszystkie aplikacje na świecie budowane były przez zespoły developerskie w architekturze monolitycznej, uruchomieniem tychże aplikacji zajmował się wszechmogący Admin. Dlaczego wszechmogący? Admin posiadał ogromną wiedzę, a także umiejętności, zarówno w zakresie sprzętu, jak i jego konfiguracji. Nic więc dziwnego, że jego władza była duża. W czasach, gdy rozwiązania chmurowe nie istniały, spoczywała na nim ogromna odpowiedzialność za prawidłowe konfigurowanie monolitycznej architektury w środowisku produkcyjnym, w którym ruch często był ogromny, a wymagania wobec niezawodności – wysokie. Taki podział obowiązków tworzył jednak ogromne bariery między zespołem wytwarzającym oprogramowanie a wymienionym adminem. Osoba kontrolująca dostęp do zasobów serwera, zamknięta w swojej twierdzy, nie rozumiała trudności napotkanych przez developerów i nierzadko winiła ich za wszystkie problemy. W drugą stronę działało to podobnie, a brak komunikacji potrafi poważnie spowolniać każdy projekt.
Jak to robimy dziś?
Dziś mamy dużo większe możliwości w zakresie wytwarzania oprogramowania i nie boimy się eksperymentować, ponieważ dzięki rozwiązaniom chmurowym nie wdrażamy zmian bezpośrednio w środowisku produkcyjnym. Pracujemy zwinnie, w zgodzie z metodami Agile, stawiamy na komunikację, transparentność, budujemy zgrane zespoły, zwracając uwagę na Time to Market. W dobie start-upów zrodziła się też potrzeba szybkiego uruchomienia środowiska developerskiego oraz wdrażania w środowisku produkcyjnym choćby podstawowej wersji produktu (czyli MVP – Minimum Viable Product). To pozwala szybko sprawdzić słuszność założeń wobec nowego rozwiązania.
Przeczytaj artykuł: Azure DevOps – jak zacząć karierę?
Duża złożoność wymagań biznesowych oraz poziom skomplikowania budowanych narzędzi wymuszają z kolei większą specjalizację umiejętności danych członków zespołu developerskiego. Wcześniejsze podejście – jeden specjalista od wszystkiego: od programowania, po wdrożenie produktu – nie ma dziś już racji bytu. Developer, skupiony na dostarczaniu oprogramowania, nie ma wystarczająco dużo czasu na wdrażanie go w środowisku serwerowym. Tak właśnie powstała potrzeba wskazania w zespole specjalisty, którego cechowałyby umiejętności w obszarze tworzenia aplikacji, ale także znajomość procesów ich wdrożenia. I tym kimś jest właśnie DevOps (ang. Development and Operations).
Dowiedz się więcej: Cloud Engineering
Przeczytaj także: Korzyści z migracji firm do chmury
Kim jest specjalista DevOps?
DevOps to rola, w której specjalista jest lub może być odpowiedzialny za poniższe obszary:
- Przygotowanie środowisk na różnych poziomach, które umożliwiają odpowiednio: rozwój oprogramowania, testy, wdrożenie w środowisku developerskim i wdrożenie na produkcji;
- Proces Continuous Integration / Continuous Delivery (skrót. CI/CD) – przygotowanie i automatyzacja procesu budowania, testowania, weryfikacji jakości kodu, a następnie wdrożenia go w środowisku serwerowym przy pomocy dedykowanych narzędzi (Jenkins, CircleCI, GitHub itp.);
- Instalacja, konfiguracja oraz aktualizacja narzędzi wspierających proces wytwarzania oprogramowania, co pozwala skrócić czas potrzebny do wdrożenia oraz wprowadzania zmian (repozytoria artefaktów i kontenerów Dockera, Sonar, Elastic Search, bazy danych);
- Monitoring infrastruktury oraz sprawdzanie ostrzeżeń automatycznie generowanych przez system w przypadku anomalii.
- Usprawnienie komunikacji z zespołem osób odpowiedzialnych za infrastrukturę (jeśli taki istnieje);
- Automatyzacja procesów eliminująca błędy wynikające z „czynnika ludzkiego”, czyli IaC (Infrastructure as Code), przy wykorzystaniu narzędzi takich jak np. Terraform, Ansible.
- Wdrożenie skalowalnej, elastycznej i samonaprawiającej się aplikacji (głównie w chmurze).
Czym zajmuje się DevOps Engineer? Różne konfiguracje jednego specjalisty
Choć często pojawiają się ogłoszenia o pracę na stanowisku „DevOps Engineer”, niektórzy twierdzą, że nie ma takiej roli. Prawdopodobnie dlatego, że zakres obowiązków takiej osoby bywa bardzo różny, w zależności od rozmiaru projektu. W praktyce możemy więc spotkać różne konfiguracje tego stanowiska pracy:
1) DevOps jest członkiem zespołu developerskiego
Zespół infrastruktury odpowiada za część serwerową, a DevOps jest „przedstawicielem” zespołu rozwijającego oprogramowanie, kontaktującym się z zespołem, który zajmuje się infrastrukturą.
Plusy
- DevOps może brać czynny udział w rozwoju oprogramowania
- DevOps może lepiej wsłuchać się w potrzeby zespołu programistów
Minusy
- Ma mniejszy wpływ na to, co dzieje się po stronie infrastruktury
- Komunikacja z DevOpsami z innych zespołów jest słabsza
2) Specjaliści DevOps tworzą oddzielny zespół, a każdy DevOps jest przypisany do zadań jednego lub dwóch zespołów developerskich
Plusy
- Lepsza komunikacja pomiędzy specjalistami DevOps – nie tworzy się dwóch takich samych rozwiązań, co pozwala zachować większą spójność
- Większa wydajność pracy dzięki automatyzacji i usprawnieniu procesów dostarczania oprogramowania
Minusy
- Słabsza komunikacja z zespołem developerskim
Dlaczego warto mieć w projekcie inżyniera DevOps?
Jak widać, choć DevOps jest specjalistą o szerokim zakresie kompetencji, w niczym nie przypomina zamkniętego w serwerowni administratora. Wiele organizacji chętnie zatrudnia specjalistów DevOps, a nie które firmy nawet całe zespoły DevOps, gdyż stoją za tym konkretne korzyści:
- Szybsze wdrożenie – DevOps dzięki swojej wiedzy w zakresie wdrożeń odciąża developerów, którzy skupiają się na programowaniu;
- Znacząca poprawa jakości oprogramowania – dzięki wieloetapowemu procesowi Continuous Integration, mającemu na celu przeprowadzenie różnego rodzaju testów oprogramowania;
- Poprawa bezpieczeństwa dostarczonego rozwiązania – DevOps posiada szeroką wiedzę w zakresie bezpieczeństwa. W kontekście roli DevOpsa często pojawia się rozwinięcie „DevOpsSec” – od słowa security;
- Wysoka dostępność – są różne sposoby wdrażania oprogramowania na serwerze. Można wdrożyć jedną instancję aplikacji, przy czym w chwili awarii staje się ona niedostępna. Dzięki wdrożeniu przez DevOpsa w tzw. wysokiej dostępności (High Availability) istnieje kilka instancji aplikacji. Ma to na celu utrzymanie dostępu do usługi oraz pełnej funkcjonalności oprogramowania;
- Skalowalność – DevOps może wdrożyć rozwiązanie umożliwiające automatyczne zwiększenie liczby instancji aplikacji przy nagłym wzmożonym ruchu;
- Self-healing – wdrożenie przez inżyniera DevOps mechanizmów utrzymania pozwala nadać aplikacji zdolność do naprawienia się w przypadku awarii. Automatyzacja może polegać na regularnym, np. co 10 sekund, wykonaniu testu, czy dana aplikacja działa, i w razie potrzeb automatycznie uruchomić ją ponownie.
Przeczytaj także: Automatyzacja procesów z Azure Durable Function
Podsumowanie
Pędząca transformacja cyfrowa sprawia, że podejście do rozwoju oprogramowania się zmienia, a firmy szukają specjalistów, którzy usprawnią i przyspieszą ten proces. Pozyskanie ich jest jednak niełatwe i w 2019 roku specjaliści DevOps znajdowali się wg raportu LinkedIn na trzecim miejscu najbardziej pożądanych kompetencji. Nic dziwnego, że coraz więcej organizacji publikuje oferty pracy dla DevOps Engineera. Część firm decyduje się także na zatrudnienie całego zespołu DevOps, korzystając ze wsparcia firm specjalizujących się w rozwoju oprogramowania. Powody są różne: trzeba skrócić czas wdrożenia aplikacji, jest chęć poprawy bezpieczeństwa i komunikacji między zespołami projektowymi czy chęć posiadania wysokiej jakości aplikacji. A jaki byłby twój powód?
Java Developer z ponad 10-letnim doświadczeniem projektowym. Aktualnie zafascynowany ideą DevOps oraz rozwiązaniami chmurowymi.