Warsztat DevOps’a – Teoria cz. 1

Witam w pierwszym artykule z serii „Warsztat DevOps’a”. Cała seria będzie zawierać zagadnienia teoretyczne jak i praktyczne – także każdy powinien znaleźć wartościowe informacje dla siebie. Jeżeli znajdziesz w artykułach jakieś błędy, bądź niejasności proszę daj mi znać.

Dzisiaj zaczniemy od podstaw, czyli od odpowiedzi na pytanie: Co to w ogóle jest to DevOps i ten DevOps Engineer.

Dawne dzieje:

Aby dobrze zrozumieć ideę, która stoi za nurtem DevOps trzeba się cofnąć kilka lat wstecz. Do czasów kiedy metodologie zwinne wytwarzania oprogramowania jeszcze raczkowały. W tamtym czasie ktoś odkrył, że klasyczne metodologie nie sprawdzają się za dobrze. Po prostu za wolno reagują na zmiany na rynku. Tak więc chodziło o to, że Klient / Autor / Pomysłodawca wiedział, że jego aplikacja potrzebuje przeprojektowania. Nie miał on jednak żadnego mechanizmu, aby podzielić się tą informacją z zespołem developerskim. W związku z powyższym pojawił się prym metodologii zwinnych, który dzięki iteracyjnemu sposobowi wytwarzania pozwala na reakcję w bardzo szybkim czasie, co zadowala klienta i nie irytuje developera. Reasumując metodologie zwinne rozwiązały problem komunikacji między Klientem a zespołem wytwarzającym oprogramowanie. Dzisiaj bardzo mało osób wyobraża sobie pracę nad projektem w innej metodologii niż zwinnej, bo są one  standardem.

Czasy współczesne:

Z biegiem czasu okazało się, że rozwój narzędzi i technologii doprowadził do swego rodzaju podziału na Dev i Ops. Tak dobrze czytasz, ten podział nie istniał od zawsze. Za moich czasów młodości, nie było takich podziałów. Kiedy miałem pierwszą pracę w kawiarence internetowej, trzeba było sobie samemu skonfigurować serwer, na którym odpalało się napisaną przez samego siebie aplikację (chyba zaczynałem jako DevOps Engineer). Wraz ze wzrostem zapotrzebowania na moc obliczeniową więcej ludzi było potrzebne do konfigurowania / tworzenia infrastruktury (Ops). Przyspieszenie współpracy pomiędzy developerami, a Klientami / Pomysłodawcami spowodowało także większe zapotrzebowanie na osoby tworzące kod (Dev). To właśnie dlatego, że ten podział się nasilił powstał nurt DevOps. Reasumując ten trochę zagmatwany wywód, DevOps jest to metodologia pomagająca zatrzeć powiększającą się lukę pomiędzy sferą Dev i Ops.

Teraz już pewnie się domyślasz kim jest DevOps Engineer. DevOps Engineer to osoba posiadająca doświadczenie w Dev i Ops oraz umiejąca to doświadczenie wykorzystać w połączeniu z obecnie istniejącymi narzędziami do automatyzacji. Moim zdaniem w idealnym świecie zespół powinien składać się z samych DevOps Engineer’ów. Każdy z nich mógłby być wyspecjalizowany „mniej” lub „bardziej” w węższej dziedzinie np. lepszy programista, lepszy tester, czy lepszy administrator). Więc finalnie nie istotne czy jesteś programistą, testerem, czy administratorem – możesz nauczyć się DevOps. Jeżeli kiedykolwiek zdażyło Ci się myśleć, że DevOps Engineer to osoba na która programiści, testerzy i administratorzy spychają pracę, której sami nie lubią / nie umieją robić to byłeś w ogromnym błędzie.

Mam nadzieję, że ten artykuł dał Ci do myślenia. Przekonaj się do zapoznania z metodologią DevOps – to napewno dobra inwestycja w przyszłość. Na zakończenie proszę przemyśl jakie plusy daje ta metodologia. Czy wg. Ciebie warto jest brnąć w ten nurt? Napisz proszę swoje przemyślenia w komentarzu pod postem lub na facebooku: Szkoła DevOps