• +48 530 88 77 99
  • info@thecamels.org

Serwer MySQL jest bardzo chętnie wybierany jako baza danych dla wielu serwisów internetowych. Z biegiem czasu baza potrafi się rozrastać do kolosalnych rozmiarów. Poza przechowywaniem treści strony (artykuły, komentarze, lista użytkowników), zawiera również ustawienia samej strony czy aplikacji. W takim wypadku regularne robienie kopii zapasowej staje się wręcz koniecznością. Duża baza danych to również większe obciążenie dla serwera, który musi uporać się z zarządzaniem milionami rekordów. Remedium na wiele tego typu problemów może być replikacja.

Wiele organizacji podejmuje decyzję o migracji swoich usług oraz infrastruktury do chmury. Chcą w ten sposób zmniejszyć koszta utrzymania serwerów oraz przede wszystkim zapewnić aplikacji skalowalność oraz wysoką dostępność. Niestety sam proces przenoszenia usług do chmury może okazać się bardzo kosztowny oraz pracochłonny. Czasami okazuje się, że konieczne jest przepisanie aplikacji, aby wspierała rozwiązania dostępne w chmurze. Istnieje wiele sposobów jak sobie z tym radzić a jednym z nich jest podejście „lift-and-shift„.

„Continuous” (ang. ciągły) to jedno powtarzające się wielokrotnie słowo, które można usłyszeć w dyskusjach na temat DevOps, gdzie prawie wszystko tam jest ciągłe (continuous). Praca z wykorzystaniem DevOps to ciągła integracja, ciągłe wdrażanie czy ciągłe dostarczanie oprogramowania. Zatem czym różnią się między sobą Continuous Integration, Continuous Delivery oraz Continuous Deployment. Przyjrzyjmy się bliżej idei ciągłości i temu, dlaczego ma tak centralne znaczenie w praktyce DevOps.

Dla tych, którzy od lat pracują z DevOps i są mocno zaangażowani w tę metodykę, jej rosnąca popularność jest tak ekscytująca, jak dostanie pierwszej pracy zaraz po studiach! No dobrze, może nie aż tak ekscytująca, ale w dalszym ciągu naprawdę super. Coraz więcej firm wszystkich rozmiarów decyduje się na DevOps, wdrażając praktyki związane z metodyką bezpośrednio w podstawowe strategie.

Jednym z powodów, dla którego programiści nie lubią spotkań, jest fakt, że ich harmonogram dnia różni się od harmonogramu innych ludzi. Spotkania więcej ich kosztują. Rozróżnijmy zatem Harmonogram twórcy oraz Harmonogram kierownika.

Współcześnie, oprogramowanie jest powszechnie dostarczane jako usługa (aplikacja internetowa lub SaaS). The twelve-factor app jest metodologią, która pozwala na budowanie takich aplikacji w sposób skalowalny poziomo. Zawiera on doświadczenie i obserwacje z budowy szerokiej gamy aplikacji SaaS.

Twoja firma korzysta teraz z metodologii DevOps. Zintegrowałeś już rozwój, eksploatację i zapewnienie jakości, a także drastycznie odsunąłeś się od gwałtownych działań, a zbliżyłeś się do zrównoważonego rozwoju aplikacji. Jak masz dowiedzieć się, jak dobrze działa takie rozwiązanie? Skąd wiesz, czy w ogóle działa?

Nie odkryjemy Ameryki jeśli powiemy, że im większa infrastruktura IT, tym większe wyzwania w zarządzaniu nią. Są jednak sposoby uproszczenia pracy warte zgłębienia. Jeśli miałeś już do czynienia z dużymi infrastrukturami, to zapewne słyszałeś o pojęciu DevOps, którego częścią jest właśnie pojęcie Infrastruktury-jako-kodu.

DevOps oraz SysOps – na pewno spotkałeś się już z tymi pojęciami. Jeśli masz firmę, to raczej mało jest prawdopodobne, że prowadzisz ją zupełnie bez komputerów, baz danych, systemów operacyjnych i serwerów. Być może nie zdajesz sobie nawet sprawy z tego, jak szeroko technologia zakradła się do Twojego przedsiębiorstwa. Wszystkie systemy muszą oczywiście ze sobą współgrać i działać 24x7x365, co wymaga stałego zarządzania nimi od strony infrastruktury i administracyjnej. A takie zarządzanie wymaga wiedzy i znajomości wielu zagadnień, musi opierać się na pewnych fundamentach, i powinna stać za tym jakaś myśl.