Od kilku lat można zauważyć rosnący popyt na DevOps (co to jest DevOps według mnie wyjaśniam tutaj), wcześniej to były dwie znacząco różniące się role. Programiści (Dev) którzy tworzyli oprogramowanie, oraz dział wdrożeń i utrzymania (Ops) którzy uruchamiali i zarządzali środowiskami produkcyjnymi. Taka jest teraźniejszość, ale co dalej?

Aplikacje Cloud Native

Bohater dzisiejszego wpisu – Cloud Native – czy chodzi tutaj tylko o aplikacje/serwisy które można uruchamiać w chmurze? Zdecydowanie nie! Cloud native apps, nie powinny być zależne od środowiska, nie ważne czy to jest chmura publiczna, chmura prywatna czy moja maszyna developerska.

Dotychczas, programista podczas pracy nad jakimś systemem musiał myśleć o tym, czy to będzie aplikacja uruchamiana jako WebApp w Azure, AWS Lambda, czy może Linux service w datacenter naszego klienta. Razem z cloud native takie rozważania odchodzą do lamusa, bo dla mnie – jako programisty, chmurą może być Azure, AWS, GCP czy też serwerownia dwa piętra niżej. Elastyczność takich aplikacji może być osiągnięta poprzez ich konteneryzację – dzięki temu łatwo odciąć się od fizycznych zasobów.

Kolejną cechą podejścia cloud native jest założenie że aplikacje są rozproszone, a precyzyjniej – są mikroserwisami. O architekturze microservice powstało wiele książek i można by jeszcze napisać kilka razy więcej o różnych podejściach do tego tematu. Zasadniczo mikroserwis to taka aplikacja/proces, która nie jest sztywno powiązana z innymi komponentami systemu i robi jedną rzecz (z biznesowego punktu widzenia). Dodatkowym atutem systemów mikroserwis jest to (a przynajmniej powinno!), że są wysoce skalowalne. Powinniśmy być w stanie uruchamiać nasze systemy na niewielkiej liczbie maszyn, a także na takiej ilości która uniemożliwia już manualne ingerencje i zarządzanie nimi powierza się innym maszynom.

Jeżeli nasz system jest rozproszony, pojawia się problem wyzwanie – jak je monitorować, zbierać logi i debugować? Aplikacje cloud native powinny być obserwowalne. Dzięki temu, będziemy w stanie powiedzieć która z 300 instancji serwisu obsłużyła jakiś proces biznesowy, ile w tym czasie zużywała czasu procesora i ile RAM potrzebowała.

Błędy zdarzają się zawsze, nie pytamy już „czy będziemy mieć błąd na produkcji?” tylko „kiedy będziemy mieć błąd na produkcji?” – w 90% przypadków systemy/aplikacje mają problem który ma swoja genezę w działaniach człowieka. Wyeliminowanie interfejsu białkowego (człowieka) z tego procesu pozwala na zmniejszenie ilości błędnych decyzji – oznacza to, że im większa automatyzacja, tym większa niezawodność, dostępność i jednolity format tego co jest uruchamiane. Kubernetes zapewnia API – jednolite niezależnie od infrastruktury, dodatkowo „opiekuje się” kontenerami uruchomionymi na nim.

Jaki z tego zysk?

Biorąc pod uwagę powyższe cechy, rozwijanie aplikacji cloud native powinno pozwolić na częstsze i szybsze dostarczanie i niezawodność rozwiązania. Produkty w ramach organizacji – zamiast własnych procedur wdrażania/developmentu będą posiadać jednolite podejście, wymuszone przez API Kubernetes’a. Na koniec warto przytoczyć słowa jednego z programistów Google – Kelsey Hightower’a:

Kubernetes does the things that the very best system administrator would do: automation, failover, centralized logging, monitoring. It takes what we’ve learned in the DevOps community and makes it the default, out of the box.

Kelsey Hightower

Literatura:

• Cloud Native DevOps with Kubernetes: John Arundel; Justin Domingus
• Kubernetes: Up & Running: Joe Beda, Brendan Burns, Kelsey Hightower