Kiedy byłem administratorem ...
Pewnego razu w dużej firmie administratorzy systemów i programiści żyli w całkowitej separacji. Deweloperzy co miesiąc “przerzucali przez płot” kod, a “opsi” musieli go ręcznie wdrażać, co zwykle kończyło się awariami trwającymi całą noc.
Change my life
Wszystko zmieniło się przez… zepsuty automat do kawy. Kiedy obie grupy spotkały się w kolejce do jedynej sprawnej maszyny w innym skrzydle, zaczęły narzekać na te same błędy.
Pierwszy krok ku DevOps
Zamiast słać oficjalne maile, narysowali schemat na serwetce. Tak powstał ich pierwszy wspólny skrypt, który skrócił wdrożenie z dziesięciu godzin do pięciu minut.
To była ich pierwsza lekcja, że DevOps to nie tylko narzędzia, ale przede wszystkim rozmowa i wspólna odpowiedzialność.
Nocne wdrożenia
W tej firmie każda próba wdrożenia nowej funkcji przypominała rozbrajanie bomby w ciemności. Deweloperzy tworzyli skomplikowany kod na swoich lokalnych maszynach, a potem przesyłali ogromne paczki dokumentacji do działu operacyjnego.
Administratorzy, którzy nigdy wcześniej nie widzieli tego kodu na oczy, musieli zgadywać, dlaczego biblioteki nie pasują do serwerów produkcyjnych. Frustracja rosła, a wzajemne oskarżenia były na porządku dziennym.
Pierwszy CI/CD
Przełom nastąpił przy wspomnianym automacie do kawy. Dwóch inżynierów z przeciwnych obozów, zaczęło rozmawiać o tym, jak bardzo nienawidzą nocnych dyżurów. Programista, przyznał, że nie ma pojęcia, na jakim systemie działają serwery, a Administrator z operacji wyznał, że nie rozumie, dlaczego aplikacja potrzebuje tylu zależności.
Zamiast wrócić do swoich biurek, usiedli z kawą i zaczęli projektować coś, co dziś nazywamy potokiem CI/CD. Zaczęli od prostego skryptu, który automatycznie sprawdzał, czy kod deweloperów w ogóle da się uruchomić w środowisku testowym. Potem dodali automatyczne testy i konteneryzację, co pozwoliło im odizolować aplikację od kaprysów infrastruktury.
A może Platform Ops ... ?
Historia Administratora, który stał się DevOps nie skończyła się na wspólnym skrypcie. Sukces sprawił, że firma zaczeła rosnąć w zawrotnym tempie. Zamiast dwóch zespołów, nagle pojawiło się ich pięćdziesiąt, co utrudniało utrzymanie wszystkich procesów w organizacji. Kolejne spotkanie przy automacie zakończone stwierdzeniem
„A gdybyśmy tak przestali dawać im surowe klocki, a zbudowali dla nich gotową przestrzeń?”.
Tak narodził się pomysł na Platform Engineering, znany też jako PlatformOps. Powstał nowy zespół platformowy, którego „klientami” stali się inni programiści w firmie. Zamiast zmuszać każdego do bycia ekspertem od wszystkiego, dostarczyli im Wewnętrzną Platformę Deweloperską (IDP).
Teraz, gdy nowy deweloper chciał uruchomić usługę, nie musiał już prosić Administratora o serwer ani pisać tysiąca linii kodu YAML. Klikał jeden przycisk w ustandaryzowanym katalogu. Platforma w tle dbała o bezpieczeństwo, bazy danych i monitoring – zgodnie ze standardami, które zostały wypracowane lata wcześniej.
A przyszłość.. ?
Cóż …
